3.4 Writing And Validating Good Requirements
A specification is not valuable because it is long. It is valuable when it makes the next engineering decision safer.
Good requirements are clear enough to review, implement, test, and challenge. They do not need literary beauty. They need operational precision.
What good requirements look like
Good requirements tend to be:
- Necessary: connected to a real stakeholder goal.
- Unambiguous: readers do not invent different meanings.
- Testable: there is a way to verify the behavior.
- Feasible: possible within technical, legal, and organizational constraints.
- Bounded: includes scope, conditions, and exceptions.
- Traceable: connected to source, design, implementation, and test.
Weak requirement: "The system should be secure."
Better requirement: "After 5 failed password attempts within 10 minutes, the account enters a 15-minute lockout state and emits a security event with user id, IP hash, and timestamp."
Validation vs. verification
Validation asks: are we specifying the right thing?
Verification asks: did we build the specified thing correctly?
Both matter. A perfectly implemented wrong requirement is still waste.
Practical validation methods
Use more than one:
- Requirement review with engineers, product, design, support, security, or compliance.
- Prototypes for risky workflow assumptions.
- Examples and acceptance scenarios.
- Feasibility spikes for uncertain technology.
- Traceability review for regulated or high-risk systems.
- User walkthroughs before implementation is expensive.
The goal is not to freeze everything. The goal is to make uncertainty visible before the cost of change becomes painful.