Requirements Must Survive the Entire Delivery Lifecycle
Requirements are not a one-time document produced during discovery. They form a controlled thread from business need through design, build, test and acceptance.
Poor requirements management creates scope disputes, duplicate build effort, weak testing and late surprises. Strong management keeps requirements clear, prioritized, traceable and governed as understanding evolves.
14.1 Define a Requirement Hierarchy
Distinguish business outcomes, capabilities, process requirements, functional requirements, non-functional requirements and technical constraints.
A hierarchy prevents a low-level feature request from appearing equal to a strategic business outcome and makes traceability easier.
14.2 Write Requirements That Can Be Tested
Use clear language that describes the need and expected behavior. Avoid vague statements such as “system should be user friendly” unless measurable criteria are defined.
Where appropriate, attach acceptance criteria, examples, volumes, roles and boundary conditions.
14.3 Give Every Requirement an Identity and Owner
Use unique IDs and associate each requirement with a process, source, owner, priority and status.
Ownership ensures there is someone who can explain the need and participate in validation when questions arise.
14.4 Prioritize Explicitly
Use a transparent scheme such as Must, Should, Could and Won’t-now, or another agreed method. Priority should reflect business necessity, risk, compliance and dependency—not simply who argues most loudly.
Revisit priorities when scope, budget or timeline changes.
14.5 Control Requirement Changes
A requirement can become clearer without changing scope; another clarification may reveal material new work. Define how the team distinguishes refinement from change.
When impact is material, use formal change control rather than silently absorbing the work.
14.6 Maintain End-to-End Traceability
Connect requirements to process design, fit-gap decisions, design specifications, backlog items, configurations, developments and tests.
Traceability is especially valuable when a defect appears or a stakeholder questions why functionality exists.
14.7 Manage Non-Functional Requirements
Performance, security, availability, auditability, scalability, usability and supportability often create major architectural impact.
Capture them early and give them the same governance discipline as functional requirements.
14.8 Use Requirements as Acceptance Evidence
A requirement is not complete because it was built. Completion should be supported by design validation, test evidence and business acceptance as appropriate.
Keep status definitions clear so “implemented,” “tested” and “accepted” are not treated as the same state.
From the Delivery Floor
A project tracked hundreds of backlog items but could not explain which business requirements they satisfied. When scope pressure appeared, leaders had no reliable way to identify low-value work.
The team rebuilt traceability around business capabilities and requirement IDs. This exposed duplicate items, clarified mandatory controls and allowed lower-priority enhancements to be deferred without threatening core outcomes.
14.9 The Delivery Leader's View
Requirements management is a governance discipline, not an administrative exercise. It should help leaders see what is committed, what has changed and what evidence supports acceptance.
If the project cannot trace important build items to an approved need, scope control is already weak.
Chapter 14 Implementation Checklist
- Is there an agreed requirement hierarchy?
- Are requirements uniquely identified?
- Are they clear and testable?
- Does each have an owner and source?
- Are priorities explicit?
- Are non-functional requirements included?
- Is refinement separated from scope change?
- Are changes governed?
- Can each major requirement trace to design and testing?
- Are status definitions clear?
- Is acceptance evidence retained?
Key Takeaways
Requirements should remain controlled from discovery through acceptance.
Clear ownership and testable wording reduce downstream ambiguity.
Prioritization must be explicit and revisited when constraints change.
Non-functional requirements can drive major solution decisions.
Traceability protects scope, quality and acceptance.
Closing Thought
A requirement becomes valuable when the project can follow it from business need to proven outcome without losing its meaning along the way.