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.