requirements-to-spec

Requirements to spec

Converting prose into something you can verify against.

Why this exists

An FDE almost never receives requirements from the person who has the problem. They arrive relayed — through a delivery lead, a ticket someone wrote after a meeting, or a conversation with an engineer repeating what they were told. Each hop drops context and silently resolves ambiguity, usually toward whatever the relayer assumed.

The result is a request that sounds specific and isn't. "Add a currency field to refunds" is a sentence everyone nods at, and it conceals at least five decisions nobody has made.

This skill's job is to surface those decisions before they're made accidentally in code, and to write the requirement down in a form where "is it done?" has an answer. Everything downstream depends on it: feasibility-probe grounds this spec in code, verification-plan maps these criteria to evidence, and release-readiness reports against them.

When this applies

• A vague or one-line ask
• Requirements relayed through intermediaries
• Before estimating or designing anything
• Meeting notes that need to become work
• Nobody can state what "done" means

When it doesn't

• A well-specified ticket with acceptance criteria already written — check it's testable, then proceed
• A production incident. Fix it; specify later.
• Pure investigation with no behavior change — that's an assessment engagement

Prerequisites

.fde/00-engagement.md — the sponsor and the real problem from the charter are the frame for everything here.

Procedure

1. Capture the ask verbatim

Record the original wording before you interpret it. Paraphrasing is the first place ambiguity gets silently resolved, and once the paraphrase is written down the original is gone.

Also record who said it, when, and to whom. Provenance matters: a requirement from the sponsor and a requirement from a developer's recollection of a corridor conversation are different objects, and should not look identical in the document.