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

ABSTRACT 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.

  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: Eliciting requirements for a proposed system inevitably involves the problem of handling undesirable information about customer's needs, including inconsistency, vagueness, redundancy, or incompleteness. We term the requirements statements involved in the undesirable information non-canonical software requirements. In this paper, we propose an approach to handling non-canonical software requirements based on Annotated Predicate Calculus (APC). Informally, by defining a special belief lattice appropriate for representing the stakeholder's belief in requirements statements, we construct a new form of APC to formalize requirements specifications. We then show how the APC can be employed to characterize non-canonical requirements. Finally, we show how the approach can be used to handle non-canonical requirements through a case study.
    Knowledge and Information Systems 12/2006; 11(1):85-104. · 2.64 Impact Factor
  • Source
    [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; · 1.33 Impact Factor
  • 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. · 0.88 Impact Factor

Full-text (2 Sources)

Available from
Jul 25, 2014