Concept and mechanism
Decide in advance which relationships will be needed to track delivery. A useful chain can connect objective, requirement, component, test, and result, but detail should answer the team’s questions and risk level. A file containing hundreds of stale links is not stronger proof than a small matrix maintained correctly. Identify update owners and the rule permitting a status change. Developed, tested, and accepted represent different evidence. Also plan version control and how changes after testing become visible. A previous-version result may need reassessment; an existing link does not guarantee continued validity.
Guided application
In one example, a requirement says 95% of queries must finish within two seconds under a defined load. A one-second average does not prove that criterion: some queries may take much longer. Before the exercise, specify the population, collection window, and how the proportion is calculated. In another example, recovery within 30 minutes and a maximum five-minute data loss are separate criteria; demonstrating one does not demonstrate the other. These values are exercise conditions, not bank policies. Collaborate with business, support, and specialists to define measurable criteria and evidence acceptance owners. Changing a criterion after seeing the result requires rationale and a decision, not a silent edit to make reporting green.
Average latency and proportion below a threshold answer different questions.
Common pitfalls
Link treated as valid evidence; testing treated as acceptance; criterion changed after results.
Related topics: From need to solution scope · Value, stakeholders, and business case · Requirements plan and responsibilities
Define what will be proven, with which evidence, and for which version.
Reference: Requirement traceability as evidence · Five-domain ECO / verified 2026-10-01