Lesson 5 of 5
Defining acceptance criteria early
9 min
The cheapest moment to make a requirement testable is the moment it is written. Acceptance criteria are the specific, checkable conditions that must be true for the business to accept a requirement. Written during Fit-to-Standard or refinement, they tell the build team what done means, give testers their expected results, and give process owners a fair basis for sign-off. Written after the build, they tend to describe whatever was built.
From requirement to signature
- RequirementBusiness need with its reason, linked to a solution process
- Acceptance criteriaCheckable conditions agreed with the process owner
- Test casesSteps and expected results derived from the criteria, linked in Cloud ALM
- EvidenceTest runs with results and attachments
- AcceptanceProcess owner confirms the requirement against its criteria
Writing good criteria
- Specific: name the org units, documents and roles, such as sales area 1710 / 10 / 00 and the billing clerk role.
- Observable: describe a result someone can see in the system, not an intention.
- Complete enough: cover the main path and the exceptions the business cares about.
- Owned: agreed by the process owner who will sign.
- Independent of the build: state what must be true, not which program or setting achieves it.
| Weak criterion | Why it fails | Testable version |
|---|---|---|
| Invoicing works for fleet customers | Not observable; no conditions | For Great Lakes Fleet Services, all deliveries in a calendar month produce exactly one invoice dated the last working day |
| The report is fast | No threshold or conditions | The open order report for plant 1710 returns results in under 10 seconds for a month of data |
| Users can approve purchase orders | Which users, which limits? | Purchase orders over $25,000 for purchasing org 1710 require approval by the purchasing manager role before output |
A familiar format helps: given a starting situation, when the user does something, then a result is visible. For Contoso's consolidated invoice: given three deliveries to Great Lakes Fleet Services in March, when billing runs for March, then one invoice is created that contains all three deliveries.
Using the standard test scripts
For processes that fit the standard, criteria already exist in another form: the expected results in SAP Best Practices test scripts. Contoso adapts those scripts to its own org units and data, and adds criteria only for configuration values and deltas. This keeps the volume manageable and means that a fit process can be accepted against the same script the business watched in the workshop.
Do not forget non-functional needs. Fit-to-Standard workshops tend to surface them as asides: "month-end billing must finish overnight", "only the controller may post to closed periods". Capture each one as a requirement with a threshold, because performance, authorization and audit expectations are the criteria most often missing when a process owner is asked to sign.
Traceability in SAP Cloud ALM
In SAP Cloud ALM, test cases can be assigned to a requirement, to its user stories, or both, and the requirement traceability views show linked user stories, test cases and their latest results. SAP's best practice flow includes steps where a requirement is ready for test and later confirmed. Contoso uses the confirmation as the process owner's acceptance of that requirement, made with the evidence on screen.
What would you do?
A Contoso developer finishes the consolidated invoice user story and asks Maria to "take a look". There are no written acceptance criteria. Maria is unsure what to check. What should Priya recommend?
- Acceptance criteria are specific, observable conditions the process owner agrees to before the build.
- Use given, when, then; name org units, roles and thresholds.
- Fit processes reuse adapted Best Practices test scripts; deltas need full criteria.
- Link test cases to requirements in SAP Cloud ALM so acceptance is made against evidence.
Check your understanding · not graded
Lesson check
1. Why define acceptance criteria during Fit-to-Standard or refinement?
2. Which is a testable acceptance criterion?
3. For a process that fits the standard, what can serve as acceptance criteria?
4. Who should agree acceptance criteria for a delta?