10 Must-Know Tips in Writing SAP Functional Specification Documents

Think of yourself as an SAP Fresher being given a blank functional specification template. Sure, you may find a few keywords and/or sentences in the template. That should be enough right? My response to that is “no, it is not enough”.

Back when I was an SAP Fresher, I have encountered that scenario. Don’t get me wrong. The template had a lot of keywords and sentences – nothing wrong with that.

My concerns back then as a fresher were more of the following:

• How do I start? Where do I begin exactly?
• What am I supposed to write in the functional specification document?
• How do I know if my FS is okay?

…and the best part:

• Can I have a fully populated / complete version of a functional specification document? I just want to see an example and get an idea.

Basically, a lot of questions and thoughts pop up as a beginner. It would be great to have a colleague and/or mentor assist you with these concerns…maybe even a formal training.

That is the ideal scenario but, in some cases, these may not be readily available for every SAP fresher. Even if they are available, sometimes you need something more – may it be a bit more guidance, a different perspective, etc. At least in my case, I needed something more.

Below, you will find 10 must-know tips in writing an SAP functional specifications document. I have learned these throughout the course of my career and decided to share these tips with you.

---

1. Know your WRICEF

First of all, you need to know WRICEF. For some, it is also known as “RICEFW” or “WRICEF-A”. We will get to those later. This acronym basically helps you categorize SAP specific requirements / changes.

• W – Workflow
• R – Reports
• I – Interfaces
• C – Conversions
• E – Enhancements
• F – Forms

You can make use of WRICEF to categorize each requirement / change as needed. This helps give a “development perspective” to the developer.

What is RICEFW?

Well, it consists of the same definition breakdown only W – Workflows is at the end of the acronym.

What about WRICEF-A? What is WRICEF-A?

The “A” in this case stands for “Authorizations”. So, if your change involves authorization changes then you categorize it under that. Personally, I prefer to keep it as WRICEF. For the authorizations portion, I prefer to include it as part of the “additional details / considerations” portion in my functional specifications document.

Below can be your “cheat sheet” for WRICEF:

• W – Workflow
  • Think of approvals + Work that is passed from one to another (sequence)
  • Trigger approval to Person 1. After Person 1 approves, trigger approval to Manager 1 etc.
  • Approval flow logic
• R – Reports
  • Standard SAP Report
  • Custom Report
  • Report Painter
  • BW Reporting (Business Information Warehouse)
• I – Interfaces
  • Think of integrations and communication with third-party software.
  • SAP to SAP integration
  • SAP to Non-SAP integration vice versa
  • RFC, BAPI, IDOC, EDI, ALE, UDDI, SOAP, WSDL, REST, API, FTP, SFTP, etc.
  • Read this post to know the difference.
• C – Conversions
  • Converting data from one format to another + from one system to another
  • Legacy data transfer from legacy system (or file) to To-be System
  • Batch Data Communication (BDC), Legacy System Migration Workbench
  • (LSMW)
• E – Enhancements
  • Add / modify existing functionality to standard SAP
  • User-exits, Business Add In (BADI)
  • New Program
• F – Forms
  • Think of Printouts + Custom Forms
  • SAPscript forms, SAPscript print programs, SmartForms.

2. The developer / reader doesn’t want to read a novel

Have you ever been tasked to read a document with so many pages (mostly consisting of huge endless paragraphs)? Let’s add on that scenario and say that you need to read the whole document by tomorrow.

This is me exaggerating of course but who knows… it may happen. I would love to read a good novel from start to finish. I chose that novel and it is considered as a hobby. However, in the scenario provided, we are talking about work.

The reader must understand the information / requirements in the fastest way possible. We are looking at timelines after all.

That being said, I suggest that you:

• Make use of pictures, diagrams, visual cues, etc. (pictures are worth a thousand words)
• Avoid making huge compact paragraphs (make it easy on the eyes and easy to digest the information). Compare Sample Text 1 and 2.

3. The developer / reader doesn’t want to read a vague document

You know the stories where the information changes as it passes through diff people? Take this analogy for example:

That was funny to me and saddening at the same time because it’s true. That sort of stuff happens all the time where the information or understanding varies per person.

Going back to writing functional specifications document…I would advise you to be as detailed and descriptive as possible.

4. Write to convey a clear message not to show how proficient you are in complex language

I have tried reading technical documents and it takes more effort and time to understand the information. Let’s take a quick trip down memory lane to our school days where we are given scientific documents.

No offense to those who have science as their favorite subject. This is just for analogy / visualization purposes.

It is difficult for some (like me) and it will take way more effort and time before you reach a good understanding of what the technical document is saying. At times, I end up so bored that it takes more effort to read the document.

With that, I suggest that:

• Don’t make it difficult for the reader to understand the document.
• Don’t show off or show how proficient you are in a language. The goal is to ensure the developer / reader can quickly understand the message you are trying to convey.

Try to find that sweet spot or middle ground where your words are easy to understand. This is between the developer and you (as a functional consultant).

I am not saying that you completely avoid using technical terms. Sometimes it cannot be avoided and so the alternative would be to explain the technical concept or behavior in layman’s terms.

Think of an IT Support as well. if something goes wrong with the custom program after a couple of months, the IT Support may need to refer to the functional specifications document. Let us say that he / she needs to resolve the issue as soon as possible.

Now think of the IT Support finding your FS document and discovering how technical it is written. It will take a lot of time and effort to understand the content. What does this mean? More time…More effort.

5. Think BIG (Big Picture)

A functional specification document doesn’t have to be limited to the sections defined in the template. You can more information as you see fit. If you feel that you need to consider aspects of the project / change, then by all means include it. The more detailed you can get to help the reader understand what it going on… the better.

It also doesn’t apply to the reader but to you as a consultant. In my case, I have dealt with different projects involving integration, Non-SAP applications, programs created from scratch, etc.

What does this mean?

It means I need to consider a lot of things than the usual SAP changes. I may need to think about the following examples:

• Audit Compliance – Will this new feature be compliant with the audit regulations of the company?
• External Database / Server – The data is being stored in another database / server and it is involved as an additional step in reports processing. How does SAP communicate with this server?
• So on and so forth…

Those examples are just some of what I consider. So, over the years I have kept track of all of those considerations and included them in my personal checklist as guidance.

This in turn, helps me see the big picture. At this point, it’s not just about creating this change. It’s also seeing the impacts and potential concerns after this change is implemented.

6. Be Cautious

What you put in the functional specifications document matters. It is one of the documents that is constantly being referred to in case there are system functionalities in doubt etc.

It helps to be cautious in what you write. If you are unsure of something, make sure it is verified and approved. Make sure to take the time and clearly discuss the expectations and functionalities with the business champion / stakeholder / whomever concerned.

It also helps to question what you write. There is no harm in challenging or questioning some behaviors. It may be a potential consideration that helps avoid future issues / mishaps.

7. The Functional Specifications Differ

There is no standardized format for functional specifications. It differs from company to company.

It could also differ as:

• An in-house consultant.
• A consultant under an IT Company assigned to several projects / clients.
• A freelancer / contract-based consultant / self-employed.
• A consultant following an Agile / Hybrid approach or other methodologies.

Because of all these formats and templates, I have decided to create my own template combining sections, so I am reminded of certain considerations. I utilize the official templates handed over to me as a consultant, but it helps to have my own guide.

Note that for pure agile projects (Non-SAP or Hybrid), a functional specifications document will not be needed. Instead, you can expect to create user stories and product backlogs. This of course differs from one company, methodology, processes to another.

8. Keep the details concise

You want to avoid confusing the reader, so it helps to keep details concise.

This also considers the wordings you use even the ordering of requirements.

For example: If you mention the word “App” in the “Background and Purpose” section of the FS and mention “Portal” in the “Requirements” section… it will cause confusion even if you are talking about the same thing.

9. Don’t cram several requirements into 1

Which would you prefer?

• Several requirements jammed into 1 requirement item or
• Several mini requirements itemized (sorted accordingly)

It depends on how you would like to discuss the requirements, but I prefer to spread out / break out mini requirements then arrange them well. At least in my perspective, it is easier to digest and understand what needs to be done.

Towards the end, you can explain how each of those requirements would work together. Allow the reader to see the whole picture.

10. Never ever forget about the end-user

At the end of the day, the end-users or stakeholders are the main priority. You need to ensure that you get the requirements / functionalities right. You need to deliver according to their expectations and at least manage those expectations if there are technical / system limitations.

You can follow all the tips above and write a concise detailed document but if the content does not meet the expectations of the stakeholder… or worse… doesn’t solve the main problem, that would be a bad outcome.

That being said, I suggest that you exert time and effort to understand what the client is trying to solve rather than just blindly agreeing to the requests the client is giving you.

Summary

1. Know your WRICEF
2. The developer / reader doesn’t want to read a novel
   • Pictures please
3. The developer / reader doesn’t want to read a vague document
   • The information changes as it passes through diff people
4. Write to convey a clear message not to show how proficient you are in complex language
   • The goal is to find that sweet spot – middle ground – help the reader understand
   • Use simple and easy to understand words
5. Think BIG (Big Picture)
6. Be Cautious
7. The Functional Specifications Differ
   • There is no standardized “format”
   • As an in-house consultant
   • As a consultant under an IT Company assigned to projects/clients
   • As a freelancer / contract-based consultant
   • Agile / Hybrid approach
8. Keep the details concise
9. Don’t cram several requirements into 1
10. Never ever forget about the end-user

I hope this helps. Goodluck! 😊

Interested in a Digital Kit & Online Course on Creating Functional Specifications for SAP Consultants?

In just 2.6 hours or less, learn how to create SAP Functional Specifications with the use of Comprehensive FS Guides. Includes 3 Downloadable Materials you can take home and use throughout your career. This detailed course is scenario-based for easier understanding.

Interested in the 3 Downloadable Materials without the Course? Click on this link to know more. Use Coupon Code “HXHMMHXR5X” to get a 70% DISCOUNT!