Requirements Engineering
Requirements engineering turns stakeholder needs, constraints, and risks into a testable description of what should be built. A goal says why the work matters; a requirement says what behavior, quality, interface, or constraint the system must satisfy. For data products, requirements must include data availability, workflow fit, acceptable error, latency, privacy, and auditability before software architecture is chosen.
Actors, conditions, and fit criteria
A useful requirement has an actor, condition, system response, fit criterion, owner, and non-goal. “Use AI to improve support” is a goal. “Auto-route German billing tickets only when precision is at least 0.94 on golden_de_billing_v3, with human override visible on every routed ticket” is testable. The examples can become behaviour-driven development scenarios or testing fixtures.
Reviewable requirements
Two requirements can be reviewed as requirements rather than aspirations:
| id | statement | fit criterion | owner | testable? |
|---|---|---|---|---|
| REQ-1 | Route German billing tickets automatically | precision >= 0.94 on golden_de_billing_v3 | support-ops | yes |
| REQ-2 | Human override is always available | override button visible for 100% of auto-routed tickets | product | yes |
The artifact is intentionally small: it distinguishes requirements from aspirations. Once a requirement carries a fit criterion, code review can ask whether the implementation and documentation updated the same contract.
Failure modes
Weak requirements overfit to a proposed solution, omit operational constraints, or hide disagreement behind words such as “accurate”, “real-time”, or “scalable.” If a term cannot be tested, measured, or reviewed, clarify it before writing a technical decision record.
References
Nav