Conference Paper

A Case Study: Validation of Guidance Control Software Requirements for Completeness, Consistency and Fault Tolerance.

Conference: 8th Pacific Rim International Symposium on Dependable Computing (PRDC 2001), 17-19 December 2001, Seoul, Korea
Source: DBLP


In this paper, we discuss a case study performed forvalidating a Natural Language (NL) based softwarerequirements specification (SRS) in terms ofcompleteness, consistency, and fault-tolerance.A partialverification of the Guidance and Control Software (GCS)Specification is provided as a result of analysis usingthree modeling formalisms.Zed was applied first todetect and remove ambiguity from the GCS partial SRS.Next, Statecharts and Activity-charts were constructed tovisualize the Zed description and make it executable.Theexecutable model was used for the specification testingand faults injection to probe how the system wouldperform under normal and abnormal conditions.Finally,a Stochastic Activity Networks (SANs) model was built toanalyze how fault coverage impacts the overallperformability of the system. In this way, the integrity ofthe SRS was assessed.We discuss the significance of thisapproach and propose approaches for improvingperformability/fault tolerance.

Download full-text


Available from: F.T. Sheldon, Jul 25, 2014
9 Reads
  • Source
    • "Most recent studies of completeness of specification in the literature are related to the application of some formal method for analysis and validation or often related to algebraic specifications [28]. For example Sheldon et al [29] have combined Z, Statecharts, and Stochastic Activity Network to validate a Natural Language software requirements specifications for completeness, consistency , and fault-tolerance. "
    [Show abstract] [Hide abstract]
    ABSTRACT: The initial expression of requirements for a computer-based system is often informal and possibly vague. Requirements engineers need to examine this often incomplete and inconsistent brief expression of needs. Based on the available knowledge and expertise, assumptions are made and conclusions are deduced to transform this ‘rough sketch’ into more complete, consistent, and hence correct requirements. This paper addresses the question of how to characterize these properties in an evolutionary framework, and what relationships link these properties to a customer's view of correctness. Moreover, we describe in rigorous terms the different kinds of validation checks that must be performed on different parts of a requirements specification in order to ensure that errors (i.e. cases of inconsistency and incompleteness) are detected and marked as such, leading to better quality requirements.
    Information and Software Technology 09/2004; 46(11-46):763-779. DOI:10.1016/j.infsof.2004.03.003 · 1.05 Impact Factor
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: 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
    Reliability and Maintainability Symposium, 2002. Proceedings. Annual; 02/2002
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: Software development starts by specifying the requirements. A Software Requirements Specification (SRS) describes what the software must do. Naturally, the SRS takes the core role as the descriptive documentation at every phase of the development cycle. To avoid problems in the latter development phases and reduce life-cycle costs, it is crucial to ensure that the specification is correct. This paper describes how to model, test and evaluate (i.e., check, examine, and probe) a natural language (NL) SRS using two formalisms (Z and Statecharts). These formalisms are used to determine strategies for avoiding design defects that stem from the requirements that could ultimately lead to system failures. A case study was performed to validate the integrity of a Guidance Control SRS in terms of completeness, consistency, and fault-tolerance. Based on these experiences, the NL-specificationZStatechart transformations can be completed in a systematic and repeatable manner that yield valuable insight into the overall integrity of software specifications.
    Software Quality Control 08/2004; 12(3):231-264. DOI:10.1023/B:SQJO.0000034710.86897.16 · 1.14 Impact Factor
Show more