SkarpSkarp

Chapter 17 of 20

Requirements Analysis, Prioritization, and the Requirements Traceability Matrix

Transform raw requirements into an organized, traceable set of needs by analyzing, grouping, and prioritizing them and linking them through a requirements traceability matrix.

27 min readen

Module Overview: From Raw Requirements to Organized Insight

Where We Are in the Journey

You already learned how to elicit and write good requirements. This module covers what happens after elicitation: analyzing, prioritizing, and tracing those requirements so the project can actually manage them.

Three Big Skills

We focus on three skills: 1) analyzing and modeling requirements, 2) prioritizing them using MoSCoW and value vs. effort, and 3) linking them through a requirements traceability matrix.

Canonical Definition to Memorize

For the exam, lock in this definition: "A grid that links product requirements from their origin to the deliverables that satisfy them." That is the requirements traceability matrix.

Your Running Example

We will use a realistic scenario: designing a new university course registration portal. Each technique will be applied to this example so you see how the pieces connect.

Step 1: What Is Requirements Analysis and Why Does It Matter?

Definition and Purpose

Requirements analysis is where you examine, structure, and refine elicited requirements so they are clear, feasible, and aligned with business objectives. It turns messy ideas into usable inputs for design and testing.

Key Goals

Goals include clarifying meaning, checking feasibility, aligning each requirement with business goals or regulations, and preparing them so designers and testers know exactly what to build and verify.

Exam-Linked Skills

Analysis supports gap analysis, creating testable requirements (including nonfunctional ones), and modeling processes to reveal bottlenecks and hidden rules. These are all tested under Business Analysis Frameworks.

Common Exam Trap

Do not confuse analysis with passive documentation. On the exam, correct options show the BA actively interpreting, organizing, and challenging requirements, not just typing meeting notes.

Step 2: Core Analysis Techniques – Decomposition, Grouping, Modeling

Decomposition

Decomposition breaks a big, vague requirement into smaller, precise ones. Instead of "support registration", you create specific items like search, add course, detect conflicts, and confirm registration.

Link to WBS Thinking

This is similar to a work breakdown structure: a hierarchical decomposition of project work. Here you decompose requirements, not tasks, but the goal is the same—clarity and manageability.

Grouping Requirements

Grouping clusters requirements by type (functional/nonfunctional), process step, or stakeholder. This reveals overlaps, conflicts, and missing pieces, and supports gap analysis between current and future state.

Modeling for Insight

Models like swimlane process maps, SIPOC diagrams, and decision tables turn text into visuals. They expose missing approvals, error paths, and business rules that pure text often hides.

Step 3: Worked Example – From Vague to Testable Requirements

Start with Vague Statements

Stakeholders say: "The system should be fast", "Only authorized people should change grades", and "It must be easy to use". These are not yet testable or precise enough for design and testing.

Make Performance Measurable

Clarify "fast" into a nonfunctional requirement: e.g., results shown within 2 seconds for 95% of requests under a defined user load. Now performance testers know what to measure.

Define Access-Control Rules

Clarify "authorized" by naming roles: e.g., only users with Instructor or Registrar roles can modify final grades. This becomes a specific security requirement.

Usability as Acceptance Criteria

Turn "easy to use" into measurable acceptance criteria: e.g., new students can complete registration in 10 minutes with no more than one error. This supports usability testing and traceability.

Step 4: Prioritization Basics and the MoSCoW Technique

Why Prioritize?

You rarely have the time or budget to do everything at once. Prioritization decides what to deliver first, what to defer, and how to maximize business value under constraints.

MoSCoW Categories

MoSCoW = Must-have, Should-have, Could-have, Won’t-have (this time). Each requirement is classified into one of these to guide trade-offs and release planning.

Portal Example

For the portal: enrolling in courses is Must-have; seeing waitlist position is Should-have; SMS reminders are Could-have; integration with external career platforms is Won’t-have for now.

Exam Tips

On the exam, Must-haves often relate to legal, safety, or core business needs. True prioritization avoids calling everything Must-have and involves stakeholders in value decisions.

Step 5: Apply MoSCoW to Sample Requirements

Try this thought exercise. Imagine you are helping prioritize features for the first release of the course registration portal. Assume the university has a tight deadline to replace a failing legacy system before the next semester.

Classify each requirement as Must-have, Should-have, Could-have, or Won’t-have (this time) for the first release. There is not a single "right" answer, but think like a pragmatic BA under time pressure.

Requirements:

  1. R‑F‑01: Students can search and enroll in courses.
  2. R‑F‑02: Advisors can approve course overloads online instead of paper forms.
  3. R‑NF‑01: The system complies with student data privacy regulations.
  4. R‑UX‑01: The interface supports dark mode.
  5. R‑INT‑01: The portal integrates with the campus mobile app for push notifications.
  6. R‑REP‑01: The registrar can export enrollment statistics to CSV.

Your task

  1. For each requirement, decide its MoSCoW category.
  2. Then, ask yourself: Which ones are tied to regulations, core business operations, or critical stakeholder needs? Those tend to be Must-haves.
  3. Finally, identify at least one requirement you would explicitly label Won’t-have (this time) to protect the schedule.

Pause for a minute and make your choices. Afterward, compare your reasoning to the guidance in the next steps of the module.

Step 6: Value vs. Effort Prioritization and Trade-offs

Value vs. Effort Matrix

You estimate each requirement’s value and effort, then place it into one of four quadrants: quick wins, major bets, fill-ins, and likely drops. This visual helps guide trade-offs.

Defining Value and Effort

Value includes contribution to objectives, compliance, risk reduction, and satisfaction. Effort includes time, cost, technical complexity, and implementation risk.

Portal Examples

Quick win: export timetable to calendar. Major bet: multi-data-center load balancing. Fill-in: custom color themes. Likely drop: AI course recommendations in the first release.

Exam Angle

Correct options show the BA facilitating, not dictating. They use simple scoring or a 2x2 matrix and relate value to measurable metrics for later solution evaluation.

Step 7: Requirements Traceability Matrix – Definition and Structure

Canonical Definition

Memorize this: a requirements traceability matrix is "A grid that links product requirements from their origin to the deliverables that satisfy them." Each row usually represents one requirement.

Typical RTM Columns

Common columns: requirement ID and description, source/origin, priority, design elements, test cases, deliverables, and status. Together they form a map from need to solution.

How It Supports the Exam Skills

Traceability links requirements to objectives, regulations, design, and tests, and allows impact analysis when requirements change. It also supports evaluating whether the solution met needs.

Predictive vs. Adaptive

In predictive life cycles the RTM is often a formal document. In adaptive life cycles, traceability is embedded in tools and links between backlog items, designs, and tests.

Step 8: Sample RTM for the Course Registration Portal

Visualizing the RTM

Imagine the RTM as a spreadsheet where each row is a requirement and columns capture source, priority, design elements, test cases, and deliverables. This grid is the trace map.

Reading the Example

R-F-01 traces from student survey to the enrollment screen, test case TC-01, and the enrollment module deliverable. A change in R-F-01 impacts all these linked items.

Using It for Impact Analysis

If a requirement changes or is removed, you scan its row to see which designs, tests, and deliverables are affected. This is core to structured impact analysis.

Supporting Trade-off Decisions

When cutting scope, the RTM shows which objectives and stakeholders are tied to each requirement, helping justify why a "Could-have" like push notifications can be deferred.

Step 9: Quick Check – RTM and Impact Analysis

Answer this CAPM-style question to check your understanding of traceability and impact analysis.

During user acceptance testing, a stakeholder requests a change to how course prerequisites are validated in the registration portal. What is the BEST first action for the business analyst to take?

  1. Update the project schedule to include additional development and testing time.
  2. Review the requirements traceability matrix to identify all design elements and test cases linked to the prerequisite validation requirement.
  3. Ask the development team to provide a rough cost estimate before doing any further analysis.
  4. Approve the change if it improves user satisfaction, since user needs are the highest priority.
Show Answer

Answer: B) Review the requirements traceability matrix to identify all design elements and test cases linked to the prerequisite validation requirement.

The best first step is to understand the full impact of the requested change. Reviewing the requirements traceability matrix shows which design components, test cases, and deliverables are linked to the affected requirement. Only after impact is understood should you move to estimating cost, adjusting schedules, or recommending approval or rejection.

Step 10: Quick Check – MoSCoW Prioritization

Test your understanding of MoSCoW categories in a realistic scenario.

For the first release of the registration portal, the university must comply with a new national data privacy regulation that already entered into force. How should the related requirements MOST appropriately be categorized using MoSCoW?

  1. Could-have, because they do not directly affect student satisfaction.
  2. Should-have, because they are important but can be delayed to a later release.
  3. Must-have, because without compliance the solution is not viable or could expose the university to legal risk.
  4. Won’t-have (this time), because regulations can be handled through manual workarounds.
Show Answer

Answer: C) Must-have, because without compliance the solution is not viable or could expose the university to legal risk.

Regulatory compliance requirements are typically Must-have. Without them, the solution may be illegal or expose the organization to significant risk, so the system would not be considered acceptable for production use.

Step 11: Flashcards – Key Terms and Concepts

Use these flashcards to reinforce critical definitions and concepts that are likely to appear on the CAPM exam.

requirements traceability matrix
A grid that links product requirements from their origin to the deliverables that satisfy them.
MoSCoW categories
Must-have, Should-have, Could-have, Won’t-have (this time). Used to prioritize requirements and features.
acceptance criteria
A set of conditions that is required to be met before deliverables are accepted.
adaptive life cycle
A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
predictive life cycle
A development life cycle in which the project scope, time, and cost are determined in the early phases of the life cycle.
work breakdown structure
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.
Gap analysis (in requirements)
Comparing current-state and future-state capabilities across people, process, policy, and technology to identify required changes and missing requirements.
Testable requirement
A requirement expressed with clear, measurable conditions so that a test case can objectively determine whether it is satisfied.
Value vs. effort matrix
A prioritization tool that classifies requirements based on their business value and implementation effort, highlighting quick wins and likely deferrals.
Impact analysis
The process of assessing the effects of adding, changing, or removing a requirement by examining its links to design elements, tests, deliverables, and objectives, often using the RTM.

Step 12: Pulling It Together – From Requirements to Business Value

Step 1: Analyze and Clarify

Turn vague ideas into testable requirements. Decompose, group, and model processes to reveal gaps, then perform gap analysis across people, process, policy, and technology.

Step 2: Prioritize

Use MoSCoW and value vs. effort to decide what comes first. Facilitate stakeholder discussions so Must-haves and quick wins are clear and realistic.

Step 3: Trace and Manage Change

Maintain an RTM—a grid that links product requirements from their origin to the deliverables that satisfy them. Use it to assess change impacts and evaluate whether the solution met its goals.

Your Next Moves

Your diagnostic and mock exams will reveal strengths and gaps. Aim to recall the RTM definition, apply MoSCoW, and describe RTM-based impact analysis confidently in exam-style scenarios.

Key Terms

MoSCoW
A prioritization technique that classifies requirements as Must-have, Should-have, Could-have, or Won’t-have (this time).
gap analysis
A comparison of current-state and future-state capabilities across people, process, policy, and technology to identify what changes and requirements are needed.
impact analysis
The process of assessing the effects of adding, changing, or removing a requirement by examining its links to design elements, test cases, deliverables, and objectives.
acceptance criteria
A set of conditions that is required to be met before deliverables are accepted.
testable requirement
A requirement expressed with clear, measurable conditions so that a test case can objectively determine whether it has been satisfied.
requirements analysis
The set of activities used to examine, structure, and refine elicited requirements so they are clear, feasible, consistent, and aligned with business objectives, and ready for design and testing.
value vs. effort matrix
A prioritization tool that classifies requirements based on their business value and implementation effort, highlighting quick wins and items to defer.
nonfunctional requirement
A requirement that describes how a system performs a function (such as performance, security, usability, or reliability) rather than what functions it performs.
requirements prioritization
The process of deciding the relative importance and implementation order of requirements, often using techniques such as MoSCoW or value vs. effort.
requirements traceability matrix
A grid that links product requirements from their origin to the deliverables that satisfy them.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself