Requirements
Write requirements about outcomes and observable behavior. Keep explicit user choices; do not replace their product with a preferred solution.
Work
- Extract the user goal, initiating event, allowed actor, inputs, result, and failure behavior from the brief or running product.
- Give requirements stable IDs only when traceability helps. Prefer “An editor can rename a project; a viewer cannot” to legalistic filler.
- For each write, identify server authorization, validation, persistence, duplicate submission behavior, and what happens if the result is unknown after a timeout.
- Specify applicable quality constraints with conditions: target devices, input methods, content size, latency measurement, supported languages, privacy, and availability. Mark proposed targets as proposals.
- Name dependencies, unresolved contract questions, and excluded scope. Do not invent APIs or imply they exist.
- When revisiting implementation, report which requirements are met, changed, missing, or unverified, with evidence.
Deliver
Use requirement → acceptance example → dependency/unknown. Add only enough examples to distinguish correct behavior from a plausible implementation.
Write each requirement as:
FR-01: [actor + behavior] — Accept: [observable example] — Depends/unknown: [...]
NFR-01: [constraint + condition] — Verify: [scoped check]
Close with out-of-scope, assumptions, open questions, and next step.
Example: Given a viewer sends a rename request directly, the server rejects it and the stored name remains unchanged. Hiding the edit button alone does not satisfy this requirement.
Include a failure or boundary case for consequential behavior. “Accessible,” “fast,” and “secure” need scoped verification criteria. Use $flow when branch order is the open question; $component when a reusable interaction needs a contract.
Worked example
FR-01: The system shows the last 30 days of activity when a user opens the dashboard — Accept: recent work is reviewable without navigation — Depends: activity API exists, rate limits undocumented.
FR-02: The system preserves the date-range filter in the URL — Accept: the view can be shared and bookmarked — Depends: none.
NFR-01: Dashboard load reaches LCP under 2.5s on 4G mobile — Verify: measure on a mid-tier device; mark the target as a proposal.
NFR-02: All dashboard controls are keyboard-reachable with WCAG 2.2 AA contrast — Verify: keyboard pass plus contrast check.
Out of scope: custom report builder, CSV scheduling, mobile push notifications.
Assumptions: activity data is server-side and queryable by date range.
Open questions: past 30 days — paginate or show a summary?
Next: $sitemap for the app shell and dashboard routes.
Gotchas
- Do not treat a hidden button as access control; require server rejection with unchanged data.
- Do not invent endpoints or imply they exist; list undocumented contracts as unknowns.
- Do not write "fast," "secure," or "accessible" without scoped verification criteria.
- Do not specify UI solutions; define observable behavior and defer interaction to flow or component.
- Do not present proposed latency or quality targets as committed guarantees.
Boundaries
- Do not use when the idea is still vague — run
$intent first.
- Do not use when requirements exist and the open question is navigation — use
$sitemap instead.
- Do not specify UI solutions; define comparable behavior and let
$component or $flow resolve the interaction.
1---2name: requirements3description: Turn a brief or existing feature into testable behavior, quality constraints, and explicit data and permission contracts. Use when stakeholder notes, a brief, or a vibe-coded concept needs FR/NFR requirements before design or implementation.4---56# Requirements78Write requirements about outcomes and observable behavior. Keep explicit user choices; do not replace their product with a preferred solution.910## Work1112- Extract the user goal, initiating event, allowed actor, inputs, result, and failure behavior from the brief or running product.13- Give requirements stable IDs only when traceability helps. Prefer “An editor can rename a project; a viewer cannot” to legalistic filler.14- For each write, identify server authorization, validation, persistence, duplicate submission behavior, and what happens if the result is unknown after a timeout.15- Specify applicable quality constraints with conditions: target devices, input methods, content size, latency measurement, supported languages, privacy, and availability. Mark proposed targets as proposals.16- Name dependencies, unresolved contract questions, and excluded scope. Do not invent APIs or imply they exist.17- When revisiting implementation, report which requirements are met, changed, missing, or unverified, with evidence.1819## Deliver2021Use **requirement → acceptance example → dependency/unknown**. Add only enough examples to distinguish correct behavior from a plausible implementation.2223Write each requirement as:2425FR-01: [actor + behavior] — Accept: [observable example] — Depends/unknown: [...]26NFR-01: [constraint + condition] — Verify: [scoped check]27Close with out-of-scope, assumptions, open questions, and next step.2829Example: Given a viewer sends a rename request directly, the server rejects it and the stored name remains unchanged. Hiding the edit button alone does not satisfy this requirement.3031Include a failure or boundary case for consequential behavior. “Accessible,” “fast,” and “secure” need scoped verification criteria. Use `$flow` when branch order is the open question; `$component` when a reusable interaction needs a contract.3233## Worked example3435FR-01: The system shows the last 30 days of activity when a user opens the dashboard — Accept: recent work is reviewable without navigation — Depends: activity API exists, rate limits undocumented.36FR-02: The system preserves the date-range filter in the URL — Accept: the view can be shared and bookmarked — Depends: none.37NFR-01: Dashboard load reaches LCP under 2.5s on 4G mobile — Verify: measure on a mid-tier device; mark the target as a proposal.38NFR-02: All dashboard controls are keyboard-reachable with WCAG 2.2 AA contrast — Verify: keyboard pass plus contrast check.39Out of scope: custom report builder, CSV scheduling, mobile push notifications.40Assumptions: activity data is server-side and queryable by date range.41Open questions: past 30 days — paginate or show a summary?42Next: `$sitemap` for the app shell and dashboard routes.4344## Gotchas4546- Do not treat a hidden button as access control; require server rejection with unchanged data.47- Do not invent endpoints or imply they exist; list undocumented contracts as unknowns.48- Do not write "fast," "secure," or "accessible" without scoped verification criteria.49- Do not specify UI solutions; define observable behavior and defer interaction to flow or component.50- Do not present proposed latency or quality targets as committed guarantees.5152## Boundaries5354- Do not use when the idea is still vague — run `$intent` first.55- Do not use when requirements exist and the open question is navigation — use `$sitemap` instead.56- Do not specify UI solutions; define comparable behavior and let `$component` or `$flow` resolve the interaction.
mattjmdesign