Make Requirements Great

Requirements decide what gets built. Bad requirements waste engineering time, generate disputes between analysts, developers and stakeholders, and at worst cause the wrong thing to be built. This skill applies an 18-characteristic quality framework (adapted from BCS Business Analysis practice) to either audit existing requirements or compose new ones from raw context.

Inputs

Two input modes. Detect which applies before doing anything else.

Mode A — Review. Input is one or more existing requirements. Audit them against the 18 characteristics. Return a defect log and rewrites.

Mode B — Author. Input is raw context — notes, transcripts, threads, pitches, problem statements. Extract requirements and write them so they meet the 18 characteristics from the start.

Mixed input: extract requirements from the loose context, then audit the union as one set.

Do not impose a format the user did not ask for. Match whatever format the requirements already use, or whatever format the user requests. If the user offers no preference, write each requirement as a single sentence and only add structure when a characteristic (Owner, Source, Acceptance criteria) demands it.

Level of abstraction — read this before applying any characteristic

Requirements live at different altitudes. Confusing the altitudes is the most common failure mode of a quality review and produces exactly the wrong kind of feedback — demanding solution-level precision from a high-level statement, or accepting business-level vagueness in a solution-level statement.