Gather requirements from a real task
Begin a requirements session with a decision or task someone needs to complete. Ask for a recent example, follow its records and write down exceptions. Turn each proposed requirement into a statement with a source, an owner and a way to check acceptance.
This workshop and record-request template is for delivery discovery. It is not a recruitment interview script. Choose questions that address a gap in the evidence; there is no requirement to ask every question.
Before the session
Write the question the session should resolve and what is outside scope. Invite someone who does the work and someone who receives its output. Arrange permission to inspect a small, relevant set of records. Use redacted copies when personal or commercially sensitive details are unnecessary.
| Question | Evidence to request | What to record |
|---|---|---|
| Show the last time you did this | A dated example and its originating request | Trigger, actors and actual sequence |
| What decision did you need to make? | The information available at that moment | Decision and missing information |
| What happens when the usual path fails? | A returned, delayed or rejected example | Exception, owner and recovery |
| Who needs the output next? | Receiver's acceptance or rejection | Handoff condition and unresolved work |
| What would demonstrate an acceptable change? | Example inputs and expected outcomes | Testable behaviour and acceptance owner |
| Which parts of this account remain uncertain? | Another account or missing record | Conflict, next check and responsible person |
Worked session: discount requests
The following example is synthetic. A sales lead says requests above 15% need approval; finance says the threshold is 10%. The facilitator records two attributed accounts. Asking the group to settle on 12.5% would create a new policy proposal, not establish the current one.
| Observation or account | Requirement candidate | Unresolved evidence |
|---|---|---|
| Two people describe different thresholds | Apply the authorised discount threshold | Locate the policy and confirm who may change it |
| A requester cannot see whether approval is pending | Show the request's recorded decision state | Inspect a real status history and agree state meanings |
| An absent approver delays a decision in the example | Provide an authorised absence route | Confirm delegation rules; do not assume a substitute |
Finish the session with a short read-back. Ask whether the record accurately represents each account, then assign the remaining checks. Agreement that notes are accurate is different from approval to implement their proposals.
After the session
Give each candidate a stable ID. Keep the source date and link, avoid copying private records into a broadly shared document, and record who may inspect the original. If the required source is unavailable, retain the gap and its effect on the decision.
Move supported candidates into the requirements traceability matrix. Keep unsupported proposals visible until the appropriate owner decides what to do with them. A short session with a clear unresolved decision is more usable than a completed checklist that conceals disagreement.
What evidence is missing before these requirements can be agreed?
Run a task-based workshop and record request that distinguishes accounts from agreed requirements.
Your starting question: What evidence is missing before these requirements can be agreed?
Start by checking
- Inspect a recent task and an exception.
- Attribute conflicting accounts.
- Assign the next evidence checks.
Evidence to gather
- Dated task records and workshop accounts.
- Examples of accepted and returned outputs.
Not established yet
- Which account is correct.
- Whether a proposed requirement is authorised.