Requirements & Traceability

Good requirements are specific, measurable, and testable. Everything else is wishful thinking.

Requirements Are Contracts

Why requirements matter: Vague requirements guarantee conflict later. "Fast," "reliable," and "user-friendly" mean different things to different people. A good requirement is specific enough to test, clear enough to implement, and harsh enough to reject bad designs. If you can't verify it, it's not a requirement—it's a wish.

Requirements drive everything: design decisions, test plans, budget allocations, schedule estimates. Bad requirements early become expensive failures late. The art of requirements engineering is translating fuzzy stakeholder needs into precise, testable specifications.

How to Write Requirements

The SHALL Statement Format

Professional requirements use SHALL (mandatory), SHOULD (desired), or MAY (optional). SHALL means non-negotiable—the system fails verification without it.

❌ Bad - Vague

"The system should be fast."

✓ Good - Quantifiable

"The system SHALL process telemetry commands within 100ms from receipt to execution, measured at 95th percentile under nominal load."

❌ Bad - Untestable

"The interface must be user-friendly."

✓ Good - Testable

"The ground station interface SHALL enable operators to complete routine health checks in under 5 minutes after 2 hours of training, verified through user testing with 5 subjects."

❌ Bad - Design Constraint Masquerading as Requirement

"The system shall use a microservice architecture."

✓ Good - Actual Need

"The system SHALL support independent deployment of subsystems without downtime, with rollback capability within 60 seconds."

Characteristics of Good Requirements

Atomic

One requirement per statement. Avoid "and" that hides multiple requirements.

Bad: "Radio shall transmit and receive on multiple frequencies."

Good: Separate REQ-001 (transmit) and REQ-002 (receive).

Verifiable

You must be able to test whether it's met. No subjective judgments.

Test: Can you write a pass/fail test procedure? If no, rewrite the requirement.

Unambiguous

One and only one interpretation. Avoid fuzzy words like "reasonable," "adequate," "normal."

Replace with: Specific quantities, time limits, error rates, percentages.

Complete

Includes normal operation, error cases, boundary conditions, and environmental constraints.

Ask: What happens at edges? What if inputs are invalid? What's the failure mode?

Requirements Decomposition

Why decompose: System-level requirements are too high-level to implement directly. You need to decompose them into subsystem, component, and eventually software/hardware requirements. Each level adds detail while maintaining traceability back to the original need.

Decomposition Example

Level ID Requirement
System SYS-001 The spacecraft SHALL maintain attitude knowledge to within ±1° (3σ) during normal operations.
Subsystem ADCS-010 The ADCS SHALL determine attitude using sensor fusion with update rate ≥10 Hz.
Subsystem ADCS-011 The ADCS SHALL use IMU, magnetometer, and sun sensors as attitude determination sources.
Component IMU-100 The IMU SHALL provide 3-axis gyro data with bias stability <10°/hr and noise density <0.01°/√hr.
Component SW-200 The Kalman filter algorithm SHALL fuse sensor data with latency <5ms and output attitude quaternion.
Key principle: Each decomposed requirement must trace back to parent requirements. If you can't explain why a low-level requirement exists, it's either gold-plating or you've lost traceability. Every requirement costs money to implement and verify—justify it.

Requirements Traceability

Traceability is accountability: Can you prove every requirement is implemented? Can you prove every test verifies a requirement? Can you prove no features exist without requirements (scope creep)? Traceability matrices answer these questions. They're tedious but essential for complex projects.

Traceability Matrix Example

Requirement ID Requirement Design Element Test ID Status
SYS-001 Attitude ±1° accuracy ADCS Module, Kalman Filter TEST-045 ✓ Verified
SYS-002 Command latency <100ms C&DH Software v2.3 TEST-012 ✓ Verified
SYS-003 Battery life >5 years Power Subsystem TEST-089 ⚠ In Progress
SYS-004 Radiation tolerance 50 krad Component selection TEST-120 ✗ Failed

What Traceability Catches

When Requirements Change (They Will)

Requirements always change mid-project. Traceability lets you assess impact: "This requirement changed—here are the 7 design elements and 12 tests that must be updated." Without traceability, you're guessing. With traceability, you know exactly what's affected.

Types of Requirements

Functional Requirements

What the system does.

  • Process commands
  • Generate telemetry
  • Control actuators
  • Store data
  • Execute algorithms

Performance Requirements

How well it does it.

  • Response time
  • Throughput (data rate)
  • Accuracy and precision
  • Capacity (storage, users)
  • Efficiency (power, CPU)

Interface Requirements

How it connects.

  • Communication protocols
  • Data formats and structures
  • Physical connectors
  • Voltage levels and timing
  • API specifications

Environmental Requirements

Conditions it must survive.

  • Temperature range
  • Radiation tolerance
  • Vibration and shock
  • Pressure and humidity
  • EMI/EMC compliance

Safety Requirements

What must NOT happen.

  • No single-point failures
  • Fail-safe modes
  • Hazard mitigation
  • Watchdog protection
  • Emergency shutdown

Quality Attributes

Long-term properties.

  • Reliability (MTBF)
  • Maintainability
  • Testability
  • Scalability
  • Security

Common Requirements Mistakes

Confusing Requirements with Design

Wrong: "System shall use PostgreSQL database."

Right: "System shall persist data with ACID guarantees and support concurrent access for 100 users."

State what, not how. Let design choose implementation.

Missing Error Cases

Wrong: "System shall process valid commands."

Right: Also specify: invalid commands, timeout behavior, buffer overflow handling, retry logic, graceful degradation.

Happy path is 10% of the requirement. Error cases are 90%.

Untestable Requirements

Wrong: "System shall be highly available."

Right: "System shall achieve 99.9% uptime measured over 30-day windows."

If you can't measure it, you can't test it. If you can't test it, it's not a requirement.

Scope Creep via Adjectives

Wrong: "System shall be easy to use."

Right: "90% of trained users shall complete task X in under Y minutes."

Words like "easy," "intuitive," "robust" hide requirements. Quantify them or delete them.

The 5-minute test: Hand your requirement to someone unfamiliar with the project. Can they tell you exactly what to build and how to test it? If not, the requirement is ambiguous. Rewrite it.

Requirements Best Practices