A scenario puts the proposal back in a concrete situation
Aliases: situated scenario · replaying a proposal · abstract feature list
What it is
The requirement says “support remote signing.” No person, no place, nothing else in the hands. A scenario puts the proposal back in a situation: who, under which constraints, trying to finish which job, meeting this proposal how. That is not copy polish. It reattaches an abstract capability to time, bodies, and the people nearby. A proposal that will not attach often only holds as a line in a feature list.
Why it happens
In a document a proposal exists as capability: a button, an API, a state. Capability does not spend attention and does not compete with a child on the hip, a weak signal, or a ticket number being called at the next window. Situation writes those costs back in, and the proposal’s real shape appears—signing means producing ID, finding a witness, finishing inside a timed window. The writer is forced to pick a moment, and the pick exposes which kind of moment the proposal assumed (a quiet desk, full attention). Unchosen moments do not vanish; the proposal merely pretends they are background.
Studying it
Drop the same proposal into several already observed situations (place, device, companions, deadline) and watch which steps are one sentence in the doc and extra actions—or impossible—in the situation. Compare a capability-list review with a read-aloud situation review on what gets challenged: the former hits scope, the latter hits premises. Outcomes: count of hidden premises the situation kills, and whether the job still completes without a desk or without full attention.
Where it stops holding
Very early divergence may use half-sentence scenarios as probes; they need not be performable every time. Once trade-offs start, a half sentence is not enough. A scenario is not a sample: one richly written story does not replace observation; it only makes the proposal’s bets explicit so they can be checked. When technical constraints are still unknown, system behavior in the scenario should be tagged as hypothesis, not written as already possible. A multi-person proposal written with one protagonist is a truncated situation.
Applying it
- For every consequential proposal, write at least one already observed situation: constraints on the person, place, concurrent activity, completion criterion.
- During read-aloud, forbid adding convenient conditions that are not in the document (“and now they happen to be at a computer”); add them only by changing the proposal or writing another situation.
- If the proposal only lives at a quiet desk, either narrow the claimed setting or change the capability.
- After review, list premises the situation slapped, and decide for each: change the design, shrink the claim, or go observe.