15.1 Establishing Scope Through Requirements Management

APM Project Management Qualification PMQ

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Exam Format & Question Types 1.3 How to Study for APM PMQ

2 Life Cycles

2.1 Linear Life Cycles and Why Work Is Phased 2.2 Iterative and Hybrid Life Cycles 2.3 Project Life Cycles and Extended Life Cycles 2.4 Choosing a Life Cycle: Context, Culture, Strengths and Limitations

3 Governance Arrangements

3.1 Functional, Matrix and Projectised Structures 3.2 Governance Frameworks, Policies and Delegated Responsibility 3.3 Life-Cycle Impact on Governance and Limits of Financial Authority 3.4 Project Roles and Responsibilities 3.5 Project Manager and Project Sponsor Through the Life Cycle 3.6 Linking Projects to Organisational Objectives

4 Sustainability

4.1 Sustainability Responsibilities, Principles and Impact 4.2 Monitoring and Reporting Sustainability Measures

5 Business Case

5.1 Business Case Fundamentals and Analysis Tools 5.2 The Business Case as Baseline and Reviewing Change

6 Procurement

6.1 Procurement Strategy: Purpose and Contents 6.2 Supplier Selection and Negotiation 6.3 Features of Different Contractual Relationships 6.4 Supplier Reimbursement Methods

7 Reviews & Assurance

7.1 Reviews, Decision Gates, Benefits Reviews and Audits 7.2 What Gets Reported and Informing Decisions 7.3 Why Activities Are Re-Planned After a Review 7.4 Project Assurance

8 Transition & Benefits Management

8.1 Transition Requirements and Business-as-Usual Readiness 8.2 Knowledge Transfer and Agreeing the Transition Plan 8.3 Benefits Management: Identification to Realisation 8.4 Aligning and Communicating Benefits

9 Stakeholder Engagement & Communication

9.1 Stakeholder Analysis, Influence and Engagement 9.2 The Communication Management Plan and Its Benefits 9.3 Managing Stakeholder Expectations 9.4 Communication Methods and Tailoring the Message 9.5 Factors That Help and Hinder Communication

10 Conflict Resolution

10.1 Sources and Impacts of Conflict 10.2 Addressing Conflict and the Thomas-Kilmann Model

11 Leadership

11.1 Leadership, Motivation and Team Performance 11.2 Changing Leadership Styles for the Situation 11.3 Coaching, Mentoring and Emotional Intelligence

12 Team Management

12.1 Team Development Stages and Models 12.2 Characteristics and Benefits of Effective Teams 12.3 Leading Virtual and Hybrid Teams

13 Diversity & Inclusion

13.1 Diversity Characteristics and the Equality Act 13.2 Incorporating Diversity and Diverse Thinking 13.3 Conscious and Unconscious Bias and Fair Treatment

14 Ethics, Compliance & Professionalism

14.1 Continuing Professional Development and Competence 14.2 Sources of Specialist Advice and Standards 14.3 The Legal and Regulatory Landscape

15 Requirements & Solutions

15.1 Establishing Scope Through Requirements Management 15.2 Managing Scope Through Configuration Management 15.3 Solutions Development and Prioritisation

16 Quality Management

16.1 Quality Planning, Indicators and the Business Case 16.2 Quality Control and Success Criteria

17 Integrated Planning

17.1 The Integrated Project Management Plan: Format and Contents 17.2 Why an Integrated Plan Matters

18 Schedule Management

18.1 Defining Scope and Breakdown Structures 18.2 Dependencies and What Drives the Schedule 18.3 Re-Estimating and Schedule Optimisation

19 Resource Management

19.1 Determining Resource Requirements and Availability 19.2 Organisational Breakdown Structure and RACI 19.3 Categorising and Allocating Resources 19.4 Resource Smoothing and Resource Levelling

20 Budgeting & Cost Control

20.1 Creating a Budget and Cost Types 20.2 Earned Value and Cost Forecasting 20.3 Monitoring and Reporting Financial Performance 20.4 Closing Down Project Finances

21 Risk & Issue Management

21.1 Benefits of Risk and Issue Management and Contingency Planning 21.2 The Risk and Issue Management Processes 21.3 Proactive and Reactive Risk Responses 21.4 Governance in Risk and Issue Management

22 Change Control

22.1 The Change Control Process and Its Stages 22.2 What a Change Request Must Capture 22.3 Assessing Options and the Impact of a Change 22.4 Recommending Decisions and Updating Plans

15.1 Establishing Scope Through Requirements Management

Key Takeaways Explain This Topic AI

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.

Last updated: August 2026

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.