Upload
raghu-manly
View
213
Download
0
Embed Size (px)
Citation preview
7/29/2019 A functional specification.doc
1/4
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.
The functional specification is a kind of guideline and continuing reference point as the developers write
the programming code. (At least one major product development group used a "Write the manual first"
approach. Before the product existed, they wrote the user's guide for a word processing system, thendeclared that the user's guide was the functional specification. The developers were challenged to create a
product that matched what the user's guide described.) Typically, the functional specification for anapplication 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. Many 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:
Requirements. This 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. Requirements are usually expressed in terms of narrative
statements and in a relatively general way.
Objectives. Objectives are written by product designers in response to the Requirements. They describe in
a more specific way what the product will look like. Objectives may describe architectures, protocols, and
standards to which the product will conform. Measurable objectives are those that set some criteria bywhich the end product can be judged. Measurability can be in terms of some index of customer
satisfaction or in terms of capabilities and task times. Objectives must recognize time and resource
constraints. The development schedule is often part or a corollary of the Objectives.
Functional specification. The functional specification (usually functional spec or just spec for short) is the
formal response to the objectives. It describes all external user and programming interfaces that the
product must support.
Design change requests. Throughout the development process, as the need for change to the functionalspecification is recognized, a formal change is described in a design change request.
Logic specification. The structure of the programming (for example, major 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. The logic
specification describes internal interfaces and is for use only by the developers, testers, and, later, to someextent, 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 preparedfor the product's users.
Test plan. Most development groups have a formal test plan that describes test cases that will exercise theprogramming that is written. Testing is done at the module (or unit) level, at the component level, and at
the system level in context with other products. This can be thought of as alpha testing. The plan may also
allow for beta test. Some 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 requests, some of which may result from formal testing and beta testing.
7/29/2019 A functional specification.doc
2/4
The cycle is then repeated for the next version of the product, beginning with a new Requirements
statement, which ideally uses feedback from customers about the current product to determine what
customers need or want next.
Most software makers adhere to a formal development process similar to the one described above. Thehardware development process is similar but includes some additional considerations for the outsourcing
of parts and verification of the manufacturing process itself.
Functional Specs is a document prepared by the functional consultant for any work which he wants to be
executed by the technical person (ABAB).
For Example if you want to create a new report then you have to give certain info to the ABAP Guy, like
Input Screen Fields - Details of Table and Fields fromk which data would be fetched
Output Screen Fields - Details of Table and Fields fromk which data would be fetched
Layout of Report
You also have to give the logic on which the report shall work.
You can easily get Templates for FS on the net.
How to write functional specification in SAP?
Functional specification comes next only to configuration when it comes to functional consultants job and
without mastering it your SAP experience is incomplete. A poorly written functional spec creates big
communication issue between technical andSAP functional consultant and the matter is further
compounded when they are not sitting at same location. You can only imagine the mess it will create if
the functional spec is not properly written and the technical guy is sitting in different country and worse
still his spoken English is not good (e.g. Chinese, French, Korean etc. ).
Functional specs are written when the standard SAP is not able to meet the client's requirement. Based on
the functional spec the ABAPer will write the technical design doc. and then the functional guy will test
the same in the system and document the results in his test script.
We come across 3 situations which calls for functional specs to be written:
1. Enhancements /modifications. If business requires some special procedure.
2. Reports, Client's customized reports.
3. Interface, EDI interface involves ALE/IDOC.
Here are some tips to write great functional specs. The objective should be that the technical guy should
understand it in one go and to reduce any further clarification.
1. Understand the requirement completely. This will depend on your business understanding. Make sure
that the client's requirement cannot be met through standard SAP before working on it. Please suggest the
client if any alternative business process which is supported by SAP and meets his requirement too.
http://www.erpgreat.com/general/role-of-a-sap-functional-consultant.htmhttp://www.erpgreat.com/general/role-of-a-sap-functional-consultant.htmhttp://www.erpgreat.com/general/role-of-a-sap-functional-consultant.htm7/29/2019 A functional specification.doc
3/4
2. In case of reports you must be competent to decide whether it's a R/3 orSAP BW report. one example -
if the report involves data analytics (like you do in pivot table of excel) it will be a BW report. However
its data collection will be done in R/3.
3. You must mention the business need and business value the report/enhancement will add to the
business. This is for future reference and also to convince the other users.
4. Any legacy system changes to be done once the enhancement/report is run should also be mentioned.
You can mention changes regarding business process or data. This may be an input for change
management team and also for cut-over strategy.
5. In case of interface please do mention if it's a display or non display document.
6. Please do not write the structure in place of table and field. Make some effort and find out in which
field the data is stored. ABAPer will appreciate it.
7. Don't just write table and field name but also give the data pulling logic. This is perhaps the most
important part. At times it is really difficult to make the technical guy understand how the data is gettingpulled. Without understanding this he can't proceed further. For example
Target quantity - PACKPO-TRGQTY needs to be transported to Rounding quantity VBAP- ABLFZ
The data pulling logic for the same will as follows
VBAK-VBLEN doc cat E= VBAP-VBLEN
VBAP-MATNR= PACKPO-MATNR Item cat M
8. Be careful about the data volume while designing the input screen of a customized report. You must
very carefully decide which of these should be mandatory and optional else it will create a performanceissue at the time of load testing.
Please note that every implementation has its own unique format for writing functional specs however the
above mentioned points needs to be covered to make it more communicative and effective.
How to write functional specification in SAP?
Functional specification comes next only to configuration when it comes to functional consultants job and
without mastering it your SAP experience is incomplete. A poorly written functional spec creates big
communication issue between technical andSAP functional consultant and the matter is furthercompounded when they are not sitting at same location. You can only imagine the mess it will create if
the functional spec is not properly written and the technical guy is sitting in different country and worsestill his spoken English is not good (e.g. Chinese, French, Korean etc. ).
Functional specs are written when the standard SAP is not able to meet the client's requirement. Based on
the functional spec the ABAPer will write the technical design doc. and then the functional guy will test
the same in the system and document the results in his test script.
We come across 3 situations which calls for functional specs to be written:
http://www.erpgreat.com/sap-bw.htmhttp://www.erpgreat.com/general/role-of-a-sap-functional-consultant.htmhttp://www.erpgreat.com/general/role-of-a-sap-functional-consultant.htmhttp://www.erpgreat.com/sap-bw.htmhttp://www.erpgreat.com/general/role-of-a-sap-functional-consultant.htm7/29/2019 A functional specification.doc
4/4
1. Enhancements /modifications. If business requires some special procedure.
2. Reports, Client's customized reports.
3. Interface, EDI interface involves ALE/IDOC.
Here are some tips to write great functional specs. The objective should be that the technical guy should
understand it in one go and to reduce any further clarification.
1. Understand the requirement completely. This will depend on your business understanding. Make sure
that the client's requirement cannot be met through standard SAP before working on it. Please suggest the
client if any alternative business process which is supported by SAP and meets his requirement too.
2. In case of reports you must be competent to decide whether it's a R/3 orSAP BW report. one example -
if the report involves data analytics (like you do in pivot table of excel) it will be a BW report. However
its data collection will be done in R/3.
3. You must mention the business need and business value the report/enhancement will add to thebusiness. This is for future reference and also to convince the other users.
4. Any legacy system changes to be done once the enhancement/report is run should also be mentioned.
You can mention changes regarding business process or data. This may be an input for change
management team and also for cut-over strategy.
5. In case of interface please do mention if it's a display or non display document.
6. Please do not write the structure in place of table and field. Make some effort and find out in which
field the data is stored. ABAPer will appreciate it.
7. Don't just write table and field name but also give the data pulling logic. This is perhaps the mostimportant part. At times it is really difficult to make the technical guy understand how the data is getting
pulled. Without understanding this he can't proceed further. For example
Target quantity - PACKPO-TRGQTY needs to be transported to Rounding quantity VBAP- ABLFZ
The data pulling logic for the same will as follows
VBAK-VBLEN doc cat E= VBAP-VBLEN
VBAP-MATNR= PACKPO-MATNR Item cat M
8. Be careful about the data volume while designing the input screen of a customized report. You must
very carefully decide which of these should be mandatory and optional else it will create a performance
issue at the time of load testing.
Please note that every implementation has its own unique format for writing functional specs however the
above mentioned points needs to be covered to make it more communicative and effective.
http://www.erpgreat.com/sap-bw.htmhttp://www.erpgreat.com/sap-bw.htm