WHITE PAPER

REQUIREMENTS SANITY/INSANITY Practical Rules for Requirements Capture in DO-178C, DO-254 and ARP 4754A

Requirements guide most of the activities within a constrained development environment (DO-178, DO-254, ARP 4754), which also means they drive most of the schedule and program risk. This paper introduces a framework of rules for capturing functional requirements which should minimize program risk and maintain schedules.

Currently, a typical functional requirement set contains enough information and detail to correctly execute a design. The insanity comes in when engineers attempt to formally test or verify that design, to the same set of requirements. Some scenarios could be:

• Tests that cover the design, but won’t trace to the requirements.
• Tests that fail because the design is not what you thought it was.
• Tests that are beyond the scope of the requirements.

This paper establishes a set of seven rules which will allow you to restore some sanity to your projects. These rules, in addition to establishing consistency, promote:

• The understanding of the differences between constraints and requirements.
• The conceptual shift in the point of view of the requirements. Write requirements from the verification / test point of view.

It is never too late to establish complete and correct requirements; the sooner this is done in a program, the lower the risk level.