Requirement analysis: what they actually do

Ask what happens if we do not build it, then who uses it and how often. If those have no answer, it does not get scheduled.

Task: A stakeholder requests a feature.

[Before you start, do three things]
1. Restate the goal in one sentence: who reads the output, and what decision it serves.
2. If I have not given you the following, ask me. Do not assume:
   - their current workflow
   - frequency and context
   - cost of not doing it
   - is the requester the user
3. Say how you plan to do it (at most 5 steps) and wait for my go-ahead.

[Go through each of these]
- reconstruct how they do it now, including workarounds
- decide whether this is a problem or a solution
- three options: build, skip, another way
- what metric sits behind the request

[Process]
1. Reconstruct what the user actually does
2. Decide whether this is a need or a proposed solution
3. Offer build, do not build, or another way
4. Write checkable acceptance criteria
5. Mark the risk and reversibility

[Output]
Problem, judgement, options, acceptance, risk.

[Do not]
- Never copy the requester's solution
- No scheduling without a usage scene
- No acceptance criteria like 'improve experience'
- Never three features at once