Loading...
Please wait, while we are loading the content...
Similar Documents
Validation of Guidance Control Software Requirements Specification for Reliability and Fault-Tolerance
| Content Provider | Semantic Scholar |
|---|---|
| Author | Pullman Kim, Hye Yeon |
| Copyright Year | 2002 |
| Abstract | SUMMARY & CONCLUSIONS A case study was performed to validate the integrity of a software requirements specification (SRS) for Guidance Control Software (GCS) in terms of reliability and fault-tolerance. A partial verification of the GCS specification resulted. Two modeling formalisms were used to evaluate the SRS and to determine strategies for avoiding design defects and system failures. Z was applied first to detect and remove ambiguity from a part of the Natural Language based (NL-based) GCS SRS. Next, Statecharts and Activity-charts were constructed to visualize the Z description and make it executable. Using this formalism, the system behavior was assessed under normal and abnormal conditions. Faults were seeded into the model (i.e., an executable specification) to probe how the system would perform. The result of our analysis revealed that it is beneficial to construct a complete and consistent specification using this method (Z-to-Statecharts). We discuss the significance of this approach, compare our work with similar studies, and propose approaches for improving fault tolerance. Our findings indicate that one can better understand the implications of the system requirements using Z-Statecharts approach to facilitate their specification and analysis. Consequently, this approach can help to avoid the problems that result when incorrectly specified artifacts (i.e., in this case requirements) force corrective rework. 1. INTRODUCTION Highly reliable systems demand rigorously engineered software. A failure in the control software of mission critical systems can be disastrous. It is difficult to create a reliable specification because such control software tends to be highly complex. To avoid problems in the latter development phases and reduce life-cycle costs, it is crucial to ensure that the specification be reliable. Reliability, as applied to the software requirements specifications, means: (1) is the specification correct, unambiguous, complete, and consistent; (2) can the specification be trusted to the extent that design and implementation can commence while minimizing the risk of costly errors; and (3) how can the specification be defined to prevent the propagation of errors into downstream activities? The completeness of a specification is defined as a lack of ambiguity in implementation. The specification is incomplete if the system behavior is not specified precisely because the required behavior for some events or conditions is omitted or is subject to more than one interpretation (Ref. 1). Consistency means that the specification is free from conflicting requirements and undesired nondeterminism (Ref. 2). The typical SRS is highly dependent on natural language. Natural language … |
| File Format | PDF HTM / HTML |
| Alternate Webpage(s) | http://www.csm.ornl.gov/~sheldon/public/2002RM-055-1.pdf |
| Language | English |
| Access Restriction | Open |
| Subject Keyword | Artifact (software development) Chart Conflict (Psychology) Content-control software Downstream (software development) Executable Fault tolerance Formal system List of version control software Mission critical Morphologic artifacts NL (complexity) Natural language Partial Requirement Requirements analysis Rework (electronics) Software propagation Software requirements specification System requirements UML state machine Verification of Theories |
| Content Type | Text |
| Resource Type | Article |
