Scope and requirements management
Scope and requirements management
This domain tests how scope is defined, decomposed, baselined and protected.
Core rules
- Capture requirements through interviews, workshops, observation and document analysis; separate functional from non-functional requirements.
- Prioritise with MoSCoW (must, should, could, won't) or similar; musts define the minimum usable subset.
- Build a WBS that is deliverable-oriented; the lowest level is a work package with acceptance criteria.
- Establish a scope baseline (scope statement, WBS, WBS dictionary) and control changes through integrated change control.
- Trace requirements to design, build and test to prevent omission.
Worked example
A CRM replacement has a must requirement: 'sales staff can see customer history in one screen'. A should requirement is: 'manager dashboard refreshes hourly'. The WBS decomposes 'customer history view' into data model, API, UI and test work packages. A later request for a mobile app is not in the baseline; it goes to change control with impact on schedule and cost. Reasoning: priority and traceability let the team protect the minimum scope while assessing additions formally.
Traps
- Confusing scope creep with legitimate change: both need control, but creep is uncontrolled.
- Writing requirements as solutions ('use PostgreSQL') rather than needs.
- Missing non-functional requirements such as performance, security or accessibility.
- No acceptance criteria, so 'done' is disputed.
- Gold-plating by the team without approval.