SkarpChapter 18 of 21
Requirements Analysis, Traceability, and the Product Backlog in BA
Trace every requirement from its origin to delivered value, and see how tools like the requirements traceability matrix and product backlog keep complex change under control.
Step 1 – From Vague Wishes to Testable Requirements
Your Core BA Job
In projects, your core BA job is to turn stakeholder wishes into clear, testable requirements that can be built, traced, and verified.
What Is a Requirement?
Think of a requirement as a statement of need the solution must satisfy. It can be functional (what it does) or nonfunctional (how well it performs, secures, or behaves).
Acceptance Criteria
Acceptance criteria are "A set of conditions that is required to be met before deliverables are accepted." They make requirements objectively testable.
Why Testability Matters
A testable requirement can be observed or measured, leads to a clear pass/fail result, and is specific enough to guide design and testing.
Vague Stakeholder Statements
Real stakeholders say things like "user friendly" or "fast" or "better security". These are not yet proper requirements; they must be refined.
Step 2 – Converting Vague Statements into Measurable Acceptance Criteria
From Fuzzy to Testable
Your job is to turn fuzzy phrases like "user friendly" or "fast" into specific, measurable acceptance criteria that can be tested.
Example: User Friendly Login
Instead of "user friendly", define criteria such as: 90% of new users complete login and setup unaided; 95% logins complete within 20 seconds.
Example: Fast Reports
Replace "reports should be fast" with: the 12‑month sales summary report loads within 5 seconds for 95% of requests during business hours.
Example: Better Security
Translate "better security" into specifics: encrypt data at rest with AES‑256; only certain roles can view full addresses; others see partial data.
Why This Matters
These clarified statements become nonfunctional requirements with clear acceptance criteria, guiding design and test cases and reducing ambiguity.
Step 3 – Eliciting and Validating Testable Requirements (Including Nonfunctional)
Eliciting Requirements
Use interviews, workshops, observation, surveys, and prototyping to uncover needs. Always ask: "How will we know this works?"
Focus on Measurability
Push stakeholders to define what they would measure to prove success and what minimum/maximum values are acceptable.
Nonfunctional Requirements
Performance, security, usability, reliability, and compliance are nonfunctional areas that often start vague and need careful quantification.
Validating Requirements
Validate that requirements are aligned with objectives and regulations, feasible, consistent, and testable using clear acceptance criteria.
Exam Tip
When you see vague or conflicting requirements in CAPM questions, the best next step is usually to clarify and validate, not design a solution.
Step 4 – Requirements Traceability Matrix: Canonical Definition and Structure
Canonical Definition
A requirements traceability matrix is "A grid that links product requirements from their origin to the deliverables that satisfy them."
What It Maps
It maps each requirement from its origin (stakeholder, regulation, business case) to design, build, and test artifacts that implement it.
Typical Columns
Common columns: Requirement ID, description, source, business objective, regulation link, design element or WBS item, test cases, and status.
Why It Matters
Traceability proves coverage, prevents gold-plating, supports audits, and lets you assess the impact when requirements change.
Exam Signal
If a question mentions a matrix linking requirements to test cases, design, or regulations, they are describing a requirements traceability matrix.
Step 5 – Mini Traceability Matrix: Linking to Objectives, Design, and Tests
Scenario: Online Booking
Project: add online appointment booking. Objective OBJ‑1: cut call-center load by 30% in 6 months by moving bookings online.
Sample Requirements
REQ‑01: fast slot search; REQ‑02: email confirmation within 1 minute; REQ‑03: only authenticated patients can book.
Backward Links
Each requirement links back to a source (manager, patients, compliance) and to OBJ‑1, showing why it exists.
Forward Links
Each requirement links forward to design elements (APIs, UI, services) and test cases that verify it.
Value and Compliance
This mini matrix proves coverage toward the objective and shows controls like access restrictions for compliance and security.
Step 6 – Thought Exercise: Using Traceability for Impact Analysis
Use this scenario to practice impact analysis with a mental traceability matrix. Think it through before checking the guidance.
Scenario
You are the BA on a payment system upgrade. Your matrix includes:
- REQ‑10: "System must support credit card payments using Visa and Mastercard." (Source: Sales)
- REQ‑11: "System must store only the last 4 digits of the card number and a token; full card numbers must never be stored." (Source: Security policy, PCI-DSS)
- REQ‑12: "Refunds must be processed back to the original payment method within 3 business days." (Source: Customer service)
Linked items:
- Design elements
- Visa/Mastercard payment gateway integration (DE‑A)
- Tokenization service (DE‑B)
- Refund processing workflow (DE‑C)
- Test cases
- TC‑10: Pay with Visa
- TC‑11: Pay with Mastercard
- TC‑12: Verify only last 4 digits stored
- TC‑13: Refund processed within 3 business days
Change request
A stakeholder asks to remove REQ‑11 to "simplify development" and allow storing full card numbers.
Your task
- List at least three impacts this change would have, using the traceability links.
- Decide whether this is mainly a scope, schedule, risk, or compliance impact (or a mix).
- Think about who you must inform or get approval from.
Pause and answer these in your own words. Then compare with the guidance below.
---
Sample reasoning (for self-check)
- Impacts:
- Violates the security policy and likely PCI-DSS obligations.
- Requires changes to DE‑B tokenization service design and TC‑12 test case.
- Increases risk of data breach, legal penalties, and reputational damage.
- Impact types: mainly risk and compliance, plus scope changes to design and testing.
- Stakeholders: security officer, legal/compliance, product owner, project sponsor.
On the exam, when asked how to assess such a change, the best answer usually involves consulting the requirements traceability matrix and key stakeholders before approving or rejecting the change.
Step 7 – Product Backlog as a BA Artifact in Adaptive Life Cycles
Adaptive Life Cycle
An adaptive life cycle is "A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration."
Product Backlog Definition
The product backlog is "An ordered list of everything that is known to be needed in the product, managed by the product owner."
What’s in the Backlog?
User stories, defects, technical work, and research tasks. Each item embodies one or more requirements with acceptance criteria.
BA’s Role with the Backlog
BAs refine items, clarify acceptance criteria, ensure alignment with objectives and regulations, and support prioritization (e.g., MoSCoW).
Backlog vs. Specs
In predictive life cycles you have big specs and matrices; in adaptive life cycles the backlog is the live requirements repository, but traceability still matters.
Step 8 – Aligning Product Backlog Items with Traceability
Sample User Story
US‑05: "As a patient, I want to receive an email confirmation after booking so that I have proof of my appointment."
Acceptance Criteria for US‑05
Email sent within 1 minute; includes appointment details and cancellation link; EU emails comply with GDPR Article 13 notices.
Backward Links
US‑05 links back to business objective OBJ‑1, GDPR Article 13, and the patient advisory group as the stakeholder source.
Forward Links
It links forward to design (notification service, templates) and test cases (timing, content, GDPR wording).
Practical Tooling
Use backlog fields or tags for objective and regulation IDs, or keep a small traceability matrix keyed by backlog item ID.
Step 9 – Quick Check: Traceability and Backlog
Answer this CAPM-style question to check your understanding of traceability and the product backlog.
An agile team maintains a product backlog of user stories. The BA wants to ensure that for each story, they can quickly see which business objective it supports and which test cases verify it. Which approach best supports this goal?
- Ask developers to mention the related objective and test cases during daily standups
- Add fields or tags to backlog items for objective IDs and test case IDs, and use them as a lightweight traceability matrix
- Create a separate risk register listing all user stories and their test cases
- Rely on the product owner’s memory of which stories support which objectives
Show Answer
Answer: B) Add fields or tags to backlog items for objective IDs and test case IDs, and use them as a lightweight traceability matrix
Adding fields or tags to backlog items for objective IDs and test case IDs creates a lightweight form of a requirements traceability matrix. It links requirements (user stories) back to business objectives and forward to test cases. The other options are informal or misuse other artifacts (like the risk register) and do not provide reliable traceability.
Step 10 – Quick Check: Impact of Requirement Changes
Test your understanding of how to use traceability for impact analysis.
Midway through a project, a stakeholder requests to remove a previously approved requirement. What is the BEST first step for the BA?
- Immediately remove the requirement to keep the stakeholder satisfied
- Update the work breakdown structure and schedule without further analysis
- Use the requirements traceability matrix to identify affected design components, test cases, and business objectives
- Ask the project sponsor to reject the change to avoid scope creep
Show Answer
Answer: C) Use the requirements traceability matrix to identify affected design components, test cases, and business objectives
The best first step is to consult the requirements traceability matrix to understand the full impact of removing the requirement on design, testing, and business objectives. Only after this analysis should the team make a decision. Automatically accepting or rejecting the change, or updating plans without analysis, ignores the structured information the matrix provides.
Step 11 – Flashcards: Key Terms and Definitions
Use these flashcards to reinforce key 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.
- Product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- 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.
- Purpose of a requirements traceability matrix
- To link requirements back to their sources (stakeholders, objectives, regulations) and forward to design elements and test cases, enabling coverage checks and impact analysis.
- Testable requirement
- A requirement that is specific and measurable so that objective pass/fail test cases can be defined against it.
- Nonfunctional requirement example
- Performance: "Report X must display a 12‑month date range within 5 seconds for 95% of requests during business hours."
- How the product backlog relates to requirements
- In adaptive projects, it acts as a living repository of requirements (user stories, defects, etc.), each with acceptance criteria, which can be linked to objectives, regulations, and tests for traceability.
Key Terms
- user story
- A short, simple description of a feature told from the perspective of the user or customer, often used as a product backlog item in agile projects.
- impact analysis
- The process of using traceability and other information to assess how adding, changing, or removing a requirement will affect scope, design, testing, schedule, cost, risk, and compliance.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- 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.
- MoSCoW prioritization
- A technique that categorizes requirements into must-have, should-have, could-have, and won’t-have to support prioritization and trade-off decisions.
- nonfunctional requirement
- A requirement that describes how well a system must perform (e.g., performance, security, usability, reliability, compliance) rather than what functions it provides.
- requirements traceability matrix
- A grid that links product requirements from their origin to the deliverables that satisfy them.