Maj 24, 2026
A useful mental model for how engineering documentation fits together:
Business Need
↓
Requirements (what)
↓
Acceptance Criteria (how to verify what)
↓
Design (how to build it)
↓
Implementation
↓
Tests (based on acceptance criteria)
Key Principles
1. Traceability is Key
Every requirement should link to:
- a design element
- one or more acceptance criteria
- one or more tests
2. Avoid Mixing Levels
Common mistakes:
- Requirements that describe design (“use PostgreSQL”)
- Acceptance criteria that describe implementation details instead of behavior
3. Documents Should be “Executable”
Not in the code sense, but in clarity:
- A tester can derive test cases
- A developer can implement without guessing intent
- A reviewer can verify completeness
4. Minimal but Complete beats Verbose
Better: small set of precise requirements + strong acceptance criteria + clear design.
Worse: long documents with vague statements and hidden assumptions.
Se også: Requirements Engineering, Acceptance Criteria, Pharma Automation Framework