Functional Specification

What are functional specification why and how you write them?

What Is A Functional Specification?

Functional specifications (functional specs), in the end, are the blueprint for how you want a particular transaction or report to look and work. It details what the report or transaction will do, how a user will interact with it, and what it will look like. By creating a blueprint of this 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.

Why write a Functional Specification?

A key benefit of writing up a Functional Specification is in streamlining the development process. The developer working from the specifications ideally has, all of their questions answered about the application and can start building it. And since this is a specification that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed...and this, in a nut shell, explains the Functional Specifications.

The Function specification has the pseudo code of the program, the logic how the report or transaction should work and what the tables to be used.

It should define the business need and business functionality of the report or transaction and the criticalities if this report or transaction fails.

It should have the work around solution in case of emergency.

What Are Functional Specification in SAP?

To speak at macro level that is at project manager or at senior levels. The Functional Spec (Specification) which is a comprehensive document is created after the (SRS) Software Requirements Document. It provides more details on selected items originally described in the Software Requirements Template. Elsewhere organizations combine these two documents into a single document.

The Functional Specification 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.

The Functional Specification defines what the functionality will be of a particular area that is to be precise a transaction in SAP terminology.

The Functional Specification document to create a detailed design document that explains in detail how the software will be designed and developed.

The functional specification translates the Software Requirements template into a technical description which

a) Ensures that the product feature requirements are correctly understood before moving into the next step, that is the technical development process.

b) Clearly and unambiguously provides all the information necessary for the technical consultants to develop the objects.

At the consultant level the functional specifications 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 requirements of the clients are not available on readymade basis.

Let me throw some light on documentation which is prepared before and in a project:

1) Templates

2) Heat Analysis -

3) Fit Gap or Gap Analysis

4) Business Process Design

5) Business Process Model

6) Business Change & Impact

7) Configuration Design, which is just 5 % of Total SAP- have different names -

8) Future Impact & Change Assessment

9) Functional Design (Module Wise)

10) Risk Assessment

11) Process Metrics and Many More-- Which has impact on Business and its work flow.

Notes: These documents are prepared in Vanilla SAP Standards -- Things differ from one implementation to another, and it always depends on the type of business which is opting for SAP. 

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 and SAP functional consultant and the matter is further compounded when they are not sitting at the same location. You can only imagine the mess it will create if the functional specifications are not properly written and the technical consultant is sitting in a different country and worse still his spoken English is not as good as it should be (example: Any other language, other than English). 

Functional specs are written when the standard SAP is not able to meet the client's requirement. Based on the functional specifications the senior consultant or the ABAPer will write the technical design document and then the functional consultant will test the same in the system and document the results in his test script. 

We come across 3 situations which call for functional specifications to be written:

1. Enhancements /modifications. If business requires some special procedure. 

2. New Reports, Client's customized reports. 

3. Interface, EDI interface involves ALE/IDOC. 

Here are some tips to write great functional specifications. The objective should be that the technical consultant 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 standard SAP or SAP Business Warehouse report,  an 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 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.