Requirements and Scope Definition
This domain tests elicitation, specification, traceability and scope control. The exam expects you to turn ambiguous stakeholder wishes into testable requirements and to defend the scope baseline once it is approved.
From need to requirement
- Functional requirements describe behavior; nonfunctional requirements describe quality constraints such as performance, security, availability and usability. Both need acceptance criteria.
- Elicitation techniques include interviews, facilitated workshops, observation, document analysis and prototyping. Choose by stakeholder availability and uncertainty: observation reveals workarounds that interviews miss; prototypes reduce uncertainty about usability.
- Prioritize with MoSCoW or a value-versus-effort model, and write user stories to INVEST criteria.
Traceability and the scope baseline
The requirements traceability matrix links business need to requirement, design element, test case and acceptance result. The scope baseline is the scope statement plus the work breakdown structure and WBS dictionary. A new requirement enters through change control, not by silent backlog injection.
Worked example
A stakeholder says the system must be fast. That is untestable. Rewrite it as: 95th percentile search response is under 1.5 seconds at 500 concurrent users during peak load, measured at the API gateway. The reasoning: the rewrite names a percentile, a threshold, a load profile and a measurement point, so it can be designed, tested and accepted.
Traps
- Gold plating: adding unrequested features that consume budget and create untested scope.
- Deferring nonfunctional requirements until testing, when architecture can no longer satisfy them cheaply.
- Treating sign-off as permanent freeze; baselines change through control, not avoidance.
- Leaving etc. or and so on in requirements, which creates unlimited scope.