Home › Free PMP lessons › Scope & Requirements

PMP lesson · Scope & Requirements · Scope · lesson 1 of 3 · about 8 minutes

Collecting requirements and the traceability matrix

Predictive · hybrid · (agile: backlog with acceptance criteria)Free preview
Goal: After this lesson you can choose an elicitation technique for a situation, tell different types of requirements apart, and use a traceability matrix to make sure nothing is lost.

1The situation

The requirement that disappeared

In the robot cell workshops, the customer's IT manager asked for automatic recipe download from the MES. Everyone nodded, and it was written in the minutes.

Six months later, at the factory acceptance test, the IT manager asks: “Where is the MES download?” Nobody designed it. It was in the minutes, but it never reached the design specification.

Requirements are not lost because people are careless. They are lost because there is no thread connecting each requirement to its design, its test and its acceptance. That thread is the traceability matrix.

2Getting the right requirements

Different situations need different elicitation techniques:

TechniqueBest when…
InterviewsYou need detailed, individual knowledge from experts
Workshops (facilitated)Several stakeholders must agree; cross-functional decisions
Focus groupsYou want opinions and attitudes of a user group
QuestionnairesMany people, spread out, quick answers needed
Observation (job shadowing)People cannot describe what they really do
PrototypesUsers must see or try something to give useful feedback
Document analysisExisting procedures, contracts or legacy systems hold the answers
BenchmarkingYou want to compare with other organisations' practices
Exam shortcut: can't describe their real work → observation · must see it → prototype · many people far away → questionnaire · conflicting stakeholders → facilitated workshop.

3From need to proof

Business need · “Reduce manual loading labour by 2 operators per shift.”
→
Business case & charter
Stakeholder requirement · “Operators must change product type in under 10 minutes.”
→
Requirements documentation
Solution requirement · “Gripper quick-change tool; recipe selection on the HMI.”
→
Design specification
Acceptance test · “FAT step 14: changeover timed at ≤ 10 min, 3 runs.”
→
Test protocol & sign-off
Every requirement should travel down this chain and arrive at a test.

4How it looks on the exam

Exam-style question 1. During acceptance testing, the customer reports that an approved requirement for automatic recipe download was never implemented. The requirement was recorded in workshop minutes but not in the design specification. What would have BEST prevented this?
A. A more detailed project charter
B. A requirements traceability matrix linking requirements to design and tests
C. More frequent status meetings
D. A larger testing team
Show the answer and the decode
Answer: B.
In simple English
An approved requirement got lost between the workshop and the design.
What is the question really asking?
What would have prevented it.
Key words / trigger
“never implemented … not in the design specification”
PMP logic
The RTM links each requirement to its design and test, so a missing link is visible early.
Why the wrong answer looks attractive
More testers would find the gap at the same late stage instead of preventing it.

5Remember this

Your memory card

  • Choose elicitation by situation: observe real work, prototype when they must see it, workshop to agree
  • Requirements: business → stakeholder → solution → transition
  • RTM links each requirement to source, design and test; empty cells = danger
  • Agile: stories with acceptance criteria do the same job
The full lesson in the PMCLEAR app also has:
  • the rest of the lesson (Kinds of requirements, The traceability matrix)
  • a worked example
  • the common traps (wrong vs right)
  • 2 exam-style questions with the decode
  • a 3-question quick check
Open the full lesson → Create a free account
← Sprint planning: goal, capacity and commitmentNext: WBS and the scope baseline →