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.23 Impact Factor
  • [Show abstract] [Hide abstract]
    ABSTRACT: Poorly written requirements are a common source of software defects. In application areas like space systems, the cost of malfunctioning software can be very high. This way, assessing the quality of software requirements before coding is of utmost importance. This work proposes a systematic procedure for assessing software requirements for space systems that adopt the European Cooperation for Space Standardization (ECSS) standards. The main goal is to provide a low-cost, easy-to-use benchmarking procedure that can be applied during the software requirements review to guarantee that the requirements specifications comply with the ECSS standards. The benchmark includes two checklists that are composed by a set of questions to be applied to the requirements specification. It was applied to the software requirements specification for one of the services described in the ECSS Packet Utilization Standard (PUS). Results show that the proposed benchmark allows finding more with a low effort.
    Computer Safety, Reliability, and Security, 29th International Conference, SAFECOMP 2010, Vienna, Austria, September 14-17, 2010. Proceedings; 01/2010
  • 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.85 Impact Factor

Full-text (2 Sources)

1 Download
Available from
Jul 25, 2014