Worried about building something your customer didn't actually ask for? Requirements Management and Communication is the method that ensures every project feature is clearly defined, prioritised, and tracked from start to finish. For the CAPM exam, mastering this topic means you can confidently answer questions about how to prevent project failure caused by 'scope creep'—when uncontrolled changes or continuous growth in a project's scope leads to missed deadlines and blown budgets.
Jump to a section
A simple way to picture Requirements Management and Communication
Have you ever tried to assemble a piece of flat-pack furniture with a friend, only to find out halfway through that you both thought the 'long wooden dowel' was for different things? In 'Requirements Management and Communication', you're essentially the person who translates what the customer wants into the instruction manual for the project team.
Consider this: your friend wants a bookshelf (the project). They describe it as 'sturdy and about this tall.' You, acting as the project manager, need to clarify: what does 'sturdy' mean? (Is it for heavy textbooks or just ornaments?) What exact height? (Meters? Feet?) You then write a list of requirements: 'Bookshelf must hold 20kg of weight per shelf, be 180cm tall, and have five shelves.' This list is your Requirements Traceability Matrix (RTM)—a document that tracks every single requirement from its origin (the friend's vague idea) through to the final product (the assembled shelf).
Then, you must prioritise: should I buy oak or pine? Is a glass door essential or just nice-to-have? You rank these based on value and risk—just like in IT, where you use the MoSCoW method (Must have, Should have, Could have, Won't have). Finally, you communicate constantly: you send your friend a diagram, confirm the wood type, and give progress updates. That's stakeholder communication—keeping everyone in the loop so the bookshelf actually fits in their living room. Without this process, you'd end up with a wobbly, too-tall monstrosity that blocks the window.
Requirements Management is the systematic process of gathering, defining, documenting, and controlling the requirements for a project. A 'requirement' is simply a condition or capability that must be present in a product, service, or result to satisfy a contract, standard, specification, or other formally imposed document. Think of it as the 'what' of the project—what does the end product need to do or be?
First, requirement gathering uses techniques like interviews, surveys, focus groups, or workshops. For example, a business might run a workshop where stakeholders write 'user stories'—short, simple descriptions of a feature told from the user's perspective: 'As a customer, I want to reset my password so I can log back into my account.' This is the raw material.
Next comes definition and documentation. Every requirement is written in a clear, testable format. A bad requirement is 'the system should be fast.' A good requirement is 'the system must process 95% of transactions in under 2 seconds.' You then enter each requirement into a 'Requirements Traceability Matrix' (RTM)—a table that links each requirement to its origin (which stakeholder asked for it), its status (approved, deferred, cancelled), and the deliverables that satisfy it. The RTM is a crucial tool because it ensures no requirement gets lost.
After documentation, you must prioritise the requirements. No project has unlimited time or money, so the team must decide which requirements are critical and which can wait. Two common prioritisation methods are:
MoSCoW: Must have (essential for launch), Should have (important but not vital), Could have (nice-to-have), Won't have (explicitly excluded this time).
Kano Model: Categorises requirements based on how they affect customer satisfaction. Basic Needs (must be there, no extra joy), Performance Needs (more is better), Excitement Needs (unexpected delights).
Finally, communication. A 'stakeholder' is any person or group affected by the project (e.g., sponsors, users, suppliers). Regular communication keeps stakeholders informed and engaged. Methods include status reports, meetings, dashboards, and 'walkthroughs' of the product.
Why does this all matter? Because the biggest cause of project failure is poor requirements—either misunderstood, incomplete, or ignored. The CAPM exam expects you to know that the PM (project manager) is responsible for managing the process, but the stakeholders and subject matter experts define the requirements. The business analyst may help with gathering, but the PM ensures it all ties back to the project charter (the document that authorises the project).
In summary, requirements management turns fuzzy wishes into a concrete, verifiable list of deliverables. Communication ensures everyone—from the CEO to the developer—shares the same understanding. Together, they form the backbone of project control and quality.
Identify Stakeholders
List every person or group who has an interest in the project's outcome. This includes sponsors, customers, end users, and subject matter experts. Without this, you risk missing critical requirements because you didn't ask the right people.
Collect Requirements
Use techniques like interviews, surveys, workshops, or document analysis to gather stated and unstated needs from stakeholders. This raw input becomes the basis for the requirements list.
Document Requirements
Write each requirement in a clear, measurable, and testable format. Give it a unique ID. Input these into the Requirements Traceability Matrix (RTM). This step ensures everyone has the same unambiguous reference point.
Prioritise Requirements
Apply a method such as MoSCoW (Must, Should, Could, Won't) or the Kano Model to rank requirements based on value, risk, cost, dependencies, and stakeholder importance. This helps decide what gets built first and what can wait.
Gain Approval and Communicate
Present the prioritised list of requirements to the stakeholders for sign-off. Once approved, communicate the baseline to the entire project team. Regularly update stakeholders on progress and any approved changes to requirements.
An IT project manager at a mid-sized bank is tasked with building a new mobile banking app called 'PocketBank'. Let's walk through how requirements management and communication play out in practice, step by step.
Step 1: Initial Stakeholder Identification. The PM lists everyone who has a stake: the head of retail banking (sponsor), three retail customers (end users from a focus group), the security officer, the head of IT operations, and the marketing director. The PM sends an email scheduling a one-hour kick-off workshop.
Step 2: Requirements Gathering Workshop. The PM facilitates the workshop. The sponsor says: 'The app must allow customers to view balances and transfer between accounts.' The security officer says: 'All logins must use multi-factor authentication.' The customers say: 'The app must be easy to use for my elderly mum' and 'I want to see my recent transactions quickly.' The PM writes these as raw statements on a whiteboard.
Step 3: Defining the Requirements. The PM turns each raw statement into a structured requirement: 'REQ-001: The app must display current and available balance for all linked accounts within 2 seconds of login.' 'REQ-002: All user sessions must be protected by a PIN or biometric factor (fingerprint/face ID) after 5 minutes of inactivity.' 'REQ-003: The app must have a font size selection option (small, medium, large) to accommodate users with visual impairments.' Each requirement gets a unique ID and is entered into the RTM (tracking spreadsheet).
Step 4: Prioritisation. The PM uses MoSCoW:
- Must have: Login, view balance, transfer funds (REQ-001, REQ-002). - Should have: Transaction history for last 90 days. - Could have: Customisable themes (colour schemes). - Won't have: Peer-to-peer payments in version 1.0. The sponsor approves the list. Everyone agrees version 1 is safe, secure, and provides core functionality.
Step 5: Ongoing Communication. Every two weeks, the PM sends a status email to all stakeholders: 'We have completed REQ-001 and REQ-002. The development of REQ-003 is 70% complete. No issues. The UAT (user acceptance testing) is scheduled for next month.' If a requirement changes (e.g., the security officer now wants face ID only), the PM updates the RTM, notifies everyone, and assesses the impact on time and cost.
Throughout, the PM also maintains a 'requirements log' and holds a weekly 15-minute stand-up meeting with the development team to ensure they understand each requirement clearly. Without this systematic approach, the app would risk missing a key feature (like multi-factor authentication) or the team would build something the sponsor never wanted (like a cryptocurrency trading feature for version 1).
The CAPM exam loves to test your understanding of requirements in the context of the PMBOK Guide, particularly in the 'Scope Management' knowledge area. You must know the exact sequence: Collect Requirements, Define Scope, Create WBS (Work Breakdown Structure). Here's what to focus on:
The Requirements Traceability Matrix (RTM) is a key exam concept. Questions will describe a scenario where a requirement is missing or changed, and you must choose the tool that tracks the requirement from origin to deliverable. The correct answer is the RTM.
MoSCoW method vs. Kano model. Be ready to distinguish them: MoSCoW is about priority for a specific release; Kano is about long-term customer satisfaction categories.
The exam tests that a 'business analyst' is often responsible for gathering requirements, but the project manager is accountable for the overall process being followed.
Watch for 'trap questions' where a requirement is 'implied' but not stated. For example, a stakeholder says 'we need a fast report.' You must know that 'fast' is ambiguous and needs clarification before documenting. The correct answer is to hold a meeting to define 'fast' in measurable terms (e.g., under 5 seconds).
Another common trap: questions where a change to a requirement occurs after the project charter is signed. The PM must use the 'integrated change control process' (a formal process to evaluate and approve changes) and update the RTM. Any answer that says 'just go ahead and change it' or 'tell the sponsor later' is wrong.
Key definitions to memorise:
'Requirement': a condition or capability needed by a stakeholder to solve a problem or achieve an objective.
'Stakeholder': any individual or group who can affect or be affected by the project.
'Scope Creep': uncontrolled changes or continuous growth in project scope without proper approvals (a big exam no-no).
'Traceability': the ability to link a requirement to its source, its status, and the deliverables that satisfy it.
Exam questions often present a situation and ask: 'What should the PM do first?' Typical correct answers involve referencing the RTM, holding a requirements clarification workshop, or engaging the sponsor to approve priorities. Wrong answers often involve ignoring the requirement, assuming it's understood, or delegating solely to a developer without documentation.
A requirement is a condition or capability that must be met or possessed by a project to satisfy a contract, standard, or stakeholder need.
The Requirements Traceability Matrix (RTM) links each requirement back to its origin and forward to the deliverable that satisfies it.
MoSCoW stands for Must have, Should have, Could have, Won't have — a method for prioritising requirements for a specific release.
Stakeholder communication keeps everyone informed of requirement changes, status, and decisions, preventing misunderstandings and scope creep.
Scope creep is the uncontrolled expansion of project scope without proper approvals and is a major reason projects fail.
Requirements gathering is an iterative process, not a one-time event at the start of the project.
The project manager is accountable for the requirements process, but stakeholders and experts define the requirements themselves.
These come up on the exam all the time. Here's how to tell them apart.
Requirements Traceability Matrix (RTM)
Tracks each individual requirement from origin to deliverable.
Used as a living document throughout the project, updated with status and changes.
Focuses on traceability and accountability for each requirement.
Project Scope Statement
Describes the overall boundaries of the project, including what is in and out of scope.
Created at the start and baselined; changes follow a formal process.
Focuses on the project's high-level deliverables and constraints.
MoSCoW Method
Categories: Must have, Should have, Could have, Won't have.
Used for prioritising requirements within a single release or iteration.
Focuses on the immediate need and feasibility within time and budget.
Kano Model
Categories: Basic Needs, Performance Needs, Excitement Needs.
Used for understanding long-term customer satisfaction and differentiation.
Focuses on the psychological impact of features on user delight.
Business Analyst
Primary role is to gather, analyse, and document requirements from stakeholders.
Works closely with users to understand needs and translate them into technical specs.
Responsible for the quality and completeness of the requirements.
Project Manager
Primary role is to plan, execute, monitor, control, and close the project.
Manages resources, time, budget, and risks across the whole project.
Responsible for the overall process and ensuring requirements align with business goals.
User Story
Informal, natural language description from the user's perspective.
Format: 'As a [user], I want [goal] so that [reason].'
Commonly used in agile projects and leaves room for discussion.
Functional Requirement
Formal, detailed, and specific description of what the system must do.
Format: 'The system shall [action] under [condition].'
Commonly used in waterfall projects and leaves little ambiguity.
Mistake
Requirements are only gathered once at the start of the project, and then the team just builds them.
Correct
Requirements are gathered continuously and refined throughout the project, especially as more is learned. The initial set is an 'as-known' baseline, but changes are managed through a formal process.
This confusion persists because in some non-IT fields (like construction), requirements are often frozen early. Beginners assume IT projects work the same way, but agile methods and changing markets demand flexibility.
Mistake
The project manager should write all the requirements themselves because they 'own' the project.
Correct
The project manager facilitates the process, but the requirements come from stakeholders, users, and subject matter experts. The PM is responsible for the method, not the content.
The title 'manager' leads beginners to believe the PM must do everything. In reality, the PM lacks the detailed knowledge of the business domain to author requirements correctly.
Mistake
If a requirement is not documented, it's still valid if 'everyone knows it'.
Correct
In formal project management, only documented, approved requirements count. Informal assumptions lead to disputes and scope creep.
We often rely on shared understanding in everyday life (e.g., 'of course the kitchen has a sink'), but projects involve many people over long periods, and memory fades. Documentation is the only reliable record.
Mistake
Prioritisation means ranking requirements only by business value—the most valuable ones go first.
Correct
Prioritisation considers many factors: business value, risk, cost, dependencies, regulatory requirements, and technical feasibility. A high-value feature may be delayed because it depends on a risky technology being built first.
Business value is an easy yardstick for beginners to grasp, but real-world priority decisions are multifaceted. The CAPM exam tests this nuance.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A requirement describes a specific capability or condition needed from the product (e.g., 'the app must support fingerprint login'). Project scope is the sum total of all the work required to deliver that product, including the requirements and the tasks to build them.
The PMBOK Guide recommends it for all projects, but its complexity scales. For a tiny project (like updating a website button), a simple spreadsheet is fine. For large projects with many stakeholders, it's essential to keep everything organised.
The new requirement must go through the integrated change control process. You document the change, assess its impact on time, cost, and scope, and then seek approval from the sponsor or change control board before adding it.
The business analyst often performs the detailed work of gathering and documenting requirements. However, the project manager is accountable for ensuring the process is followed and that requirements align with the project charter and stakeholders' needs.
The Kano Model categorises requirements into Basic Needs (essential but no satisfaction if met), Performance Needs (more of this increases satisfaction), and Excitement Needs (unexpected delights that cause high satisfaction). It helps prioritise features that truly delight customers versus those that are expected.
Scope creep is uncontrolled growth of the project's scope without formal approvals. Requirements management prevents it by documenting a baseline of approved requirements and then requiring a formal change process for any new or modified requirements.
You've finished Requirements Management and Communication. Continue through the CAPM study guide to build a complete picture of the exam.
Done with this chapter?