Checklist
Specify the interface where responsibility changes hands
Many ambiguous requirements live in the space between two owners.
When it fits
- Each component looks correct in isolation but failures occur at handoffs between teams, systems or process steps.
When to avoid it
- Interface detail should match risk; do not create heavyweight documents for trivial internal calls that are already governed by stable contracts.
Checklist
- Producer and consumer
- Data/object/event transferred
- Trigger and timing
- Format or contract
- Acknowledgement or success signal
- Failure/retry behavior
- Owner when the handoff fails
Why it matters
For each important interface, name the producer, consumer, object transferred, trigger, format or contract, timing, error signal, retry or fallback, and who owns a failed handoff. Treat the boundary as a requirement surface, not invisible plumbing.
An example
An outbound IDoc interface specifies who sends it, message type, trigger, acknowledgement, retry behavior and which team owns an unprocessed message.
Check your result
A handoff failure can be assigned and diagnosed without first debating where one component ends and the next begins.
Keep this limit in mind
- Interface detail should match risk; do not create heavyweight documents for trivial internal calls that are already governed by stable contracts.
Connected ideas
Useful withSpecify what happens when the happy path cannot complete
Evidence and sources
NASA's requirements checklist emphasizes clarity, one thought per requirement, completeness, explicit assumptions, consistency, traceability, feasibility and verifiability.
The checklist is for systems engineering; smaller tasks can apply the principles proportionally.
Appendix C: How to Write a Good Requirement · Requirements validation checklist