Building a Requirement Fault Taxonomy: Experiences from a NASA Verification and Validation Research Project

We found many papers that confirmed our requirements fault types and found only a few papers that described “new” requirement faults (see [4]). Note that
the above list, with the addition of not traceable, non verifiable, unachievable, misplaced, and intentional deviation fault types, should serve as a good starting
taxonomy for the fault-based analysis of any software system. Examination of NASA requirement faults resulted in a number of changes to the taxonomy, as
discussed below. The resulting new set of 13 fault categories was considered to be relevant as a “generic” NASA fault taxonomy as shown in Table 1.

We added a category for each “new” fault type such as not traceable, non-verifiable, unachievable, misplaced, and intentional deviation, bringing the taxonomy to 18 fault types. We consider omitted or missing requirement as one major category. The sub-fault categories identified under this category are: 1) Omitted requirement, 2) Missing external constants, and 3) Missing description of initial system state. We identified incorrect as one major category. The sub-fault categories are: 1) Incorrect external constants, 2) Incorrect input or output descriptions, 3) Incorrect description of initial system state, and 4) Incorrect
assignment of resources.

We added one major requirement fault, ambiguous, and under it we grouped: 1) Improper translation, and added a new sub-fault category 2) Lack of clarity. We
grouped conflicting requirements into one major fault category, inconsistent, and the sub-faults under this category are: 1) External conflicts, and 2) Internal
conflicts. We added a new major requirement fault, redundant, to cover the situation where a requirement appears duplicated elsewhere in the specification.