Lesson 1 of 5
Requirements from fit-to-standard
10 min
Listen to this lesson
A requirement is the program's promise to the business. It says what the solution must do that the standard, or the system as it stands today, does not. If the promise is never written down, nobody builds it, nobody tests it, and the process owner finds out in UAT. SAP Cloud ALM gives requirements a home inside the project, attached to the solution process they change, so the promise can be followed all the way to a tested, deployed change.
Where requirements come from
In SAP Activate, the main source is the fit-to-standard workshop in the Explore phase. SAP's learning content describes workshops organized by functional area: the team reviews the standard process, discusses fit, identifies delta requirements and decides the configuration needed. One consultant demonstrates and leads the discussion while a second documents the identified requirements directly in Cloud ALM.
Contoso is running a system conversion, not a new implementation, so its workshops look slightly different. Most ECC processes carry over, and the questions are about what changes: simplification items such as business partner and credit management, custom code that must be adapted or retired, and processes the business wants to improve while it has the chance. Priya calls them delta design workshops, but the output is the same: requirements attached to solution processes.
- Scope the solution processOrder to cash for sales area 1710 / 10 / 00 is in the project scope
- Run the workshopShow the S/4HANA process, compare with how Contoso works in ECC today
- Capture the deltaCreate a requirement on the process while the discussion is live
- Add contextWorkstream, priority, tags and a clear description with acceptance criteria
- ApproveThe process owner or requirement approver accepts it into scope
- RefineApproved requirements are broken into user stories for the build
Requirements and notes
SAP's guidance separates two kinds of workshop output. A requirement is actionable: something the solution must fulfill, which will be approved and then built. A note records knowledge about the process that is worth keeping but asks for no work, such as "credit checks for fleet customers are run by the Chicago team". Notes become part of the process documentation. Mixing the two inflates the backlog with items nobody will ever build, and that breaks every coverage figure later.
| Workshop output | Example from Contoso | Where it goes |
|---|---|---|
| Requirement | Purchase orders over $25,000 need approval through flexible workflow | Requirement on the procure-to-pay process; approved, refined, built and tested |
| Requirement | Consolidated monthly invoice for Great Lakes Fleet Services | Requirement on order to cash; becomes user stories and a feature |
| Note | The Detroit buyers review open requisitions every Monday | Process documentation; no build, no test case |
| Not in scope | A new warehouse app for a site Contoso does not own yet | Logged as a rejected or deferred requirement, with the reason |
Ways to create a requirement
SAP's material lists several entry points. In the process view, you select a solution process in scope and create a requirement from it, either from the process diagram or from the side panel. You can also create requirements in the Requirements app, upload them from a spreadsheet, or create them through the API. Whatever the route, the link to the solution process is what matters, because it is kept through the life of the requirement and drives the process-level reports. SAP has also made it possible to assign several processes to one requirement, which helps with cross-process needs such as an approval rule that touches both procure to pay and finance.
A good requirement is short, testable and owned. Contoso's template has a one-line title, a description of the business need, the acceptance criteria the process owner will check, the workstream, a priority and tags for themes such as simplification item or interface. Avoid solution design in the title. "Approve POs over $25,000" is a requirement; "Build BAdI for release strategy" is a user story.
Approval
Approval is optional in Cloud ALM, but it is the step that turns a wish into scope. SAP's leading practice includes requirement approval, and SAP has added a dedicated Requirement Approver project role so approval does not have to sit with the project lead. Once approved, the requirement moves on toward planning and realization. SAP's learning exercise approves a requirement in the Requirement Traceability view and then sets it to In Realization. At Contoso, Dan approves finance requirements and Maria approves order-to-cash requirements; Grace reviews anything that changes the go-live plan.
What would you do?
In Contoso's order-to-cash workshop, Maria mentions in passing that Chicago sometimes ships before credit release "because the old report is slow". The consultant documenting the session is unsure what to capture. What is the best move?
- Requirements are actionable deltas captured in fit-to-standard or delta design workshops; notes are knowledge without work.
- Create requirements from the solution process so the process link drives later reporting.
- Write title, description, acceptance criteria, workstream, priority and tags while the process owner is present.
- Approval turns a wish into scope; Cloud ALM supports a dedicated Requirement Approver role.
Check your understanding · not graded
Lesson check
1. In SAP's guidance, what separates a requirement from a note captured in a workshop?
2. Why create a requirement from the solution process rather than as a free-standing item?
3. Which Contoso item is a good requirement title?
4. Who can approve requirements when SAP's dedicated role is used?