Lesson 4 of 5
Traceability analysis
9 min
Listen to this lesson
Once requirements, stories, features and test cases are linked, Cloud ALM can show the chain. The traceability analytics are where a test lead finds the gaps that status meetings miss: requirements with nothing built, features with nothing tested, stories with no parent. This lesson walks through the views and a routine for using them.
The traceability views
Traceability lives in Cloud ALM's analytics. SAP's Expert Portal describes Requirement Traceability as an end-to-end tool reached from the Analytics area: for a project, it lists requirements with the status of the related entities for each one, such as user stories, features, project tasks, test preparation and test execution, with filters on each. SAP's implementation process diagram pairs it with related views for different owners.
| View | What it answers | Main audience at Contoso |
|---|---|---|
| Requirement Traceability | For each requirement: stories, feature, test preparation and execution status | Priya and the process owners, every sprint |
| Solution Process Traceability | For each scoped process: requirements and test progress | Dan and Maria before UAT sign-off |
| User Story Traceability | Readiness of stories from sub-tasks and tests | Team leads at sprint reviews |
| Feature Traceability | Feature readiness from stories and tasks; exportable to a spreadsheet | Release and change managers before deployment |
| Requirements Distribution | Requirements by team and status, such as in approval or blocked | Grace for workload and scope tracking |
The main traceability analytics in SAP Cloud ALM. Names and columns evolve, so check your tenant.
SAP stresses one point about these views: the statuses of the entities are maintained manually, and the tool helps you check the overall state. Traceability shows links and statuses as people recorded them. It does not inspect the system to see what was really configured. That is why the analysis is a conversation starter, not a verdict.
Four gap patterns
Most problems Priya finds fall into the bottom-right cell: a feature with transports in CMQ but no linked test. The sample question in Contoso's own test strategy uses it: a requirement with a delivered feature and no linked test case is a test coverage gap, not a transport error and not an authorization issue. The top-left cell is subtler. Tests linked to a requirement that has no build may be fine (configuration-only requirements) or may mean a story was linked to the wrong requirement.
A weekly routine
- Is every approved requirement linked to at least one story or feature?Yes → next · No → orphan; ask the workstream lead to plan or reject it
- Is every story linked to a requirement?Yes → next · No → untraced work; link it or route it for approval
- Does every requirement with a feature have a linked test case?Yes → next · No → coverage gap; assign a test author
- Have the linked tests run in the current cycle's plan?Yes → next · No → execution gap; check the test plan
- Do statuses agree (feature tested, tests passed, no open defects)?Yes → ready for confirmation · No → status hygiene; correct before the gate
Run the check with filters, not by scrolling. Filter Requirement Traceability by status In Realization and look for requirements whose test preparation column is empty. Filter by workstream to hand each lead a short list. Export the result if your tenant allows it and attach it to the sprint review, so the trend is visible over time.
Share the results in a way people act on. Priya sends each workstream lead only their own exceptions, with the requirement ID, the gap pattern and the owner's name, rather than the full export. Lists of five items get fixed; spreadsheets of four hundred rows get filed.
What would you do?
Requirement Traceability shows Contoso's consolidated fleet invoice requirement with three stories Done, a feature In Testing, and two linked test cases, both passed. Maria says the invoice still fails for deliveries from plant 1720. What explains this best?
- Requirement Traceability lists requirements with the status of stories, features, test preparation and execution.
- Solution process, user story and feature traceability serve process owners, team leads and release managers.
- Statuses are maintained by people; traceability shows links, not proof of quality.
- Look for four patterns: orphans, untraced stories, built-not-tested and stale statuses.
Check your understanding · not graded
Lesson check
1. A requirement has a feature with transports in CMQ but no linked test case. What is it?
2. Which view is aimed at process owners who want test progress per scoped process?
3. What does SAP note about the entity statuses shown in Requirement Traceability?
4. An approved requirement has no stories, no feature and no tests. What should happen?