faa-req-handbook

Follow the Handbook's eleven recommended practices: define the system boundary as monitored and controlled variables, capture operational concepts as use cases, state environmental assumptions, build a functional architecture, define modes, then write detailed requirements as condition-to-assignment rules with ideal value, tolerance, and latency.

The four-variable model (Parnas/Madey, via SCR) frames requirements with MON (monitored), CON (controlled), NAT (environmental assumptions), and REQ (required relationship). Software requirements extend it with INPUT/OUTPUT variables and the IN'/REQ'/OUT' split, reusing the system's ideal value function unchanged.

Define the boundary as the set of monitored variables the system senses and controlled variables it affects directly. Apply the elimination test: a true boundary variable would still exist if the system vanished. Keep variables abstract and never specify wire formats like an ARINC 429 word.

No. The Handbook is slanted toward real-time, embedded sensor/actuator control systems in avionics and medical domains. It is thin on information-system, enterprise, business, and agile requirements styles, and does not cover requirements-management tooling like DOORS.

No. The pack names IEEE Std 1233, IEEE 830-1998, RTCA DO-178B/DO-248B/DO-278, and SAE ARP 4754/4761 but reproduces none of them, since they remain copyrighted by their publishers. It describes in original words how the Handbook's practices relate to those standards.

Specify latency (maximum lag) for every controlled variable and tolerance (allowed deviation) for every numerical controlled variable, each tethered by rationale to environmental assumptions. Never assign latency or tolerance to internal variables, since no promise is made about them.