Lesson 4 of 5
The traceability backbone
9 min
Traceability is the reason a test lead cares about project setup. A process owner signing UAT wants to know, for each of their processes: what was asked for, what was built, how it was tested and what is still open. In SAP Cloud ALM, the solution process in scope is the anchor that makes that question answerable, because requirements, test cases and documents all relate to it.
How the objects connect
- Solution processIn scope; the anchor for coverage
- RequirementCreated from the solution process in Fit-to-Standard
- User storiesSprint-sized build work broken down from the requirement
- FeatureThe deployable change; assigned to one requirement and carrying transports
- Test cases and plansAssigned to the process, requirement or user stories, then run in test plans
- DefectsRaised from failed runs and linked back
SAP's implementation best practice guide describes these relationships. A requirement can be refined into several user stories. A feature can include multiple user stories but is assigned to a single requirement, and it is the container for transportable changes. Test cases can be assigned to the requirement, to user stories, or both. Documents can be related to processes and other objects, and those relations always point to the document's latest version.
Choosing an implementation approach
SAP's guide asks projects to choose which entities they will use, because traceability only works if everyone uses the same pattern. Its leading approach for private edition projects is requirement-driven with user stories: start with requirements, break them into user stories, use a one-to-one relationship between requirements and features, and align customer-specific test cases to requirements and user stories. Alternatives exist for incremental delivery, for simpler projects without user stories, and for user-story-driven work in some cloud products.
| Approach | Chain | Trade-off |
|---|---|---|
| Requirement-driven with user stories (leading practice) | Requirement → user stories → feature | Full traceability and agile planning; more objects to maintain |
| Requirement-driven, incremental | One requirement → several features | Supports staged delivery; testing gets more complex |
| Requirement-driven without user stories | Requirement → feature | Simpler; loses sprint planning features such as story points |
| User-story-driven | User stories → feature, no requirements | Fast to set up; loses requirement approval and scope control |
Status as a signal
Each object has its own status, and SAP's guide shows how they move together. Requirements can pass through an approval step and then into realization; user stories move from open through in progress or in review to done; features move from specification and implementation through testing and successfully tested to deployment. The guide also shows a requirement being marked ready for test and later confirmed. Status lists evolve between releases, so agree with the team which statuses Contoso uses and what each one means.
- Is every in-scope solution process covered by at least one test case?Yes → next · No → coverage gap; add test cases before SIT
- Does every approved requirement have linked user stories or a feature?Yes → next · No → orphan requirement; plan or reject it
- Does every user story trace back to a requirement or process?Yes → next · No → possible scope creep; review with the product owner
- Do the requirement's linked test cases have a recent passed run?Yes → ready to confirm · No → not ready for acceptance
Reading traceability in Analytics
| View | Answers | Used at Contoso by |
|---|---|---|
| Solution process traceability | For each process: requirements, tests, results, defects | Process owners before UAT sign-off |
| Requirement traceability | For each requirement: stories, feature, tests and their status | Priya and product owners each sprint |
| User story traceability | Readiness of stories based on sub-tasks and test executions | Scrum masters at reviews |
| Feature traceability | Which features and transports are tested and deployed | Release and change managers |
SAP Cloud ALM traceability views and who relies on them.
What would you do?
Contoso's SIT coverage report shows the plan-to-produce area at 40 percent, but the test team says they have written all the test cases. What is the most likely explanation?
- The solution process in scope anchors traceability for requirements, test cases and documents.
- A feature is assigned to one requirement and can include several user stories; it carries transports.
- SAP's leading practice for private edition is requirement-driven with user stories and one feature per requirement.
- Use solution process, requirement, user story and feature traceability views before every gate.
Check your understanding · not graded
Lesson check
1. Which object anchors traceability from scope to tests in Cloud ALM?
2. How many requirements can one feature be assigned to?
3. What is SAP's leading implementation approach for private edition projects in Cloud ALM?
4. A user story traces to no requirement or process. What might it indicate?