SAP Functional Specification

The SAP functional specification, affectionately referred to as functional spec, is critical to the development of RICEF objects. RICEF stands for Reports, Interfaces, Conversions, Enhancements, Forms — in other words, anything that requires programming in SAP. This post will delve into the purpose and content of a functional specification.

Purpose of an SAP Functional Specification

A functional consultant writes an SAP functional specification any time there is a gap between standard SAP functionality vs desired functionality. Functional specs may be necessary during an end-to-end SAP implementation to address gaps identified in the business blueprint. They may also be required when an SAP add-on is purchased, an enhancement is approved, or even when a bug-fix is raised. Basically any time you need a technical consultant to do something, write a functional spec!

The document should paint a clear picture of the required outcome in the system. The goal of the document is to:

• Enable the developer to create a technical design document and, ultimately, to develop the solution correctly
• Identify the test scenarios so testers know what to execute
• Convey the end result to stakeholders so they know what they are getting
• Act as a historical reference (along with the technical design document) to identify what was built in the system and why

There may be several revisions to the document as it is discussed between functional, technical, test and business teams. Ultimately, the functional spec is finalized, approved by the stakeholders and saved for posterity.

Content of an SAP Functional Specification

As a functional consultant, I have written many functional specifications that followed many different formats. Usually, each project has its own template of functional specification, so it is best to reach out to your project team and ask them to share the template.

Team and Timing

This section defines the administrative needs and resources leveraged in the project. It answers the following questions: Who? Where? When? If physical signatures are required for approval of the spec, they may be included here as well.

Requirement Details

The meat of the document lies in the requirement details. It answers the following questions: Why? What? How? There is no perfect formula for filling these details in a functional spec, as the style varies by RICEF object type. The requirement details should tell a logical story about the need, the current process, the desired outcome and the proposed solution. DO include process flow diagrams, existing sample programs, performance considerations, layout mock-ups and reporting expectations. DO NOT write lazy, vague descriptions of the requirements or presumptions about the desired results. Remember, the developer needs to use this document to build the object. For a great read on the technical consultant’s advice on writing functional specs, click here.

As an example, if the RICEF object is a custom report, the diligent consultant might append an external document of output field specifications and add some bullet points to express the output type, toolbars and export methods like so:

• Report output in ALV grid format
• Standard ALV toolbar options activated:
  • Details, Sort, Search, Filter, Total, Subtotal, Print, Export, Layout Maintenance

• Ability to export report to Spreadsheet, Local File, or SAP Business Workplace

Test Cases

Similarly, the test cases should include all individual test execution steps of the TO BE requirement. Again, the test team needs to use this document to develop the scripts and execute the testing once the object is developed. Be as detailed as possible!

Summary

At the end of the day, the SAP functional specification is the blueprint used to build development objects in the system. Spend some time and effort writing the document. Ensure that the requirements are understood, the expected result is clearly defined, and that all of the above is agreed upon by all stakeholders.