Requirements diagrams aren’t just boxes and arrows. They’re the legal contracts of systems engineering, the paper trail that prevents your $20M defense project from failing audit or your medical device from killing patients. Here’s how the pros actually use them.
Why This Matters More Than You Think
The horror story we all know:
A team builds an “FDA-compliant” infusion pump. It passes all unit tests but fails certification because:
- No one traced the “shall prevent air bubbles” requirement to the bubble detection algorithm
- The verification test only checked software responses, not physical bubble clearance
Result: 18-month delay, $8M in redesign costs.
How requirements diagrams prevent this:
They force you to connect:
- Regulatory demands → Design decisions → Physical components → Test procedures
The Nuts and Bolts That Actually Matter
1. Requirements That Don’t Suck
Bad requirement: “System shall be secure” (meaningless)
Good requirement:
text
[R-023]
Priority: Safety-Critical
Source: FDA 21 CFR Part 1203.45(b)
Text: “Pump shall detect >0.5mL air embolisms with 99.9% reliability”
Verification: Physical test with calibrated air injection apparatus
Pro tip: Color-code requirements by:
- Red = Safety/Legal
- Blue = Performance
- Green = User Experience
2. Traceability That Withstands an Audit
Real-world connections you must show:
| Requirement | Satisfied By | Verified By |
| R-023 | AirSensor block | Test TC-117 (bubble injection) |
| R-101 | UserAuth module | PenTest PT-202 |
Nuclear plant example:
Every seismic safety requirement traces to:
- Concrete thickness in structural models
- Sensor placement in I&C diagrams
- Earthquake simulation procedures
3. Derivation Chains That Expose Gaps
How requirements should flow:
text
[Customer Need]
↓ «deriveReqt»
[System Requirement]
↓ «deriveReqt»
[Subsystem Requirement]
↓ «satisfy»
[Component Block]
Automotive case study:
Customer want: “Car shouldn’t kill pedestrians”
→ Derives to: “Emergency braking at <30m detection”
→ Which splits to:
- Radar detection range specs
- Brake actuator response time
- Driver alert timing
Diagrams That Don’t Lie
The Money Shot
A proper requirements diagram for a drone system shows:
- Legal boxes (FAA Part 107 altitude limits)
- Physical implementations (barometer module satisfying altitude req)
- Tests that prove compliance (altitude hold validation procedure)
Watch for:
- Orphan requirements (no «satisfy» link) = Design holes
- Dangling verifications (no «verify» link) = Untested features
Tool Reality Check
- DOORS Next Gen: Overkill for startups, essential for aerospace
- Jama Connect: Good balance for medical devices
- Spreadsheets: Will get you fired when auditors come
Pro Moves They Don’t Teach in School
- Requirement DNA Testing
For each requirement, ask:- Who demanded this? (Regulator? Marketing?)
- What’s the worst failure mode?
- How would we prove we met it?
- Change Impact Poker
When a requirement changes:- Deal cards to team members representing subsystems
- Each estimates impact severity (1-5)
- Anyone plays a 5? Full impact analysis required
- The “Idiot Test”
Can a new hire look at your diagram and:- Find all safety requirements in <2 minutes?
- See which code modules handle each?
- Locate the corresponding tests?
When Requirements Diagrams Save Lives
Therac-25 Radiation Therapy Case:
- Missing requirement: “Shall not administer overdose when operator corrects input”
- No «deriveReqt» to error handling routines
- Result: Fatal radiation overdoses
Modern requirements diagrams prevent this by:
- Making safety constraints visually unmistakable
- Forcing explicit error path specifications
- Linking every safety req to failure mode analyses
The Secret No One Admits
Most teams:
- Cram requirements into documents no one reads
- Lose traceability after first design iteration
- Discover missing verifications during final audit
Winning teams:
- Treat requirements as living model elements
- Update links during every design review
- Automate traceability checks in their CI pipeline
Your Action Plan
- Start Small
Pick one subsystem (e.g., battery management):- List 10 critical requirements
- Map them to components and tests
- Stress Test It
Delete a random requirement—does anyone notice?
If not, your links are decorative - Scale Ruthlessly
Once it works for one module:- Enforce “no new code without requirement links”
- Make test engineers sign off on verification coverage
The Bottom Line
Requirements diagrams aren’t documentation—they’re your project’s central nervous system. When done right, they:
- Turn regulatory jargon into actionable specs
- Expose design gaps before fabrication
- Survive employee turnover and management changes
Final litmus test: If your diagram can’t help you win in court after a failure, it’s not robust enough.
Remember: In engineering, if it wasn’t traced, it wasn’t required. And if it wasn’t required… why did you build it?