An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.

A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.

A short, simple description of a feature told from the perspective of the person who desires the new capability, often using the format: "As a [user], I want [goal] so that [reason]."

An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.

Requirements Analysis, Prioritization, and the Product Backlog — CAPM Mastery: Comprehensive Exam-Ready Preparation for the 2023+ CAPM Blueprint

Q: A team has collected many stakeholder requests for a new customer portal. Before finalizing the scope baseline, the business analyst groups large, vague requests into smaller, testable items and then works with the product owner to order them in the product backlog. Which two activities are being performed?

Decomposition and prioritization. The BA is turning large, vague requests into smaller, testable items (decomposition) and then ordering them in the product backlog with the product owner (prioritization). The other options describe unrelated processes.

From Elicited Requirements to Analyzed Requirements

Why Analysis Matters

You now move from eliciting to analyzing requirements: turning raw stakeholder input into structured, prioritized items that can guide delivery in predictive and agile projects.

Key Definitions

A requirement is a condition or capability needed by a stakeholder. A stakeholder is "An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by" a project outcome.

Project Context

A project is "A temporary endeavor undertaken to create a unique product, service, or result." Requirements analysis ensures that project work actually delivers what stakeholders need.

Core Analysis Activities

Analysis includes clarifying meaning, decomposing big requirements, checking feasibility and testability, prioritizing, and preparing requirements for artifacts like the WBS, schedule, and product backlog.

Exam Hint

On CAPM questions, when requirements are messy or conflicting, the best next step is often an analysis activity (clarify, decompose, prioritize) before locking down scope or dates.

Decomposing High-Level Requirements

What Is Decomposition?

Decomposition breaks large, high-level requirements into smaller, manageable pieces, similar to how a work breakdown structure decomposes project work.

WBS Definition Link

A work breakdown structure is "A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables."

Levels of Requirements

You often see business, stakeholder, solution (functional and nonfunctional), and transition requirements. Each level gets more detailed and closer to implementation.

Retail App Example

Business: "Enable customers to purchase online." Stakeholder: "Customers can create accounts." Solution: add to cart, pay with card or wallet, fast checkout performance.

When to Stop Decomposing

Stop when each requirement is small enough to be understood, estimated, built, and tested. In agile, that usually means it can fit comfortably within a single iteration.

Worked Example: Decomposing a Vague Requirement

The Vague Statement

Stakeholder: "We need a better portal where students can do everything online." This is too vague to plan from and must be decomposed.

Clarify Outcome

Ask what "do everything online" means. You learn key tasks: register for courses, pay tuition, see grades, update personal information.

High-Level Requirements

Business: enable core academic and financial tasks online. Stakeholder: students manage enrollment and payments without visiting campus offices.

Solution Requirements

Functional: enroll, drop, view balance, pay online, view grades. Nonfunctional: availability 99.5%, pages load within 3 seconds for most requests.

Testability and Next Steps

Ensure each requirement is testable, then ask which capabilities are most critical to release first. This leads into prioritization techniques.

Prioritization Basics and MoSCoW Technique

Why Prioritize?

You cannot build everything at once. Prioritization chooses what to implement first and what might be deferred or dropped when constraints tighten.

MoSCoW Categories

MoSCoW: Must have, Should have, Could have, Won't have (this time). Each category reflects how critical a requirement is.

Portal Example

For a first release: Must = enroll, pay, view grades. Should = update info. Could = dark mode. Won't = alumni donation features.

Exam Trap: Everything Is Must

On the exam, avoid treating all requirements as "Must". Good answers reflect trade-offs and realistic prioritization under constraints.

Life Cycles and MoSCoW

In a predictive life cycle scope, time, and cost are set early. In an adaptive life cycle scope per iteration is defined just before it starts. MoSCoW helps in both.

Value vs. Effort: Visual Prioritization

Value vs. Effort Overview

Value vs. effort uses a 2x2 grid with Value on one axis and Effort on the other, helping teams visually decide which requirements to do first.

Four Quadrants

Quadrants: 1) High value, low effort (quick wins). 2) High value, high effort (strategic). 3) Low value, low effort (fillers). 4) Low value, high effort (often dropped).

Portal Example Mapping

Quick wins: show balance, simple grades view. Strategic: self-service enrollment, payment integration. Fillers: profile pictures. Likely dropped: AI course recommender.

Exam Recognition

If an exam question mentions plotting items on a grid to decide sequence, it is likely describing a value vs. effort style prioritization technique.

Benefits

This visual method supports transparent stakeholder discussions and works well in adaptive life cycles where backlog items are re-prioritized often.

The Product Backlog as a Business Analysis Artifact

Product Backlog Definition

PMI: A product backlog is "An ordered list of everything that is known to be needed in the product, managed by the product owner."

Key Ideas in the Definition

It is an ordered list (not a random pile), contains all known needs, and is managed by the product owner, who decides priorities.

Types of Backlog Items

Items can be user stories, technical tasks, defects, or research spikes. Each represents work needed to improve the product.

BA Role in the Backlog

The BA helps refine items, add acceptance criteria, clarify dependencies, and ensure requirements are clear and testable.

Predictive vs Adaptive Artifacts

Predictive projects lean on formal specs and WBS. Adaptive projects center on the product backlog to manage evolving requirements.

User Stories and Acceptance Criteria

User Story Format

User stories often use: "As a [user], I want [goal] so that [reason]." They capture requirements from the user's perspective.

Portal Story Example

"As a student, I want to pay my tuition online so that I do not have to visit the finance office in person."

Acceptance Criteria Definition

Acceptance criteria are "A set of conditions that is required to be met before deliverables are accepted." They make stories testable.

Sample Acceptance Criteria

For online payment: enter amount, see total, validate card, show errors, send confirmation, and ensure failed payments do not change balance.

Agile and Predictive Use

In agile, criteria guide sprint testing. In predictive, similar conditions appear in specs and test plans. Both define when work is truly accepted.

Traceability: Connecting Requirements to Scope and Delivery

What Is Traceability?

Traceability connects each requirement to its source and to the deliverables that satisfy it, ensuring nothing important is lost or built without purpose.

RTM Definition

A requirements traceability matrix is "A grid that links product requirements from their origin to the deliverables that satisfy them."

RTM Contents

Typical columns: requirement ID, description, source, related design or user stories, test cases, and status across the lifecycle.

WBS and Work Packages

A work package is "The work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed." Requirements map to these.

Exam Use Cases

When asked how to ensure all requirements are delivered or to analyze change impacts, the requirements traceability matrix is usually the right answer.

Thought Exercise: From Requirement to Backlog and WBS

Work through this mentally (or jot notes). This will help you connect requirements analysis to both agile and predictive artifacts.

Scenario: A city library is launching a new mobile app. One high-level requirement is:

"Patrons must be able to borrow and return e-books using the mobile app."

Your tasks:

Decompose the requirement

Identify at least 3 more detailed functional requirements that support this high-level statement.
Example starter: "Patrons can search for available e-books by title or author."

Draft a user story

Write one user story in the standard format that captures a key part of this requirement.
Example structure: "As a [patron], I want [goal] so that [reason]."

Propose 2–3 acceptance criteria

For your user story, describe specific conditions that must be true for the story to be accepted.
Aim for criteria that could be tested.

Map to predictive artifacts

Imagine this is a predictive project with a WBS. Describe one work package that might appear in the WBS to implement your user story.
Remember: a work package is the lowest level of work where cost and duration are estimated and managed.

Reflect

Which parts of your thinking felt more "agile" (e.g., user stories, acceptance criteria)?
Which parts felt more "predictive" (e.g., work package, up-front decomposition)?

Pause for 3–4 minutes and actually write your answers. This mirrors the kind of reasoning CAPM questions expect: moving smoothly between requirements, backlog items, and scope planning.

Quiz 1: Analysis, Prioritization, and Backlog Basics

Test your understanding of core concepts so far.

A team has collected many stakeholder requests for a new customer portal. Before finalizing the scope baseline, the business analyst groups large, vague requests into smaller, testable items and then works with the product owner to order them in the product backlog. Which two activities are being performed?

Decomposition and prioritization
Validation and schedule compression
Risk analysis and quality control
Configuration management and procurement planning

Show Answer

Answer: A) Decomposition and prioritization

The BA is turning large, vague requests into smaller, testable items (decomposition) and then ordering them in the product backlog with the product owner (prioritization). The other options describe unrelated processes.

Quiz 2: Recognizing Key Definitions

Check your recall of PMI definitions relevant to this module.

Which statement best matches PMI’s definition of "product backlog"?

A document listing all project risks and their responses, maintained by the project manager.
An ordered list of everything that is known to be needed in the product, managed by the product owner.
A grid that links product requirements from their origin to the deliverables that satisfy them.
A hierarchical decomposition of the total scope of work to be carried out by the project team.