Discovering Requirements and Defining Metrics
Learn to turn what people ask for into requirements and metric definitions that someone else could test. No coding: you work on the data of Raket Parts, a fictional maker of rocket parts.
You will be able to
- find every user of a report and the decision each one makes
- separate real needs from proposed solutions
- write requirements someone else can test
- cover missing and cancelled cases before work starts
Who is this report really for?
Identify every user and decision, test the source and record constraints and unresolved conflicts.
Needs, not wish lists
Separate needs from solutions, ask neutral questions, examine actual work and record each finding with its source.
Requirements you can test
Write testable requirements, cover missing and cancelled cases and rank work against the decision.
A metric you can test
Specify a metric by counting unit, group, date, source and tests, and send rival definitions to one owner.
Outcomes, not activity
Define an outcome with a dated baseline and target, guardrails that name harms and leading indicators with lead times.
Challenging a set of leading indicators
Test the links an indicator set assumes and how each could be gamed.
Traceability and change control
Link each requirement to its source and test, and control changes after sign-off.
Mid-Path project: an order exception process
Requirements and metrics for one real process, start to finish.
Final assessment
Requirements, a metric specification and outcome measures on an unseen case.
Requirements and Metrics / Module 1
Who is this report really for?
Bram asks for a monthly late-delivery report for Sales. Maaike first needs to discover the decisions, users and limits behind the request. You will map them before anyone builds a view.
Sections
Requirements and Metrics / Module 1 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Requirements and Metrics / Module 2
Needs, not wish lists
Mira proposes an extra sign-off for credits. Maaike must find the actual need behind that idea, ask useful questions and check the service records. You will leave with a sourced list of needs, not a list of features.
This module builds on module 1. If you are new to this, start with module 1.
Sections
Requirements and Metrics / Module 2 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Requirements and Metrics / Module 3
Requirements you can test
The team says the late-delivery view must be accurate. That sounds fine until two readers count different lines. Maaike will turn the request into acceptance checks that make the treatment of difficult cases explicit.
This module builds on module 2. If you are new to this, start with module 2.
Sections
Requirements and Metrics / Module 3 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Requirements and Metrics / Module 4
A metric you can test
Bram and finance both measure enquiry conversion. Their answers differ because their groups differ. Maaike writes rules and test cases before asking an owner to choose.
This module builds on module 3. If you are new to this, start with module 3.
Sections
Requirements and Metrics / Module 4 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Requirements and Metrics / Module 5
Outcomes, not activity
The marketing team can count emails sent. Maaike asks how customers behaved, what harm a promotion could create and which earlier signal would warn the team.
This module builds on module 4. If you are new to this, start with module 4.
Sections
Requirements and Metrics / Module 5 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Requirements and Metrics / Module 1 / 1.1
1.1 What a precise metric needs
Section 1.1 complete
Next: 1.2 Find the hidden users
Requirements and Metrics / Module 1 / 1.2
1.2 Find the hidden users
Section 1.2 complete
Next: 1.3 Constraints: hard or negotiable
Requirements and Metrics / Module 1 / 1.3
1.3 Constraints: hard or negotiable
Section 1.3 complete
Next: 1.4 Needs that conflict
Requirements and Metrics / Module 1 / 1.4
1.4 Needs that conflict
Section 1.4 complete
Next: Module 1 check
Continue to the module check Recap this section Back to module 1
Requirements and Metrics / Module 1 / Check
Module 1 check
Module 1 complete
Next: Module 2, Needs, not wish lists
Continue to module 2 Try it on your own question Recap module 1 Back to module 1
Requirements and Metrics / Module 2 / 2.1
2.1 Need or proposed solution
Section 2.1 complete
Next: 2.2 Questions that do not lead
Requirements and Metrics / Module 2 / 2.2
2.2 Questions that do not lead
Section 2.2 complete
Next: 2.3 Watch what people do
Requirements and Metrics / Module 2 / 2.3
2.3 Watch what people do
Section 2.3 complete
Next: 2.4 Record it with its source
Requirements and Metrics / Module 2 / 2.4
2.4 Record it with its source
Section 2.4 complete
Next: Module 2 check
Continue to the module check Recap this section Back to module 2
Requirements and Metrics / Module 2 / Check
Module 2 check
Module 2 complete
Next: Module 3, Requirements you can test
Continue to module 3 Try it on your own question Recap module 2 Back to module 2
Requirements and Metrics / Module 3 / 3.1
3.1 Vague words fail
Section 3.1 complete
Next: 3.2 Condition, behaviour, criterion, source
Requirements and Metrics / Module 3 / 3.2
3.2 Condition, behaviour, criterion, source
Requirements and Metrics / Module 3 / 3.3
3.3 Edge cases
Section 3.3 complete
Next: 3.4 Priority follows the decision
Requirements and Metrics / Module 3 / 3.4
3.4 Priority follows the decision
Section 3.4 complete
Next: Module 3 check
Continue to the module check Recap this section Back to module 3
Requirements and Metrics / Module 3 / Check
Module 3 check
Module 3 complete
Next: Module 4, A metric you can test
Continue to module 4 Try it on your own question Recap module 3 Back to module 3
Requirements and Metrics / Module 4 / 4.1
4.1 Same enquiries, two rates
Section 4.1 complete
Next: 4.2 Counting unit, time rule and source fields
Requirements and Metrics / Module 4 / 4.2
4.2 Counting unit, time rule and source fields
Section 4.2 complete
Next: 4.3 Tests that catch a wrong build
Requirements and Metrics / Module 4 / 4.3
4.3 Tests that catch a wrong build
Section 4.3 complete
Next: 4.4 Options, missing fields and ownership
Requirements and Metrics / Module 4 / 4.4
4.4 Options, missing fields and ownership
Section 4.4 complete
Next: Module 4 check
Continue to the module check Recap this section Back to module 4
Requirements and Metrics / Module 4 / Check
Module 4 check
Module 4 complete
Next: Module 5, Outcomes, not activity
Continue to module 5 Try it on your own question Recap module 4 Back to module 4
Requirements and Metrics / Module 5 / 5.1
5.1 Activity is not an outcome
Section 5.1 complete
Next: 5.2 Outcome, baseline and dated target
Requirements and Metrics / Module 5 / 5.2
5.2 Outcome, baseline and dated target
Section 5.2 complete
Next: 5.3 Guardrails name a harm
Requirements and Metrics / Module 5 / 5.3
5.3 Guardrails name a harm
Section 5.3 complete
Next: 5.4 Leading indicators and a changed group
Requirements and Metrics / Module 5 / 5.4
5.4 Leading indicators and a changed group
Section 5.4 complete
Next: Module 5 check
Continue to the module check Recap this section Back to module 5
Requirements and Metrics / Module 5 / Check
Module 5 check
Module 5 complete
Next: Module 6, coming later
Back to the Path Try it on your own question Recap module 5 Back to module 5
Requirements and Metrics / Module 1 / Recap
Recap card
1.1 What a precise metric needs
What a precise metric needs
- Name what is counted and the group before calculating.
- State the period, exclusions and one owner for the definition.
Common mistake
Only naming a rate. Different people can count different lines.
Requirements and Metrics / Module 1 / Recap
Recap card
1.2 Find the hidden users
Find the hidden users
- The requester is not every user.
- Access records show permission, not actual use.
- Ask service teams about their decisions and work rhythm.
Common mistake
Assuming access means use. Confirm real use with the team.
Requirements and Metrics / Module 1 / Recap
Recap card
1.3 Constraints: hard or negotiable
Constraints: hard or negotiable
- Separate approved rules, system facts and preferences.
- A proposed policy is not an approved rule.
- Record the source and owner of a limit.
Common mistake
Calling a proposal binding. Check its current status.
Requirements and Metrics / Module 1 / Recap
Recap card
1.4 Needs that conflict
Needs that conflict
- Different decisions can require different views.
- Record both needs and who owns the resolution.
- Never settle another stakeholder's conflict by averaging.
Common mistake
Inventing a compromise. Escalate to the authorised owner.
Requirements and Metrics / Module 1 / Recap
Recap card
Module 1: Who is this report really for?
What a precise metric needs
- Name what is counted and the group before calculating.
- State the period, exclusions and one owner for the definition.
Common mistake
Only naming a rate. Different people can count different lines.
Find the hidden users
- The requester is not every user.
- Access records show permission, not actual use.
- Ask service teams about their decisions and work rhythm.
Common mistake
Assuming access means use. Confirm real use with the team.
Constraints: hard or negotiable
- Separate approved rules, system facts and preferences.
- A proposed policy is not an approved rule.
- Record the source and owner of a limit.
Common mistake
Calling a proposal binding. Check its current status.
Needs that conflict
- Different decisions can require different views.
- Record both needs and who owns the resolution.
- Never settle another stakeholder's conflict by averaging.
Common mistake
Inventing a compromise. Escalate to the authorised owner.
Requirements and Metrics / Module 2 / Recap
Recap card
2.1 Need or proposed solution
Need or proposed solution
- A need names the job to be done.
- A solution names a particular action or feature.
- Ask what problem the proposed solution solves.
Common mistake
Taking a feature request as a need. Ask why it matters.
Requirements and Metrics / Module 2 / Recap
Recap card
2.2 Questions that do not lead
Questions that do not lead
- Neutral questions invite evidence.
- Ask about the last real case and what changed.
- Use interviews for motives and observation for behaviour.
Common mistake
Leading with a preferred answer. It can hide the real need.
Requirements and Metrics / Module 2 / Recap
Recap card
2.3 Watch what people do
Watch what people do
- Cases record received, reopened and closed work.
- Credits proposed and credits issued are different events.
- Mark what the record shows and what needs confirmation.
Common mistake
Calling a blank amount zero. Missing is not a recorded zero.
Requirements and Metrics / Module 2 / Recap
Recap card
2.4 Record it with its source
Record it with its source
- Record statement, stakeholder, source and date.
- Keep each disagreement rather than overwriting it.
- Use references, not personal notes about an employee.
Common mistake
Unsourced needs. Future readers cannot tell who observed them.
Requirements and Metrics / Module 2 / Recap
Recap card
Module 2: Needs, not wish lists
Need or proposed solution
- A need names the job to be done.
- A solution names a particular action or feature.
- Ask what problem the proposed solution solves.
Common mistake
Taking a feature request as a need. Ask why it matters.
Questions that do not lead
- Neutral questions invite evidence.
- Ask about the last real case and what changed.
- Use interviews for motives and observation for behaviour.
Common mistake
Leading with a preferred answer. It can hide the real need.
Watch what people do
- Cases record received, reopened and closed work.
- Credits proposed and credits issued are different events.
- Mark what the record shows and what needs confirmation.
Common mistake
Calling a blank amount zero. Missing is not a recorded zero.
Record it with its source
- Record statement, stakeholder, source and date.
- Keep each disagreement rather than overwriting it.
- Use references, not personal notes about an employee.
Common mistake
Unsourced needs. Future readers cannot tell who observed them.
Requirements and Metrics / Module 3 / Recap
Recap card
3.1 Vague words fail
Vague words fail
- Accurate and fast need a measurable test.
- Two testers may count different groups.
- Write the rule before accepting a figure.
Common mistake
Approving vague wording. It gives different answers to honest testers.
Requirements and Metrics / Module 3 / Recap
Recap card
3.2 Condition, behaviour, criterion, source
Condition, behaviour, criterion, source
- A condition sets the starting facts.
- A behaviour tells what the system does.
- A measurable criterion and source make the result testable.
Common mistake
No expected result. A second person cannot test it.
Requirements and Metrics / Module 3 / Recap
Recap card
3.3 Edge cases
Edge cases
- Unconfirmed, cancelled and unshipped are distinct.
- Each status needs an explicit treatment.
- Do not call a blank delivery date a late confirmation.
Common mistake
Hiding difficult rows. The criterion must say how to handle them.
Requirements and Metrics / Module 3 / Recap
Recap card
3.4 Priority follows the decision
Priority follows the decision
- Must protects a necessary decision.
- Should and could follow impact, not votes.
- Conflicts go back to the decision owner.
Common mistake
Ranking by popularity. A popular feature may not be essential.
Requirements and Metrics / Module 3 / Recap
Recap card
Module 3: Requirements you can test
Vague words fail
- Accurate and fast need a measurable test.
- Two testers may count different groups.
- Write the rule before accepting a figure.
Common mistake
Approving vague wording. It gives different answers to honest testers.
Condition, behaviour, criterion, source
- A condition sets the starting facts.
- A behaviour tells what the system does.
- A measurable criterion and source make the result testable.
Common mistake
No expected result. A second person cannot test it.
Edge cases
- Unconfirmed, cancelled and unshipped are distinct.
- Each status needs an explicit treatment.
- Do not call a blank delivery date a late confirmation.
Common mistake
Hiding difficult rows. The criterion must say how to handle them.
Priority follows the decision
- Must protects a necessary decision.
- Should and could follow impact, not votes.
- Conflicts go back to the decision owner.
Common mistake
Ranking by popularity. A popular feature may not be essential.
Requirements and Metrics / Module 4 / Recap
Recap card
4.1 Same enquiries, two rates
Same enquiries, two rates
- Same calculation words can hide different groups.
- Every rate names its group and counted outcome.
- Keep distinct definitions until the owner decides.
Common mistake
Common mistake. Calling one rate wrong without reading the group it answers.
Requirements and Metrics / Module 4 / Recap
Recap card
4.2 Counting unit, time rule and source fields
Counting unit, time rule and source fields
- One enquiry is the counting unit for enquiry conversion.
- Record the date rule and source field for each inclusion.
- Never infer a first quote version from a latest-only extract.
Common mistake
Common mistake. Counting quote lines as quote outcomes or mixing enquiry and order months.
Requirements and Metrics / Module 4 / Recap
Recap card
4.3 Tests that catch a wrong build
Tests that catch a wrong build
- Write a source record and expected outcome for each rule.
- Probe cross-month orders and unknown qualifications.
- Open quote statuses need their own treatment.
Common mistake
Common mistake. A headline percentage can hide several faulty implementations.
Requirements and Metrics / Module 4 / Recap
Recap card
4.4 Options, missing fields and ownership
Options, missing fields and ownership
- Keep rival definitions with tests and limits.
- Do not invent a field to meet an exclusion request.
- Escalate one documented decision and plan for changed stages.
Common mistake
Common mistake. Choosing a definition because its result seems more attractive.
Requirements and Metrics / Module 4 / Recap
Recap card
Module 4: A metric you can test
Same enquiries, two rates
- Same calculation words can hide different groups.
- Every rate names its group and counted outcome.
- Keep distinct definitions until the owner decides.
Common mistake
Common mistake. Calling one rate wrong without reading the group it answers.
Counting unit, time rule and source fields
- One enquiry is the counting unit for enquiry conversion.
- Record the date rule and source field for each inclusion.
- Never infer a first quote version from a latest-only extract.
Common mistake
Common mistake. Counting quote lines as quote outcomes or mixing enquiry and order months.
Tests that catch a wrong build
- Write a source record and expected outcome for each rule.
- Probe cross-month orders and unknown qualifications.
- Open quote statuses need their own treatment.
Common mistake
Common mistake. A headline percentage can hide several faulty implementations.
Options, missing fields and ownership
- Keep rival definitions with tests and limits.
- Do not invent a field to meet an exclusion request.
- Escalate one documented decision and plan for changed stages.
Common mistake
Common mistake. Choosing a definition because its result seems more attractive.
Requirements and Metrics / Module 5 / Recap
Recap card
5.1 Activity is not an outcome
Activity is not an outcome
- Outputs count what the team did: 842 emails, 58 enquiries.
- Outcomes count what customers did: 55.6% ordered again in June.
- Attribution is a timing rule, not proof of cause.
Common mistake
The mistake. Reporting emails sent or attributed enquiries as proof a campaign worked.
Requirements and Metrics / Module 5 / Recap
Recap card
5.2 Outcome, baseline and dated target
Outcome, baseline and dated target
- A baseline uses past data under the same definition: 29.8% webshop share, January to May.
- A target adds a value and a date to the baseline.
- A bigger count can hide a lower share.
Common mistake
The mistake. Comparing September with August only (up 53%) and ignoring the baseline.
Requirements and Metrics / Module 5 / Recap
Recap card
5.3 Guardrails name a harm
Guardrails name a harm
- A guardrail names its harm, a baseline and an alarm level.
- Returns arrive after delivery, so the newest months are incomplete.
Common mistake
The mistake. A guardrail like "send at least 700 emails a month" names no harm.
Requirements and Metrics / Module 5 / Recap
Recap card
5.4 Leading indicators and a changed group
Leading indicators and a changed group
- A leading indicator moves first: qualified enquiries, a median 11 days before the order.
- A new group needs its own baseline: INDUSTRIAL 73.4%, not 71.4%.
Common mistake
The mistake. Using the all-customer baseline for an INDUSTRIAL-only promotion.
Requirements and Metrics / Module 5 / Recap
Recap card
Module 5: Outcomes, not activity
Activity is not an outcome
- Outputs count what the team did: 842 emails, 58 enquiries.
- Outcomes count what customers did: 55.6% ordered again in June.
- Attribution is a timing rule, not proof of cause.
Common mistake
The mistake. Reporting emails sent or attributed enquiries as proof a campaign worked.
Outcome, baseline and dated target
- A baseline uses past data under the same definition: 29.8% webshop share, January to May.
- A target adds a value and a date to the baseline.
- A bigger count can hide a lower share.
Common mistake
The mistake. Comparing September with August only (up 53%) and ignoring the baseline.
Guardrails name a harm
- A guardrail names its harm, a baseline and an alarm level.
- Returns arrive after delivery, so the newest months are incomplete.
Common mistake
The mistake. A guardrail like "send at least 700 emails a month" names no harm.
Leading indicators and a changed group
- A leading indicator moves first: qualified enquiries, a median 11 days before the order.
- A new group needs its own baseline: INDUSTRIAL 73.4%, not 71.4%.
Common mistake
The mistake. Using the all-customer baseline for an INDUSTRIAL-only promotion.