Welcome to our new site version. Your web page bookmarks may have changed, please search for pages by title to update them. Having problems ? Please try clearing your web browser cache and hard-reloading your web page first before contacting our webmaster.

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

[document] Submitted on 19 August, 2019 - 13:33
Keywords Building a Requirement Fault Taxonomy: Experiences from a NASA Verification and Validation Research Project
Standards groups

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.

Metadata
Date published
UNKNOWN
Document type
technical white paper
Pages
11
Replaced/Superseded by document(s)
Cancelled by
Amended by
File MIME type Size (KB) Language Download
Paper_Reqt_fault_taxonomy Hayes.pdf application/pdf   101.96 KB English DOWNLOAD!
File attachments
Abstract

Fault-based analysis is an early lifecycle approach to
improving software quality by preventing and/or
detecting pre-specified classes of faults prior to
implementation. It assists in the selection of verification
and validation techniques that can be applied in order to
reduce risk. This paper presents our methodology for
requirements-based fault analysis and its application to
National Aeronautics and Space Administration (NASA)
projects. The ideas presented are general enough to be
applied immediately to the development of any software
system. We built a NASA-specific requirement fault
taxonomy and processes for tailoring the taxonomy to a
class of software projects or to a specific project. We
examined requirement faults for six systems, including
the International Space Station (ISS), and enhanced the
taxonomy and processes. The developed processes,
preliminary tailored taxonomies for
Critical/Catastrophic High-Risk (CCHR) systems,
preliminary fault occurrence data for the ISS project,
and lessons learned are presented and discussed.

Organisation(s)
Defines standard
Visit also