When choosing how to represent a requirement, what are the four "degrees of freedom" you can dial?
You can choose the instrument (natural language → structured/interaction models → formal model), the structure, the precision, and the depth (deepness) of the representation.
A requirement isn't written one fixed way — you have four independent dials, and you tune each to the situation (how risky, how complex, how formal the project is):
- Choice of the instrument — how you express it, on a spectrum from informal to formal:
- Natural language (plain prose) — quick and accessible, but ambiguous.
- Structured models (e.g. templates, structured text).
- Interaction models (e.g. use-case / sequence diagrams).
- Formal model (mathematical notation) — unambiguous and verifiable, but expensive and needs expertise.
- Structure — how you organise and group the requirements.
- Precision — how exact/quantified the statement is ("fast" vs. "≤ 200 ms at the 95th percentile").
- Deepness (depth) — how much detail you drill into; high-level overview vs. fine-grained breakdown.
A requirement's content (the presentation) covers functionality (function, data, behaviour) and attributes (performance, quality, surrounding conditions); these four degrees of freedom are about how that content is captured.
Tip: More formality/precision/depth costs more effort, so you scale it to the risk — a throwaway prototype gets natural language; a safety-critical or contractual requirement earns a precise, structured, possibly formal representation.