May 24, 2026
Requirements describe what the system must achieve, not how. They sit at different levels of abstraction.
Levels of Requirements
1. Business Requirements
The highest-level intent. Expresses why something is needed. Usually stable over time.
“The system shall reduce manual batch configuration errors.”
2. User / Functional Requirements
Describes system behavior from a user or process point of view. Focuses on what the system does.
“The system shall validate all recipe parameters before execution.”
3. System / Technical Requirements
Constraints or implementation-level expectations. Performance, security, interfaces, limits.
“Validation shall complete within 2 seconds for 95% of cases.”
Key Properties of Good Requirements
- Unambiguous — only one interpretation
- Testable — can be verified objectively
- Atomic — one idea per requirement
- Traceable — can map to design and tests
Avoid solution wording. “Use SQL table X” is not a requirement — it is a design choice.
See also: Acceptance Criteria, Design Documents, The Traceability Chain