Functional specifications (functional specs), in the end, are the blueprint for how you

want a particular report and transaction to look and work. It details what the report will
do, how a user will interact with it, and what it will look like. By creating a blueprint of
the report or transaction first, time and productivity are saved during the development
stage because the programmers can program instead of also working out the logic of the
user-eperience. It will also enable you to manage the epectations of your clients or
management, as they will know eactly what to epect. ! key benefit of writing up a
Functional "pec is in streamlining the development process. #he developer working from
the spec has, ideally, all of their $uestions answered about the report or transaction and
can start building it. !nd since this is a spec that was approved by the client, they are
building nothing less than what the client is epecting. #here should be nothing left to
guess or interpret when the spec is completed. Functional "pecification ! functional
specification (or sometimes functional specifications) is a formal document used to
describe in detail for software developers a product%s intended capabilities, appearance,
and interactions with users. #he functional specification is a kind of guideline and
continuing reference point as the developers write the programming code. (!t least one
ma&or product development group used a '(rite the manual first' approach. Before the
product eisted, they wrote the user%s guide for a word processing system, then declared
that the user%s guide was the functional specification. #he developers were challenged to
create a product that matched what the user%s guide described.) #ypically, the functional
specification for an application program with a series of interactive windows and dialogs
with a user would show the visual appearance of the user interface and describe each of
the possible user input actions and the program response actions. ! functional
specification may also contain formal descriptions of user tasks, dependencies on other
products, and usability criteria. )any companies have a guide for developers that
describes what topics any product%s functional specification should contain. For a sense of
where the functional specification fits into the development process, here are a typical
series of steps in developing a software product* +e$uirements* #his is a formal statement
of what the product planners informed by their knowledge of the marketplace and
specific input from eisting or potential customers believe is needed for a new product or
a new version of an eisting product. +e$uirements are usually epressed in terms of
narrative statements and in a relatively general way. ,b&ectives* ,b&ectives are written by
product designers in response to the +e$uirements. #hey describe in a more specific way
what the product will look like. ,b&ectives may describe architectures, protocols, and
standards to which the product will conform. )easurable ob&ectives are those that set
some criteria by which the end product can be &udged. )easurability can be in terms of
some inde of customer satisfaction or in terms of capabilities and task times. ,b&ectives
must recogni-e time and resource constraints. #he development schedule is often part or a
corollary of the ,b&ectives. Functional specification.* #he functional specification
(usually functional spec or &ust spec for short) is the formal response to the ob&ectives. It
describes all eternal user and programming interfaces that the product must support.
.esign change re$uests* #hroughout the development process, as the need for change to
the functional specification is recogni-ed, a formal change is described in a design change
re$uest. /ogic "pecification* #he structure of the programming (for eample, ma&or
groups of code modules that support a similar function), individual code modules and
their relationships, and the data parameters that they pass to each other may be described
in a formal document called a logic specification. #he logic specification describes
internal interfaces and is for use only by the developers, testers, and, later, to some etent,
the programmers that service the product and provide code fies to the field. 0ser
documentation* In general, all of the preceding documents (ecept the logic specification)
are used as source material for the technical manuals and online information (such as help
pages) that are prepared for the product%s users. #est plan* )ost development groups have
a formal test plan that describes test cases that will eercise the programming that is
written. #esting is done at the module (or unit) level, at the component level, and at the
system level in contet with other products. #his can be thought of as alpha testing. #he
plan may also allow for beta test. "ome companies provide an early version of the
product to a selected group of customers for testing in a 'real world' situation. #he Final
1roduct* Ideally, the final product is a complete implementation of the functional
specification and design change re$uests, some of which may result from formal testing
and beta testing. #he cycle is then repeated for the net version of the product, beginning
with a new +e$uirements statement, which ideally uses feedback from customers about
the current product to determine what customers need or want net. )ost software
makers adhere to a formal development process similar to the one described above. #he
hardware development process is similar but includes some additional considerations for
the outsourcing of parts and verification of the manufacturing process itself. 2ope the
above helps you.

Functional "pecification .ocument (F".) is a document to determine and define the
business process of the area discussed. .epending on how "!1 is implemented in your
organi-ation, F". format may differs for reports, enhancement, interface or forms.
F". should be reviewed by the business owner. ,nce agreed, F". should be forwarded
to the programmer to start the development of the business process. #his is the reason
why F". should be detail, comprehensive and technical enough so that the programmer
can understand the whole re$uirement and coding can be easily developed.
! standard F". format should include*
- #itle of the business process
- 3ersion history
- 4ompleity
- .etail user re$uirement
- 1re-re$uisite and assumption
- 1rocess flow diagram
- 5nhancement screen (if any)
- ,utput layout
- Field and table description (which table6field to insert, update or delete)
- Input and output parameters
- 5rror handling
- #esting re$uirement
#7,
pecs), in the end, are the blueprint for how you want a particular report and
transaction to look and work. It details what the report will do, how a user will
interact with it, and what it will look like. By creating a blueprint of the report or
transaction first, time and productivity are saved during the development stage
because the programmers can program instead of also working out the logic of the
user-experience. It will also enable you to manage the expectations of your clients or
management, as they will know exactly what to expect.
A key benefit of writing up a unctional !pec is in streamlining the development
process. "he developer working from the spec has, ideally, all of their #uestions
answered about the report or transaction and can start building it. And since this is a
spec that was approved by the client, they are building nothing less than what the
client is expecting. "here should be nothing left to guess or interpret when the spec
is completed.
Functional Specification
A functional specification $or sometimes functional specifications) is a formal
document used to describe in detail for software developers a product%s intended
capabilities, appearance, and interactions with users. "he functional specification is a
kind of guideline and continuing reference point as the developers write the
programming code. $At least one ma&or product development group used a '(rite
the manual first' approach. Before the product existed, they wrote the user%s guide
for a word processing system, then declared that the user%s guide was the functional
specification. "he developers were challenged to create a product that matched what
the user%s guide described.) "ypically, the functional specification for an application
program with a series of interactive windows and dialogs with a user would show the
visual appearance of the user interface and describe each of the possible user input
actions and the program response actions. A functional specification may also contain
formal descriptions of user tasks, dependencies on other products, and usability
criteria. )any companies have a guide for developers that describes what topics any
product%s functional specification should contain.
or a sense of where the functional specification fits into the development process,
here are a typical series of steps in developing a software product*
Requirements*
"his is a formal statement of what the product planners informed by their knowledge
of the marketplace and specific input from existing or potential customers believe is
needed for a new product or a new version of an existing product. +e#uirements are
usually expressed in terms of narrative statements and in a relatively general way.
,b&ectives* ,b&ectives are written by product designers in response to the
+e#uirements. "hey describe in a more specific way what the product will look like.
,b&ectives may describe architectures, protocols, and standards to which the product
will conform. )easurable ob&ectives are those that set some criteria by which the end
product can be &udged. )easurability can be in terms of some index of customer
satisfaction or in terms of capabilities and task times. ,b&ectives must recogni-e time
and resource constraints. "he development schedule is often part or a corollary of
the ,b&ectives.
unctional specification.* "he functional specification $usually functional spec or &ust
spec for short) is the formal response to the ob&ectives. It describes all external user
and programming interfaces that the product must support.
.esign change re#uests* "hroughout the development process, as the need for
change to the functional specification is recogni-ed, a formal change is described in a
design change re#uest.
Logic Specification*
"he structure of the programming $for example, ma&or groups of code modules that
support a similar function), individual code modules and their relationships, and the
data parameters that they pass to each other may be described in a formal
document called a logic specification. "he logic specification describes internal
interfaces and is for use only by the developers, testers, and, later, to some extent,
the programmers that service the product and provide code fixes to the field.
User documentation*
In general, all of the preceding documents $except the logic specification) are used
as source material for the technical manuals and online information $such as help
pages) that are prepared for the product%s users.
"est plan* )ost development groups have a formal test plan that describes test cases
that will exercise the programming that is written. "esting is done at the module $or
unit) level, at the component level, and at the system level in context with other
products. "his can be thought of as alpha testing. "he plan may also allow for beta
test. !ome companies provide an early version of the product to a selected group of
customers for testing in a 'real world' situation.
The Final Product*
Ideally, the final product is a complete implementation of the functional specification
and design change re#uests, some of which may result from formal testing and beta
testing. "he cycle is then repeated for the next version of the product, beginning
with a new +e#uirements statement, which ideally uses feedback from customers
about the current product to determine what customers need or want next.
)ost software makers adhere to a formal development process similar to the one
described above. "he hardware development process is similar but includes some
additional considerations for the outsourcing of parts and verification of the
manufacturing process itself.
2i there,
8st try to understand what is a functional specification doc before asking for it.
Functional specs is a doc in which you include what is the business re$uirement. If it
re$uires a change to change to eisting configs 6 code, then you will give the progs 9 the
location where you will need to change. If the re$uirement is a totally new one, then yuo
will eplain the re$uirement in detail 9 possibly give the progs 6 code if there are any.
In your case, your client has a specific invoice format which is different from which "!1
gives, in such cases, you will need to define a new Invoice output for eg :I;3. .efine it
as a print output. <ou will need to define a new print prog for the new output in which
you will call smart forms to define the layout 9 fields.
!sk your business user to send the invoice copy which he has. "can it 9 include it in the
functional specs which you prepare. )ention all the fields which you want in the layout.
!sk the !B!1er to code the invoice format in the same way. !B!1er is free to define
any convinent name as per the guidelines (which he will be aware). <ou will need to
assign that in the form routines of the output.
!s a functional consultant you will need to give the field mappings (from where you get
the data) for all the fields which you wish to print in the output. !ll that should be
included in the func specs.
"o there is no standard func specs that you can follow. 5ach func specs varies on the
re$uirement. "o dont ask these kind of $uestions in ".; forum. If you dont know how to
define func specs, ask how to define. .ont ask people to send the sample func specs.
#hats against the rules of conduct.
check sap sd flow...u will understand everything abt specifications...
". 1rocess Flow*
#he sales documents you create are individual documents but they can also form part of a
chain of inter-related documents. For eample, you may record a customer=s telephone
in$uiry in the system. #he customer net re$uests a $uotation, which you then create by
referring to the in$uiry. #he customer later places an order on the basis of the $uotation
and you create a sales order with reference to the $uotation. <ou ship the goods and bill
the customer. !fter delivery of the goods, the customer claims credit for some damaged
goods and you create a free-of-charge delivery with reference to the sales order. #he
entire chain of documents > the in$uiry, the $uotation, the sales order, the delivery, the
invoice, and the subse$uent delivery free of charge > creates a document flow or history.
#he flow of data from one document into another reduces manual activity and makes
problem resolution easier. In$uiry and $uotation management in the "ales Information
"ystem help you to plan and control your sales.
#ransaction 4odes*
In$uiry - 3!8863!8?63!8@
7uotation - 3!?863!??63!?@
"ales ,rder - 3!A863!A?63!A@
.elivery - 3/A8;63/A?;63/A@;
Billing6Invoicing - 3FA863FA?63FA@
Functional specifications (functional specs), in the end, are the blueprint for how you
want a particular report and transaction to look and work. It details what the report will
do, how a user will interact with it, and what it will look like. By creating a blueprint of
the report or transaction first, time and productivity are saved during the development
stage because the programmers can program instead of also working out the logic of the
user-eperience. It will also enable you to manage the epectations of your clients or
management, as they will know eactly what to epect. ! key benefit of writing up a
Functional "pec is in streamlining the development process. #he developer working from
the spec has, ideally, all of their $uestions answered about the report or transaction and
can start building it. !nd since this is a spec that was approved by the client, they are
building nothing less than what the client is epecting. #here should be nothing left to
guess or interpret when the spec is completed. Functional "pecification ! functional
specification (or sometimes functional specifications) is a formal document used to
describe in detail for software developers a product%s intended capabilities, appearance,
and interactions with users. #he functional specification is a kind of guideline and
continuing reference point as the developers write the programming code. (!t least one
ma&or product development group used a '(rite the manual first' approach. Before the
product eisted, they wrote the user%s guide for a word processing system, then declared
that the user%s guide was the functional specification. #he developers were challenged to
create a product that matched what the user%s guide described.) #ypically, the functional
specification for an application program with a series of interactive windows and dialogs
with a user would show the visual appearance of the user interface and describe each of
the possible user input actions and the program response actions. ! functional
specification may also contain formal descriptions of user tasks, dependencies on other
products, and usability criteria. )any companies have a guide for developers that
describes what topics any product%s functional specification should contain. For a sense of
where the functional specification fits into the development process, here are a typical
series of steps in developing a software product* +e$uirements* #his is a formal statement
of what the product planners informed by their knowledge of the marketplace and specific
input from eisting or potential customers believe is needed for a new product or a new
version of an eisting product. +e$uirements are usually epressed in terms of narrative
statements and in a relatively general way. ,b&ectives* ,b&ectives are written by product
designers in response to the +e$uirements. #hey describe in a more specific way what the
product will look like. ,b&ectives may describe architectures, protocols, and standards to
which the product will conform. )easurable ob&ectives are those that set some criteria by
which the end product can be &udged. )easurability can be in terms of some inde of
customer satisfaction or in terms of capabilities and task times. ,b&ectives must recogni-e
time and resource constraints. #he development schedule is often part or a corollary of the
,b&ectives. Functional specification.* #he functional specification (usually functional
spec or &ust spec for short) is the formal response to the ob&ectives. It describes all
eternal user and programming interfaces that the product must support. .esign change
re$uests* #hroughout the development process, as the need for change to the functional
specification is recogni-ed, a formal change is described in a design change re$uest.
/ogic "pecification* #he structure of the programming (for eample, ma&or groups of
code modules that support a similar function), individual code modules and their
relationships, and the data parameters that they pass to each other may be described in a
formal document called a logic specification. #he logic specification describes internal
interfaces and is for use only by the developers, testers, and, later, to some etent, the
programmers that service the product and provide code fies to the field. 0ser
documentation* In general, all of the preceding documents (ecept the logic specification)
are used as source material for the technical manuals and online information (such as help
pages) that are prepared for the product%s users. #est plan* )ost development groups have
a formal test plan that describes test cases that will eercise the programming that is
written. #esting is done at the module (or unit) level, at the component level, and at the
system level in contet with other products. #his can be thought of as alpha testing. #he
plan may also allow for beta test. "ome companies provide an early version of the product
to a selected group of customers for testing in a 'real world' situation. #he Final 1roduct*
Ideally, the final product is a complete implementation of the functional specification and
design change re$uests, some of which may result from formal testing and beta testing.
#he cycle is then repeated for the net version of the product, beginning with a new
+e$uirements statement, which ideally uses feedback from customers about the current
product to determine what customers need or want net. )ost software makers adhere to
a formal development process similar to the one described above. #he hardware
development process is similar but includes some additional considerations for the
outsourcing of parts and verification of the manufacturing process itself. 2ope the above
helps you.
2i,
;ormally Functional specification is for any new development.
for 5. if u have to create "ales +egister then u have to given fuction specification
related to that new report as per customer re$uired.
In the Functional specification u have to give the inputs to abaper related to new
development,like field name,table name,logic..etc.
Functional "pecification
! functional specification (or sometimes functional specifications) is a formal document
used to describe in detail for software developers a product%s intended capabilities,
appearance, and interactions with users. #he functional specification is a kind of
guideline and continuing reference point as the developers write the programming code.
(!t least one ma&or product development group used a '(rite the manual first'
approach. Before the product eisted, they wrote the user%s guide for a word processing
system, then declared that the user%s guide was the functional specification. #he
developers were challenged to create a product that matched what the user%s guide
described.) #ypically, the functional specification for an application program with a
series of interactive windows and dialogs with a user would show the visual appearance
of the user interface and describe each of the possible user input actions and the program
response actions. ! functional specification may also contain formal descriptions of user
tasks, dependencies on other products, and usability criteria. )any companies have a
guide for developers that describes what topics any product%s functional specification
should contain.
F0;4#I,;!/ "154IFI4!#I,;" means you have to give the 4,)1+525;"I35
.,40)5;# of your re$uirement with logic
It will brief the re$uirement and its design how the ,b&ect ( such as I;3,I45")
should work
I will brief by an illustration..
/et say you are working on the re$uirements of I;3,I45 /!<,0#" from Fnctional
specifications and you have all the .esing of /ayout .
<ou have to tell !B!1er on how to fetch the .ata from different field and the /ogic
for retrieving the .ata from #ables.
for example if you want to print the ACCOUNTING DOCUMENT number on
the invoice you have to tell him to fetch the !ale" or#er number from the $%A&
'$%E(N an# )oto $%*A to )et the %illin) #ocument number an# now )oto the
Table
$%+&'%E(N+ to )et the accountin) #ocu
;ormally Functional specification is for any new development.
for 5. if u have to create "ales +egister then u have to given fuction specification
related to that new report as per customer re$uired.
In the Functional specification u have to give the inputs to abaper related to new
development,like field name,table name,logic..etc.
Functional "pecification
! functional specification (or sometimes functional specifications) is a formal document
used to describe in detail for software developers a product%s intended capabilities,
appearance, and interactions with users. #he functional specification is a kind of
guideline and continuing reference point as the developers write the programming code.
(!t least one ma&or product development group used a '(rite the manual first'
approach. Before the product eisted, they wrote the user%s guide for a word processing
system, then declared that the user%s guide was the functional specification. #he
developers were challenged to create a product that matched what the user%s guide
described.) #ypically, the functional specification for an application program with a
series of interactive windows and dialogs with a user would show the visual appearance
of the user interface and describe each of the possible user input actions and the program
response actions. ! functional specification may also contain formal descriptions of user
tasks, dependencies on other products, and usability criteria. )any companies have a
guide for developers that describes what topics any product%s functional specification
should contain.
Func "pec basically contains the information about the business process which needs to
be mapped on to the I# system ("!1). It encompasses all the related function points
which will be part of the business process.
It also mentions the programs or utilities which can be enhanced6modified6copied to
achieve the end result (in case the functional consultant is aware of the program6utility)
Function "pecs is a document which a functional consultant prepares to be given to
!baper. #his .ocument contains details like #ables 9 fields name, #able &oints, /ogic for
development, along with test case in sand bo 6 test server to verify the development.
Format for Functional "pecs*
.ocument 4ontrol
4hange 2istory
Issue ;o
.ate
;ame
4hange
Initial .raft
!uthori-ations
+ole
;ame
"igned
.ate
Business 1rocess /ead (customer)
Functional !nalyst (specification author)
#echnical /ead
.eveloper (if known)
"elect program type below and then use menu option tools B unprotect to
open other fields for input
#ype
#able of 4ontents
.ocument 4ontrol 8
,verview. @
8.8 "hort .escription. @
8.? Business 1rocess. @
8.@ #erminology. @
8.C ;ew 4ustom ,b&ects +e$uired. @
8.D Impacted "!1 #ransactions6#ables. C
1rocess .ecomposition. D
?.8 1rocess Flow. D
?.? ;ew #ables6"tructures +e$uired. D
?.@ "ub-1rocess .escription. D
?.C 5rror 2andling. D
?.D "ecurity 4onsiderations. D
?.E .atabase 4onsiderations. D
?.F 4onversion Implications. D
?.G Batch 1rocessing. E
?.H Functional #est +e$uirements. E
,verview
8.8 "hort .escription
8.? Business 1rocess
8.@ #erminology
8.C ;ew 4ustom ,b&ects +e$uired
Include all new tables, key new fields6domains, new lock ob&ects, new
match-codes, new transaction codes, new authori-ation ob&ects, new
function groups, reports and module pools (transaction programs). .on%t
specify all includes, function modules, routines etc. here.
#ype (table, transaction etc.)
.escription
;aming convention
8.D Impacted "!1 #ransactions6#ables
/ist "!1 ob&ects updated6impacted by this specification (do not include
read only impacts)
,b&ect(s)
#ype (table, transaction etc.)
.escription of Impact
1rocess .ecomposition
?.8 1rocess Flow
?.? ;ew #ables6"tructures +e$uired
"pecify new tables and structures re$uired. If appropriate, you may
defer detailed field list6specification to the technical specification
(e.g. for secondary tables and structures).
#able id
.escription
#ype
)aster, transaction, customi-ing, staging
5pected si-e
)aint. dialog
;one, ")@A, custom
Fields
Iey
.omain6data element names
.omain format (if new)
.escription
?.@ "ub-1rocess .escriptio
?.C 5rror 2andling
"pecify what to do if a condition passes !;. fails (e.g. - what happens if a customer
record is found, or is not found). "pecify messages and type.
"pecify any special error logging or table storage, including use of standard application
log where appropriate.
Field
3alidation
)essage type6no.
)essage tet
?.D "ecurity 4onsiderations
?.E .atabase 4onsiderations
?.F 4onversion Implications
?.G Batch 1rocessing
?.H Functional #est +e$uirements
4onsider all the conditions that need testing for this enhancement and document below.
For each logic branch in theory both (or more) conditions of the branch should be tested.
For each scenario that could impact program eecution, all situations must be tested.
;o.
#est condition
5pected result
.ata set-up re$t.
.ependencies
2ere i am eplaining what is functional specs and what are the contents of it.
*unctional !pec",
#o speak at macro level that is at pro&ect manager or at senior levels. #he Functional "pec
("pecification) which is a comprehensive document is created after the ("+") "oftware
+e$uirements .ocument. It provides more details on selected items originally described
in the "oftware +e$uirements #emplate. 5lsewhere organi-ations combine these two
documents into a single document.
#he Functional "pecification describes the features of the desired functionality. It
describes the product%s features as seen by the stake holders, and contains the technical
information and the data needed for the design and development.
#he Functional "pecification defines what the functionality will be of a particular area
that is to be precise a transaction in "!1 terminology.
#he Functional "pecification document to create a detailed design document that eplains
in detail how the software will be designed and developed.
#he functional specification translates the "oftware +e$uirements template into a
technical description which
a) 5nsures that the product feature re$uirements are correctly understood before moving
into the net step that is technical development process.
b) 4learly and unambiguously provides all the information necessary for the technical
consultants to develop the ob&ects.
!t the consultant level the functional specs are prepared by functional consultants on any
functionality for the purpose of getting the same functionality designed by the technical
people as most of the times the functionalities according to the re$uirements of the clients
are not available on ready made basis.
/et me throw some light on documentation which is prepared before and in a pro&ect*
8) #emplates
?) 2eat !nalysis -
@) Fit Jap or Jap !nalysis
C) Business 1rocess .esign
D) Business 1rocess )odel
E) Business 4hange 9 Impact
F) 4onfiguration .esign, which is &ust D K of #otal "!1- have different names -
G) Future Impact 9 4hange !ssessment
H) Functional .esign ()odule (ise)
8A) +isk !ssessment
88) 1rocess )etrics and )any )ore-- (hich has impact on Business and its work flow
2ope it is useful
+eward points if helpful...
(hat !re Functional "pecification in "!1L
#o speak at macro level that is at pro&et manager or at senior levels. #he Functional "pec
("pecification) which is a comprehensive document is created after the ("+") "oftware
+e$uirements .ocument. It provides more details on selected items originally described
in the "oftware +e$uirements #emplate. 5lsewhre organi-ations combine these two
documents into a single document.
#he Functional "pecification describes the features of the desired functinality.. It
describes the product%s features as seen by the stake holders,and contains the technical
information and the data needed for the design and developement.
#he Functional "pecification defines what the functionality will be of a particulat area
that is to be precise a transaction in "!1 terminology.
#he Functional "pecification document to create a detailed design document that eplains
in detail how the software will be designed and developed.
#he functional specification translates the "oftware +e$uirements template into a
technical description which
a) 5nsures that the product feature re$uirements are correctly understood before moving
into the net step, that is detchnical developement process.
b) 4learly and unambiguously provides all the information necessary for the technical
consultants to develop the ob&ects.
!t the consultant level the functional spects are preapred by functinal consultants on any
functionality for the purpose of getting the same functinality designed by the technical
pepole as most of the times the functionalities according to the re$uirements of the clients
are not available on ready made basis.
/et me throw some light on documentation which is prepared before and in a pro&ect*
8) #emplates
?) 2eat !nalysis -
@) Fit Jap or Jap !nalysis
C) Business 1rocess .esign
D) Business 1rocess )odel
E) Business 4hange 9 Impact
F) 4onfiguration .esign, which is &ust D K of #otal "!1- have different names -
G) Future Impact 9 4hange !ssessement
H) Functional .esign ()odule (ise)
8A) +isk !ssessement
88) 1rocess )etrics and )any )ore-- (hich has impact on Business and its work flow
;ote M #his documents are preapared in 3anilla "!1 "tandards -- #hings differ from one
implementation to another, and it always depends on the type of business which is opting
for "!1.
2ope this helps you.
Functional "pec* F" is a document written by the functional guy to communicate to the
!B!1er, to say what development needs to be carried out and what are the tables and
fields involved. #he basic reason for a functional spec would be that of documentation
and reference and importantly the technical guys wouldn=t really know the business
process but only the tables and fields involved. "o the functional guy communicates the
business re$uirement in technical way through a functional spec. Features of a F" would
be that it will have a version number which would change depending on the modifications
made to that particular ob&ect there after. #here would be a pseudo logic which outlines
what needs to be done for data etraction, tables and fields to be used, validations, testing
info .,
! functional spec is a document which provides the logic to carry out the development.
#his document contains logic to be followed 9 the table from which the data is to be
picked. It also contains details of which are the connecting table 9 how the fields are to
be mapped
what are Functional "pecification in "!1L
#o speak at macro level that is at pro&ect manager or at senior levels. #he Functional "pec
("pecification) which is a comprehensive document is created after the ("+") "oftware
+e$uirements .ocument. It provides more details on selected items originally described
in the "oftware +e$uirements #emplate. 5lsewhere organi-ations combine these two
documents into a single document.
#he Functional "pecification describes the features of the desired functionality.. It
describes the product%s features as seen by the stake holders, and contains the technical
information and the data needed for the design and development.
#he Functional "pecification defines what the functionality will be of a particular area
that is to be precise a transaction in "!1 terminology.
#he Functional "pecification document to create a detailed design document that eplains
in detail how the software will be designed and developed.
#he functional specification translates the "oftware +e$uirements template into a
technical description which
a) 5nsures that the product feature re$uirements are correctly understood before moving
into the net step, which is technical development process.
b) 4learly and unambiguously provides all the information necessary for the technical
consultants to develop the ob&ects.
!t the consultant level the functional sects are prepared by functional consultants on any
functionality for the purpose of getting the same functionality designed by the technical
people as most of the times the functionalities according to the re$uirements of the clients
are not available on ready made basis.
/et me throw some light on documentation which is prepared before and in a pro&ect*
8) #emplates
?) 2eat !nalysis -
@) Fit Jap or Jap !nalysis
C) Business 1rocess .esign
D) Business 1rocess )odel
E) Business 4hange 9 Impact
F) 4onfiguration .esign, which is &ust D K of #otal "!1- have different names -
G) Future Impact 9 4hange !ssessment
H) Functional .esign ()odule (ise)
8A) +isk !ssessment
88) 1rocess )etrics and )any )ore-- (hich has impact on Business and its work flow
rewards if it helps
Functional Specs concept varies from Client to Client. The Standard Concept of Functional Specs
in SAP is that it is a document, which will contain the details of the requirement for development
purpose. It will include important parameters such as:
1. Compan!s "ame
#. Topic of Functional specs
$. Created %
&. 'eviewed %
(. Creation date
). 'evised date * version +it ma also contain a %reif information a%out revision , modification
done-
.. Purpose of Functional Specs
/. 'equirement of client
0. 1o2ic to arrive at the requirement, alon2 with details of Ta%les3fields * lin4s %etween ta%les.
15. Provision for capturin2 test cases
The a%ove are the few, which can %e recollected upfront.
follow and prepare as per below contents,
#!B/5 ,F 4,;#5;#"
8. 1rogram Information
?. Functional "pecification
@. .etail description
@.8 #he Functional "olution - .etail /ogic
@.? 1rogramme #ype 6 #iming
@.@ Impact of change on the system
@.C !ssumptions
@.D !uthorisation
@.E ,ther Issues
@.F 5rror 1rocessing
@.G !dditional Information
@.H #esting
@.8A 0ser !cceptance 4riteria
C. #echnical implementation
C.8 Inputs*
C.? ,utputs*
C.@ +eporting*
C.C 3alidation*
C.D #echnical Flow
C.E #ransaction for enhancement
D. !uthori-ation checks
D.8 ,b&ects which should be checked
D.? "ensitivity of +eport
Functional "pecification Format
!uthori-ation ;ame- #ech 4onsultant !pproval .ate
!pproval ;ame- Functional 4onsultant
8. "olution Information
a) 4ompany-
b) +elease-
?.,b&ect Information
a) ,b&ect field
b) Functional "pecification type- +eports6Interface enhancement
c) "tatus- !pproved6;ot !pproved
d) #est "cenariao-
e) 1riority- 2igh6/ow6)edium ,r 8 ? @
f) 4ompleity--
g) 4leint start .ate--
h) 4lent 5nd .ate--
@. +evision 2istory--
+ev ;o--+ev .ate-- 0ser--.escription
C..escription or 1urpose
a) .escription or purpose---2ere follows a complete description what Functionality this
specification is going to perform
b) Business proess details-- 2ere follows the description of business process onvolved
c) 4urrent Functionality--
d) .ecide Functionality---
+eplay
Functional specifications (functional specs), in the end, are the blueprint for how you
want a particular report and transaction to look and work. It details what the report will
do, how a user will interact with it, and what it will look like. By creating a blueprint of
the report or transaction first, time and productivity are saved during the development
stage because the programmers can program instead of also working out the logic of the
user-eperience. It will also enable you to manage the epectations of your clients or
management, as they will know eactly what to epect.
! key benefit of writing up a Functional "pec is in streamlining the development process.
#he developer working from the spec has, ideally, all of their $uestions answered about
the report or transaction and can start building it. !nd since this is a spec that was
approved by the client, they are building nothing less than what the client is epecting.
#here should be nothing left to guess or interpret when the spec is completed.
*unctional !pecification
! functional specification (or sometimes functional specifications) is a formal document
used to describe in detail for software developers a product%s intended capabilities,
appearance, and interactions with users. #he functional specification is a kind of
guideline and continuing reference point as the developers write the programming code.
(!t least one ma&or product development group used a '(rite the manual first' approach.
Before the product eisted, they wrote the user%s guide for a word processing system, then
declared that the user%s guide was the functional specification. #he developers were
challenged to create a product that matched what the user%s guide described.) #ypically,
the functional specification for an application program with a series of interactive
windows and dialogs with a user would show the visual appearance of the user interface
and describe each of the possible user input actions and the program response actions. !
functional specification may also contain formal descriptions of user tasks, dependencies
on other products, and usability criteria. )any companies have a guide for developers
that describes what topics any product%s functional specification should contain.
For a sense of where the functional specification fits into the development process, here
are a typical series of steps in developing a software product*
+e-uirement",
#his is a formal statement of what the product planners informed by their knowledge of
the marketplace and specific input from eisting or potential customers believe is needed
for a new product or a new version of an eisting product. +e$uirements are usually
epressed in terms of narrative statements and in a relatively general way.
Ob.ective", ,b&ectives are written by product designers in response to the +e$uirements.
#hey describe in a more specific way what the product will look like. ,b&ectives may
describe architectures, protocols, and standards to which the product will conform.
)easurable ob&ectives are those that set some criteria by which the end product can be
&udged. )easurability can be in terms of some inde of customer satisfaction or in terms
of capabilities and task times. ,b&ectives must recogni-e time and resource constraints.
#he development schedule is often part or a corollary of the ,b&ectives.
Functional specification.* #he functional specification (usually functional spec or &ust
spec for short) is the formal response to the ob&ectives. It describes all eternal user and
programming interfaces that the product must support.
.esign change re$uests* #hroughout the development process, as the need for change to
the functional specification is recogni-ed, a formal change is described in a design
change re$uest.
(o)ic !pecification,
#he structure of the programming (for eample, ma&or groups of code modules that
support a similar function), individual code modules and their relationships, and the data
parameters that they pass to each other may be described in a formal document called a
logic specification. #he logic specification describes internal interfaces and is for use
only by the developers, testers, and, later, to some etent, the programmers that service
the product and provide code fies to the field.
U"er #ocumentation,
In general, all of the preceding documents (ecept the logic specification) are used as
source material for the technical manuals and online information (such as help pages) that
are prepared for the product%s users.
#est plan* )ost development groups have a formal test plan that describes test cases that
will eercise the programming that is written. #esting is done at the module (or unit)
level, at the component level, and at the system level in contet with other products. #his
can be thought of as alpha testing. #he plan may also allow for beta test. "ome companies
provide an early version of the product to a selected group of customers for testing in a
'real world' situation.
The *inal /ro#uct,
Ideally, the final product is a complete implementation of the functional specification and
design change re$uests, some of which may result from formal testing and beta testing.
#he cycle is then repeated for the net version of the product, beginning with a new
+e$uirements statement, which ideally uses feedback from customers about the current
product to determine what customers need or want net.
)ost software makers adhere to a formal development process similar to the one
described above. #he hardware development process is similar but includes some
additional considerations for the outsourcing of parts and verification of the
manufacturing process itself.
Comment"
how to convert function specs to technical specs,
please mail the details to mail id* nishanthvairagadeNgmail.com
By* O @A ;ov ?AAH
when we closed the month peread in a clint . after closing when we are go migo any new
order that a messeg is come your current moth not opening . #hat time what i can do .
1lease tel me
By* O ?? Pan ?A8A
.o you have an eample that can illustrate how this kind of document should look like L
if so can you email it to alfredb8DNyahoo.com
By* O 8C )ar ?A8A
Iindly also send a sample of the actual document to &osh.$aNhotmail.com. #hank you.
By* Pohn .oe O ?E )ar ?A8A
could you please send some sample of F" to grmeena8HFDNgmail.com, since it will be
useful for me to make a very good practise and gather idea &ust e$ual to
real time work.
By* O AF )ay ?A8A
please send me some of F"%s on interactive reporting ,!/3 reporting and on smart
forms....on my mail id-sandeepruhelaNhotmail.com,sangrtstrNgmail.com
i will be thank full for all of you
By* O ?H )ay ?A8A
2i ". 5perts,4an you share with me ?-C sample Functional "pecfications in "!1 ".
which you have worked on in your real time pro&ect. please send the above samples to my
e-mail id sivakumar.niceNgmail.com. 5pecting epress reply from your end. #hank
in advance....
I would be thankful for your timely help.
By* O ?H Pun ?A8A
It is very helpful. 1lease kindly send a sample of F". to tammielptNyahoo.com. #hanks
so muchQ
By* O AF Pul ?A8A
could you please send some sample of F" to akash?C?ENgmail.com, since it will be
useful for me to make a very good practise and gather idea &ust e$ual to
real time work.
B+66
+ofi$ue
By* O ?H Pul ?A8A
could you please send some sample of Functional specs to sumith@AAENgmail.com, since
it will be useful for me to make a very good practice and gather idea &ust e$ual to
real time work.
By* O A8 !ug ?A8A
hi its very urgent for me could you please send some sample of Functional specs to
shahedRsapNyahoo.com,
Best regards
"hahed
By* O A? !ug ?A8A
1lease, I need functional spec too close to asset ac$uisition through 4ash !dvance to
staff. "end to gbengabiola?AA@Nyahoo.com
#hanks
Jbenga
By* O 8? !ug ?A8A
hi friends ,
i need few funcational specations in fico please any body can sent to my mail.
kaparthiGENgmail.com
thank you
By* santhosh kaparthi O ?A !ug ?A8A
I need some functional specifications in fico please. Iindly send it to
bla.mcpheeNyahoo.com. #hanks
By* O ?A !ug ?A8A
I need some functional specifications in fico pl- send it to santhoshrao.aNgmail.com
By* O 8E "ep ?A8A
I need some functional spec%s in fico... !ny help would be appreciated.
1lease mail at &.shrenikNgmail.com
By* O AC ,ct ?A8A
2i,
4an any one share some F" related to FI4, and !).
please send them to mal id*ra&eshR&astiNrediffmail.com.
thanks
ra&esh P
By* O ?A ;ov ?A8A
2,( #, )!I5 F0;4#I,;!/ "154IFI4!#I,;" F,+ )!#5+I!/ )!"#5+,IF
"011,"5 I (!;# #, )!I5 ! ;5( )!#5+I!/ (25+5 !" I (,0/. /II5 #,
I;10# #25 ;!)5 ,F #25 +5705"#5+ F,+ (2,) I !) 4+5!#I;J #25
)!#5+I!/, ", 4!; <,0 1/5!"5 +51/< )5 2,( #, )!I5 #25
F0;4#I,;!/ "154IFI4!#I,;..................
By* O AH .ec ?A8A
kindly send me some functional specification for material mngt, sd,fi.
1lease send it on email id sadi$ahmedcseNgmail.com
By* O 8D .ec ?A8A
kindly send me some functional specification for "!1 ".
1lease send it on email id papriyatamNgmail.com
By* O A8 Pan ?A8A
Iindy send me some functional specification for 2+ if available via
cleanRwcNhotmail.com. #hanks *)
List of all the important tables used in Sales and Distribution (SD) :
6TFA Flow shippin2 documents
67P68 9eliver 9ue Inde:
Sales order :
6;A< =eader data
6;AP Item data
6;PA Partners in sales order
6;<9 Sales district data
6;7P 9ata related to deliver line items
Billing document :
6;'< header data
6;'P Item data
Shipping :
6TT< Shipment header
6TTP Shipment item
6TTS Sta2e in transport
6TSP Sta2e in transport per shipment item
6TPA Shipment partners
67<P =andlin2 >nit 3 =eader Ta%le
67P? Pac4in2: =andlin2 >nit Item +Contents-
SD Delivery Documet :
1I<P 9eliver header
1IPS 9eliver item
Pricing :
<?"= Conditions header
<?"P Conditions items
<?"6 Procedure + %illin2 doc or sales order-
<?"9
Contracts :
679A Contract data
Customers
<"A1 8eneral 9ata
<";1 Customer @aster A Co. Code 9ata +pament method, reconciliation acct-
<";& Customer Pament =istor
<";( Customer @aster A 9unnin2 info
<";< Customer @aster ;an4 9ata
<"<A Customer @aster Credit @2mt.
<"<< Customer @aster Credit Control Area 9ata +credit limits-
<"66 Sales Area 9ata +terms, order pro%a%ilit-
<"6I Customer @aster Ta: Indicator
<"6P Partner Function 4e
<"69 ?utput tpe
<"6S Customer @aster Ship 9ata
<1PA Customer,6endor 1in4

Sales Documents
6;A<>< 6;A< B 6;><
6;>< =eader Status and Administrative 9ata
6;A< Sales 9ocument 3 =eader 9ata
6;<9 Sales 9ocument 3 ;usiness 9ata
6;>P Item Status
6;AP Sales 9ocument 3 Item 9ata
6;PA Partners
6;FA 9ocument Flow
6;7P Sales 9ocument Schedule 1ine
6;;7 Sales 'equirements: Individual 'ecords
Invoice Split Criteria for Invoice Lists
)ultiple Invoices are combined into an invoice list however, more than one invoice list is
created.
Invoice /ist "plits occur because of different header partners (bill-to parties and payers,
table 3B1!) or, primarily due to different header fields (table 3B+I).
#he 8st step in resolving issues with invoice splits is to simply compare !// header
fields, i.e. the entries in tables 3B+I and 3B1!. <ou can use transaction "58E or "58F
to compare the entries in these tables for invoices or invoice lists.
5specially the following header fields could cause invoices to split into multiple invoice
lists.
01 %illin) Date for the invoice li"t 2$%+&'*&DAT3+(1
.ifferent Billing .ates for the invoice list from the original invoices will automatically
cause invoices to split into multiple invoice lists. #his is standard functionality. #he
primary way to avoid this is to enter a date as a default billing date in transaction 3F?8 or
to modify
the report from tra$nsaction 3F?C.
If you do not enter a default billing date and the dates from the individual invoices differ,
than the invoice lists will be split into as many invoice lists as there are different dates.
41 Tran"lation Date 2$%+&'&U++*3DAT new a" of relea"e 5671
#he echange rate date is determined in the order header by the pricing date. #his date
can be copied into the invoice or, redetermined at the time of invoice creation based on
the copy control settings. #he implementation of note 8EGGDA will avoid this problem.
<ou can also check that note 88DD?G is installed if you are on C.AB.
81 Ori)in "l"6tax no6 2$%+&'!TCEG391
#he implementation of note 8C8HFG will avoid this problem if the split would not be
&ustifiable.
51 All other hea#er fiel# may al"o cau"e a "plit with the exception
of*
3B+I-I;0)3
3B+I-;5#(+
3B+I-)("BI
3B+I-3B5/;
3B+I-+FB"I
3B+I-5+;!)
3B+I-!5.!#
3B+I-5+.!#
3B+I-5+:5#
#he relevant coding can be found in program /3EA!FAS,
F,+) S3B+IRB5!+B5I#5;*
...
/,,1 !# S3B+I.
B5/5J T S3B+I-3B5/;.
S3B+I-;5#(+ T A. 'aus 3ergleich ausnehmen
S3B+I-)("BI T A. 'aus 3ergleich ausnehmen
S3B+I-3B5/; T "1!45. ' '
S3B+I-+FB"I T 3B+I-+FB"I. ' '
S3B+I-5+;!) T 3B+I-5+;!). ' '
S3B+I-!5.!# T 3B+I-!5.!#. ' '
S3B+I-5+.!# T 3B+I-5+.!#. ' '
S3B+I-5+:5# T 3B+I-5+:5#. ' '
...
#he only possibility to avoid a split caused by different entries in table 3B+I with the
eception of the fields listed above, is to initiali-e the entries in a own data transport
routine in the copy control of the affected billing document types. ,f course the
information stored in these fields will then be lost in the invoice list.
Grouping sales order and export delivery in a
billing document.
It i" po""ible to )roup export #eliverie" in a billin) #ocument if the determination of
the foreign trade segment in the copying control table is set to %!% (4opy foreign trade
data of the delivery) or %B% (+edetermine foreign trade data).
It i" po""ible to )roup "ale" or#er" an# #eliverie" in a billin) #ocument, providing no
split is initiali-ed by different header fields or header partners.
4ustomi-ing in the copying control table (#341F)*
.etermine foreign trade segment (field name in +el.@.A)
.etermine eport segment (field name in +el.?.?)
8st case * #he field %.et. foreign trade segment% (or %.et. eport segment%) is set
differently in the sales order and in the eport delivery*
--B Billing split due to different eport indicators
?nd case * #he field %.et. foreign trade segment% (or %.et. eport segment%) is set to % % in
the sales order and in the eport delivery*
--B Billing split due to different eport indicators
(% % in the sales order and %S% in the eport delivery)
@rd 4ase * #he field %.et. foreign trade segment% (or %.et. eport segment%) is set to %!% in
the sales order and in the eport delivery*
--B no split due to eport indicator or eport segment numberU the eport data of
the order item was redetermined in the billing document
Cth 4ase* #he field %.et. foreign trade segment% (or %.et. eport segment%) is set to %B% in
the sales order and in the eport delivery*
--B no split due to eport indicator or eport segment numberU the eport data of
the order item was redetermined in the billing document
Note,
If eport fields should eplicitly initiali-e a billing document split (for eample, different
country of origin), you have to create a corresponding data transport routine.
Collective billing for order-related and
delivery-related items
Collective %illin),
4ollective Billing combines different documents (orders 6 deliveries) into a single Invoice
document provided certain data specified is common across these source documents. #he
2eader data appearing in billing document must be same.4ollective billing is not possible
for a sales order and an eport delivery. 4ollective billing can only be carried out for
domestic business affairs.#he transaction code for collective billing is via $*75.
Collective billin) for or#er'relate# an# #elivery'relate# item" ,
If you create a sales order with an item which is relevant for billing by delivery and an
item which is relevant for billing by the sales order up to now the items could not be
grouped together in a billing document.
,rder releted billing is done when we proceed directly to the billing from order while
doing only the 1JI.eg Ca"h "ale"
.elivery releted billing is the normal sales cycle where we go to dilivery from order and
then to the invoice from delivery.eg normal sales cycle ru"h or#er.
06 /roblem" with the billin) #ate
If a sales order and a delivery are billed together and the date of the sales order (proposal
for the billing date) is not e$ual to the goods issue date (proposal for the billing date),
there is a problem with specifying the billing date. If a common billing date is not
determined, an invoice split is created.
#his problem can be avoided if you specify a default date when creating the billing
document.
#his problem generally does not occur for period calculations.
<ou can determine a common billing date (for eample, the current date) by creating a
new data copying routine (for eample, by copying routine %AA8%).
0sing transaction 3,F) and menu path '.ata transfer -B Billing documents', you can
copy the data transport routine and change it as follows *
form datenRkopierenR.
*