Lesson 4 of 6
Writing requirements and gaps
10 min
A gap that is described well gets a good solution. A gap described badly gets either a rejection or an expensive build of the wrong thing. Key users are best placed to describe gaps, because they know the business need; consultants and developers know the solutions. This lesson gives a short, repeatable format.
The four-part format
| Part | What to write | Contoso example: fleet contract ID |
|---|---|---|
| Business need | What the business must achieve, and why, in business words | Fleet customers require their contract ID on every invoice, or they reject the invoice and pay late |
| Standard behavior | What SAP standard does today, as shown in the workshop | The standard order has a customer reference field, but it is used for the purchase order number |
| Impact | What happens if nothing is done: money, risk, effort, customers | About 40% of revenue is fleet; rejected invoices delay cash by an average of 20 days |
| Priority | Must, should, could; and by when | Must have at go-live |
Notice what is missing: the solution. The key user does not write "add a Z-field to table VBAK". The design authority, consultants and developers propose solutions, ideally in this order: change the process, use configuration, use a key user extension, use a developer extension on released interfaces, build side-by-side. For the fleet contract ID, Contoso chose a key user custom field on the sales document, also used on the billing form.
Why every gap has an upgrade price
Under a clean core approach, every deviation from standard is something that must be built, documented, supported and regression tested at every upgrade, for the life of the system. A custom field costs little; a custom approval engine costs a lot, for years. That is why key users should challenge every gap they raise, and why the impact line matters so much: it is what justifies the long-term cost. "Users are used to it" never does.
Where requirements live
Requirements and gaps belong in the project's backlog tool, not in workshop slides or emails. Many SAP projects use SAP Cloud ALM, where requirements can be linked to processes, user stories, test cases and defects. That link matters later: when a test fails, you can see which requirement it proves; when the process owner signs off, they can see which requirements were delivered. Write each requirement so it can be tested: if you cannot describe how you would know it works, it is not finished.
What would you do?
A buyer asks Maria to log a gap: "We need the old ECC purchase order layout with our logo in the top left." The standard form already shows the logo, top right. What is the most appropriate record?
- Write gaps as business need, standard behavior, impact and priority; leave the solution to the design authority.
- Solution options run from adopting standard to classic custom code; prefer the cheapest to run.
- Every gap has an upgrade price under clean core; impact must justify it.
- Keep requirements in the backlog tool, linked to tests, with an "accepted when" line.
Check your understanding · not graded
Lesson check
1. Why should key users challenge every requested gap under a clean core approach?
2. Which part of a requirement does the key user usually not write?
3. Which solution option is cheapest to run over time?
4. What does an "accepted when" line add to a requirement?