Collect Requirements

Sensei Short Scroll 5 Planning Process Group

Collect Requirements

Introduction: Why This Matters

Requirements are the lifeblood of a project. They define what stakeholders expect, what the product or service must deliver, and what the team needs to build. Without well gathered requirements, even the best managed project risks delivering outputs that fail to meet real needs.

The Collect Requirements process ensures that stakeholder expectations are captured, analyzed, and documented. It is not about finalizing scope yet, that happens later in Define Scope. Instead, this process creates a foundation of detailed, traceable requirements that support design, validation, and scope definition (Project Management Institute, 2021).

On the PMP exam, questions often test whether you recognize the need to gather and validate requirements before defining scope or creating the WBS. In practice, thorough requirements gathering prevents scope creep, reduces rework, and improves stakeholder satisfaction.

Purpose and Objectives

Primary Purpose: To determine, document, and manage stakeholder needs and requirements to meet project objectives (Project Management Institute, 2021).

Key Objectives:

  • Engage stakeholders to capture their needs, wants, and expectations.
  • Convert stakeholder input into clear, measurable requirements.
  • Differentiate between project requirements (process needs) and product requirements (deliverable features).
  • Create documentation and traceability tools to ensure requirements are tracked throughout the project life cycle.

Overview

Collect Requirements sits between planning the framework for scope and defining scope itself. It focuses on understanding what stakeholders need before you lock in the project scope statement.

  • Planning focus: Gather, analyze, and agree on requirements in enough detail to support scope definition, design, and testing.
  • Coverage: Uses a wide range of techniques to engage stakeholders, prioritize needs, and create documentation plus a traceability matrix.

Characteristics

  • Stakeholder-centric: Driven by active engagement of stakeholders using interviews, workshops, surveys, and observation.
  • Multi-technique: Combines data gathering, data representation, decision making, and interpersonal skills.
  • Output-focused: Produces requirements documentation and a requirements traceability matrix (RTM).
  • Foundation for scope: Requirements form the raw material that later becomes the scope statement and WBS.

ITTO View

Inputs

  • Scope Management Plan.
  • Requirements Management Plan.
  • Stakeholder Engagement Plan.
  • Project charter.
  • Stakeholder register.

Data gathering

  • Interviews.
  • Focus groups.
  • Facilitated workshops (for example, Joint Application Development sessions).
  • Questionnaires and surveys.
  • Benchmarking.

Data representation

  • Context diagrams.
  • Affinity diagrams.
  • Process maps and flowcharts.

Decision making

  • Voting (unanimity, majority, plurality).
  • Autocratic decision making.
  • Multi criteria decision analysis.

Interpersonal and team skills

  • Active listening.
  • Facilitation.
  • Conflict resolution.

Other techniques

  • Prototypes (mock ups, wireframes, early models).
  • Observation (job shadowing).

Outputs

  • Requirements documentation.
  • Requirements traceability matrix.

Requirements Documentation

Requirements documentation describes what the project must deliver.

Typical contents:

  • Business requirements (why the project exists).
  • Stakeholder requirements (needs of specific groups).
  • Solution requirements (functional and non functional features).
  • Transition requirements (data migration, training, cutover steps).
  • Assumptions and constraints linked to requirements.

Exam Note: Expect situational questions that distinguish between functional and non functional requirements.

Requirements Traceability Matrix

The requirements traceability matrix (RTM) links each requirement to business objectives, scope elements, design, testing, and deliverables.

Benefits:

  • Ensures no requirement is lost or forgotten.
  • Provides a tool for validating deliverables.
  • Helps manage the impact of changes. When a requirement changes, the RTM shows which deliverables and tests are affected.

Example columns:

  • Requirement ID.
  • Description.
  • Source (stakeholder).
  • Priority.
  • Acceptance criteria.
  • Status (proposed, approved, implemented, verified).

Practical Example

Context: Banking Mobile App.

Collect Requirements activities:

  • Interviews: Held with executives, branch managers, and IT leaders.
  • Surveys: Sent to 5,000 customers to identify desired features.
  • Workshops: Conducted with regulators to capture compliance requirements.
  • Observation: Shadowed tellers to understand current transaction handling.
  • Prototyping: Built mock up screens and gathered customer feedback.

Outputs: Requirements documentation includes business needs (increase mobile adoption by 20 percent), functional needs (fund transfers, bill payments, account alerts), and non functional needs (secure login, fast response time).

The requirements traceability matrix links each requirement to objectives, scope elements, design components, and test cases.

Outcome: The bank avoids missed requirements, builds a compliant system, and delivers features that customers actually value.

Common Pitfalls

Incomplete stakeholder engagement

  • Pitfall: Requirements miss critical voices.
  • Prevention: Use the stakeholder register to engage all relevant groups.

Overly vague requirements

  • Pitfall: Requirements like “system should be user friendly.”
  • Prevention: Translate into measurable expectations, for example, “Users complete login within 10 seconds with no more than two errors.”

Failure to document assumptions

  • Pitfall: Requirements are based on unspoken assumptions.
  • Prevention: Record assumptions and constraints explicitly.

No traceability

  • Pitfall: Requirements get lost between planning, design, and testing.
  • Prevention: Maintain an RTM to ensure full life cycle tracking.

Sensei Tip : If you cannot show where a requirement came from and how it will be tested, it is not fully under control yet. The requirements traceability matrix is your silent guardian.

Exam Alert : If a question shows the team moving into design, development, or WBS creation while requirements are still unclear or undocumented, the best action is usually to go back and collect or clarify requirements, not to push forward.

Exam Lens

Patterns on the PMP Exam:

  • If requirements are unclear, the correct next step is to gather or clarify requirements, not to proceed with scope definition or WBS creation.
  • Questions often emphasize the requirements traceability matrix as a tool for linking requirements to deliverables and tests.
  • Situational questions may test prioritization methods such as voting or MoSCoW (Must, Should, Could, Will not).

Sample Question

Question: A project team delivers a new system, but stakeholders complain that key features are missing. Which process was most likely performed poorly?

  1. Define Scope.
  2. Collect Requirements.
  3. Create WBS.
  4. Validate Scope.

Correct Answer: B. Missing features usually trace back to inadequate requirements collection.

Quick Recap Table

Element Why It Matters Exam Watch Point
Requirements documentation Defines what stakeholders need from the project. Differentiate functional and non functional requirements.
Requirements traceability matrix Tracks requirements through design, build, and test. Expect questions on linking requirements and impact analysis.
Data gathering techniques Engage stakeholders in multiple, structured ways. Know tools such as interviews, workshops, and surveys.
Prioritization techniques Balance conflicting needs and limited resources. Voting, multi criteria decision analysis, MoSCoW.

Key Takeaways

  • Collect Requirements ensures stakeholder needs are documented, prioritized, and traceable.
  • The main outputs are requirements documentation and the requirements traceability matrix.
  • Strong requirements gathering reduces scope creep and rework and improves satisfaction.
  • On the PMP exam, this process is frequently tested in scenarios where missing or unclear requirements are the root cause of failure.

Next Step

With requirements collected, the next logical step is to synthesize them into a clear project scope statement. The following process, Define Scope, transforms stakeholder needs into a definitive description of the project and its deliverables.

Bibliography

Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (7th ed.). Project Management Institute.

Scroll to Top