Functional Specification: Interfaces, Conversions, Enhancements, Forms - in Other Words, Anything
Functional Specification: Interfaces, Conversions, Enhancements, Forms - in Other Words, Anything
Functional Specification: Interfaces, Conversions, Enhancements, Forms - in Other Words, Anything
The document should paint a clear picture of the required outcome in the
system. The goal of the document is to:
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.
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.
2. In case of reports you must be competent to decide whether it's a R/3 or SAP
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.
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 getting pulled. Without understanding
this he can't proceed further. For example
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.