Designing for Failure: Anomaly Identification and Treatment in System Requirements Analysis

Abstract

Abstract.A method for identifying anomalous (or "what if") conditions in the system requirements analysis (SRA) is proposed using the concept of functional failure (Spangler 1993, Armstrong 1995. The method complements and extends (Carson 1995) by defining "sufficient" conditions for SRA completeness which complement the previously defined "necessary" conditions for completeness. Identification of the functional failures during the SRA allows the system designer to treat different anomalies rigorously at the beginning of a program as part of the system design. System requirements for "fault tolerance" or "inhibiting fault cascading" are easily incorporated into the resulting SRA as required behaviors (functions) for specific antecedents. The developed process ensures in a verifiable manner that the SRA is complete and there are no incorrect or indeterminate behaviors due to inadequate system design. If applied at all levels of the system development (mission design, system design, subsystem design, end item design) one could expect no surprises during test and integration at any level of design.

1.6.4 Requirements Completeness: A Deterministic Approach

“…Other authors have made similar observations (Grady 1993). (Carson 1996) proposed a method for ensuring requirements completeness based on defining the required system behavior under all possible conditions of the system or subsystem interfaces. The key element in the process is identifying and quantifying the interface conditions (step one above), and then grouping them into one or more behaviors for which a particular response is defined in the requirements specification.…”

8.6.1 Integrating Failure Modes and Effects with the System Requirements Analysis

“…If we can anticipate and plan for the unintended behavior associated with failure, we can define the intended response to such failure. This helps ensure that there are no undefined or unexpected behaviors associated with the system (Carson 1995).…”

“…Asking the "what if?" question begins the process of identifying potential system anomalies, whether in terms of unexpected boundary conditions, operator "errors" or creativity, or system element failures (Carson 1995).…”

“…Anticipating the fact of functional failure allows the system requirements to address the consequences and prescribe an anomaly handling function in parallel with any other function. This can be considered the equivalent of the "else" alternative in a case statement, which subsumes all possibilities not explicitly identified (Carson 1995, Carson 1996.…”

“…Here we have used the "exclusive or" construct to distinguish the branching conditions, with each XOR identifying conditions for choosing between the alternate paths; the condition of functional failure is included explicitly or implicitly at each branch. As (Carson 1995) noted, when at least one branch of the XOR is the "else" condition, the requirements are "complete" for all functions (see also Carson 1998a andCarson et al, 2004). In addition, the explicit branching conditions can be identified on the functional flow as an annotation.…”