15.1 Establishing Scope Through Requirements Management
Key Takeaways
- Requirements management establishes scope through gathering, analysis, justification, and baselining of needs.
- Gathering must reach beyond the loudest stakeholders, or the baseline reflects influence rather than need.
- Analysis removes duplication and conflict and converts wants into testable, unambiguous statements.
- Justifying requirements links each one to a benefit or an obligation, so unjustified scope is challenged before it is baselined.
- The baselined requirement set becomes the reference for change control — without it, scope creep cannot even be detected.
Why requirements and configuration matter on the APM PMQ
Requirements management and configuration management together establish and protect scope. On the PMQ they form learning objective 16 — Requirements management. Weak answers say "get a requirements document." Strong answers show a life cycle of need → analysis → justified baseline → controlled change, plus the five configuration processes that keep products and documents consistent with that baseline.
Without disciplined requirements, teams build the wrong thing. Without configuration management, they cannot even agree what version of "the thing" is approved, tested, or handed over. Scope then becomes a moving rumour rather than a managed baseline.
Exam frame: Requirements establish what is needed. Configuration management protects what is built and recorded as that need evolves under change control.
Establishing scope through requirements processes
Scope on a project is the sum of products, services, and results to be delivered — and, equally important, what is excluded. Requirements processes turn stakeholder needs and constraints into a managed statement of scope that can be planned, estimated, and verified.
The requirements life cycle (gather → analyse → justify → baseline)
| Stage | Purpose | Typical activities | Output quality check |
|---|---|---|---|
| Gather (elicit) | Capture needs, wants, constraints, and interfaces from stakeholders | Interviews, workshops, observation, document review, prototypes, surveys, site visits | Right people involved; assumptions logged; conflicting asks visible |
| Analyse | Structure, clarify, de-duplicate, and test feasibility | Categorise (functional/non-functional/constraints); model processes; resolve conflicts; check completeness and consistency | Requirements are clear, testable, and non-contradictory |
| Justify | Decide what deserves inclusion against objectives, benefits, cost, risk, and strategy | Trace to business case/benefits; challenge gold-plating; prioritise (links to LO17); obtain sponsor/user authority | Only value-adding or mandatory items proceed |
| Baseline | Freeze an approved set for planning and control | Formal approval; version ID; communicate baseline; place under change control | Everyone works from the same approved set |
Gathering requirements
Gathering (elicitation) is active discovery, not passive waiting for a perfect brief. Sources include the sponsor, users, operators, regulators, suppliers, architecture/standards teams, and existing process or system documentation. Techniques should match context: a regulated clinical system needs standards review and safety workshops; a consumer app may need user research and prototypes; a civil works package needs site surveys and statutory constraints.
Common gathering failures:
- Listening only to the loudest stakeholder
- Capturing solutions ("buy system X") instead of needs ("reduce failed payments by 50%")
- Ignoring non-functional needs (security, accessibility, performance, maintainability, sustainability)
- Missing interface and operational requirements that later break transition into BAU
Tip for long responses: name who you would consult and why, not only "hold a workshop."
Analysing requirements
Analysis turns raw statements into a coherent, usable set. Typical analysis work includes:
- Separating functional requirements (what the product must do) from non-functional (how well it must perform) and constraints (must-use standards, budget envelope, legal rules)
- Removing duplicates and resolving conflicts (for example "same-day delivery" vs "lowest logistics cost")
- Checking SMART-like testability: can acceptance criteria prove the requirement was met?
- Identifying dependencies and interfaces
- Flagging uncertainty that needs further discovery (especially under iterative life cycles)
Analysis is where ambiguous language is challenged. "User-friendly," "fast," and "secure" are not yet manageable requirements until measures or standards attach.
Justifying requirements
Justifying asks whether each requirement should be in scope. Justification links requirements to:
- Strategic objectives and business-case benefits
- Mandatory compliance or safety obligations
- Cost, time, and risk of inclusion
- Opportunity cost of excluding something else
Not every requested feature is justified. Gold-plating (adding nice-to-have complexity without proportional value) inflates cost and risk. Conversely, cutting a mandatory accessibility or safety requirement to "save time" is not valid justification — it is scope abuse that returns as defects, non-compliance, or failed benefits.
Baselining needs
A requirements baseline is the approved, version-controlled set of requirements that the project commits to deliver (for a phase, increment, or whole project as agreed). Baselining enables:
- Reliable estimating and integrated planning
- Design and build against a known target
- Test and acceptance design
- Objective change control ("is this in the baseline or a change?")
| Baseline practice | Why it matters |
|---|---|
| Named version and date | Avoids "which list are we on?" |
| Approval authority | Sponsor/user/change authority as defined by governance |
| Traceability | Requirement IDs link to design, tests, and benefits |
| Communication | Team and suppliers work from the approved set |
| Change process | After baseline, changes go through control — not side conversations |
In linear life cycles, a relatively firm requirements baseline is often expected before major build. In iterative life cycles, a high-level baseline (vision, goals, non-negotiables) may sit above an evolving backlog, with increment-level baselining of the committed sprint/iteration scope. The principle remains: what is committed is known, approved, and controlled.
Scenario A — unbaselined scope
A local authority digital team gathers 200 user stories in workshops but never analyses conflicts, never justifies against the benefits case, and never baselines. Mid-build, three directors each "confirm" different must-haves. Cost and schedule forecasts collapse. A PMQ-quality response would recommend completing analysis, prioritising against benefits and constraints, obtaining a formal baseline, and routing further change through configuration and change control.
Which sequence best describes establishing project scope through requirements management?