Using abstraction and model checking to detect safety violations in requirements specifications

Although model checking has proven remarkably effective in detecting errors in hardware designs, its success in the analysis of software specifications has been limited. Model checking algorithms for hardware verification commonly use Binary Decision Diagrams (BDDs) to represent predicates involving the many Boolean variables commonly found in hardware descriptions. Unfortunately, BDD representations may be less effective for analyzing software specifications, which usually contain not only Booleans but variables spanning a wide range of data types. Further, software specifications typically have huge, sometimes infinite, state spaces that cannot be model checked directly using conventional symbolic methods. One promising but largely unexplored approach to model checking software specifications is to apply mathematically sound abstraction methods. Such methods extract a reduced model from the specification, thus making model checking feasible. Currently, users of model checkers routinely analyze reduced models but often generate the models in ad hoc ways. As a result, the reduced models may be incorrect. This paper, an expanded version of (Bharadwaj and Heitmeyer, 1997), describes how one can model check a complete requirements specification expressed in the SCR (Software Cost Reduction) tabular notation. Unlike previous approaches which applied model checking to mode transition tables with Boolean variables, we use model checking to analyze properties of a complete SCR specification with variables ranging over many data types. The paper also describes two sound and, under certain conditions, complete methods for producing abstractions from requirements specifications. These abstractions are derived from the specification and the property to be analyzed. Finally, the paper describes how SCR requirements specifications can be translated into the languages of Spin, an explicit state model checker, and SMV, a symbolic model checker, and presents the results of model checking two sample SCR specifications using our abstraction methods and the two model checkers.

Formal specifications of software systems are extremely useful because they can be rigorously analyzed, verified, and validated, giving high confidence that the specification captures the desired behavior. To transfer this confidence to the actual source code implementation, a formal link is needed between the specification and the implementation. Generating the implementation directly from the specification provides one such link. A program transformation system such as Paige's APTS can be useful in developing a source code generator. This paper describes a case study in which APTS was used to produce code generators that construct C source code from a requirements specification in the SCR (Software Cost Reduction) tabular notation. In the study, two different code generation strategies were explored. The first strategy uses rewrite rules to transform the parse tree of an SCR specification into a parse tree for the corresponding C code. The second strategy associates a relation with each node of the specification parse tree. Each member of this relation acts as an attribute, holding the C code corresponding to the tree at the associated nodes the root of the tree has the entire C program as its member of the relation. This paper describes the two code generators supported by APTS, how each was used to synthesize code for two example SCR requirements specifications, and what was learned about APTS from these implementations.

SCR (Software Cost Reduction) specifications are useful for specifying event-driven systems. To use SCR effectively for critical applications, automated verification of safety properties is important. The fact that model checking approaches are sometimes problematic motivates us to further examine the alternative approach of theorem proving. Theorem proving, in general, is a difficult task; however the regular structure of the proof obligations generated from SCR specifications suggests that relatively unsophisticated theorem provers can discharge many of these obligations. As a feasibility study, we use the B-Toolkit to detect safety violations in an example SCR specification. The B-Toolkit is a good choice because it is commercially available and Supports verified refinement to executables in a commercial programming language (C). We convert the mode transition table in the example SCR specification to an AMN (Abstract Machine Notation) specification and analyze the result with the B-Toolkit. The B-Toolkit generates 120 proof obligations of which 113 are automatically discharged by the theorem prover. The remaining 7 proof obligations are, in fact, not theorems and correspond to the 3 problems in the SCR specification detected by the model checking approaches. For the corrected SCR specification, the B-Toolkit automatically discharges all proof obligations. The example shows that even simple theorem provers are a viable approach to automated analysis for SCR specifications.

An Ameliorated Methodology for the Abstraction of Object Oriented Features from Software Requirements Specification

: This paper describes a compositional proof strategy for verifying properties of requirements specifications. The proof strategy, which may be applied using either a model checker or a theorem prover, uses known state invariants to prove state and transition invariants. Two proof rules are presented: a standard incremental proof rule analogous to Manna and Pnueli's incremental proof rule and a compositional proof rule. The advantage of applying the compositional rule is that it decomposes a large verification problem into smaller problems which often can be solved more efficiently than the larger problem. The steps needed to implement the compositional rule are described, and the results of applying the proof strategy to two examples, a simple cruise control system and a realworld Navy system, are presented. In the Navy example, compositional verification using either theorem proving or model checking was three times faster than verification based on the standard incremental (noncompositional) rule. In addition to the two above rules for proving invariants, a new compositional proof rule is presented for circular assume-guarantee proofs of invariants. While in principle the strategy and rules described for proving invariants may be applied to any state-based specification with parallel composition of components, the specifications in the paper are expressed in the SCR (Software Cost Reduction) tabular notation, the auxiliary invariants used in the proofs are automatically generated invariants, and the verification is supported by the SCR tools.

We have been involved in a number of large-scale software development projects, which might lead to loss of millions of dollars if failed. The quality of SRS (Software Requirements Specification) is the key to success of the software development. Review and inspection are common practices for the verification and validation of SRS. However, verification techniques used in projects might be characterized as ad hoc. In this article, we propose requirements clinic, a third party inspection methodology for improving the quality of the SRS. In order to systematically inspect a SRS, we developed a perspective-based inspection methodology based on PQM (Pragmatic Quality Model) of SRS. PQM is derived from IEEE Std. 830 from the perspective of pragmatic quality. To inspect a SRS according to PQM, we identified 198 inspection points, which lead to a quality score between 0 and 100. The requirements clinic advises to the requirements engineering team by a comprehensive quality inspection report including quality score, benchmark and SRS patterns for improvement. Since 2010, we have been practicing the methodology to a variety of development projects, and revealed an average of 10.6 ROI in 12 projects. We also discuss the feasibility of the methodology and lessons learned from the practices.

The aim of this study is the development of the method of generating and filling the template of ontology for the quality of the concrete software and method of forming the logical conclusion about the sufficiency of information of software requirements specification (SRS) for software quality assessment (by ISO 25010:2011). The first time proposed method of generating and filling the template of ontology for the quality of the concrete software leaves in the relevant ontology only measures, which are available in the SRS for the concrete software. It provides forming the ontology for the quality of the concrete software. The first time developed method of forming the logical conclusion about the sufficiency of the SRS information for software quality assessment provides the conclusion about the sufficiency or insufficiency of the SRS information for software quality assessment by ISO 25010:2011. If the SRS information is insufficient, this method: provides the conclusion for which characteristics and sub-characteristics the information is insufficient; creates the sorted list of missing measures as the recommended priority of their addition in the SRS; evaluates the veracity of software quality assessment based on the available in the SRS measures.

Many critical control systems are developed using formal methods. When software applied to such systems is developed, the employment of formal methods in the software requirements specification and verification will provide increased assurance for such applications. Earlier error of overlooked requirement specification can be detected using formal specification method. Also the testing and full verification to examine all reachable states using model checking to undertake formal verification are able to be completed. In this paper, we proposed an eclectic approach to incorporate Z(Zed) formal language and ‘Statemate MAGNUM’ which is formal method tools using Statechart. Also we applied the proposed method to safety-critical railway signaling systems for the formal requirement specification and analyzed the specification results.

Rural development can be favoured not only with the development of new and sustainable agricultural practices, but also with information communication technology applications. Requirements analysis and specification for mobile software has been recognized as a key factor for economic success and as a support to E-commerce. With the aim to develop a mobile application for a small group of farmers, a partnership among the Ministry of Agriculture and Livestock (MAG), the Institute Costa Rican Electricity, Telecommunications (ICE), the University of Costa Rica (UCR), and a group of organic farmers was established. Here we describe the different processes and the connection between the user needs and the software development team. After defining the specific roles of each organization, we provided especial consideration for the adoption phase, due to digital divide of the target group of small organic farmers. The analysis conducted concluded that the creation of the mobile application had both benefits and challenges. On one hand, it represented an important first step into the world of Information Communication Technology (ICT) applied to organic farming activities in Costa Rica that can surely boost e-commerce. The needs were potentially solved by the inherent advantages of ICT in an increasingly competitive world, with equity of opportunities, and the important challenge to preserve the biodiversity with sustainable agricultural practices. The specifications of mobile software requirements established in this project were supported by considerations of adoption and of collaboration, cooperation and communication strategies among key stakeholders to follow-up, the implementation phase and to assure success.

The paper argues that quality assurance must begin with quality software requirements specification (SRS) and that by preserving the link between a customer's requirements definition and the SRS, the quality of a software system can be assured beyond first release. Without such a link, it would be difficult to properly analyse the effect of related or inconsistent requirements because the reason for their existence in the final SRS document has been lost, an example of forward and backward tracing requirements through the business and system models developed during analysis and design is given. Areas of further research are then identified.

The requirements of a system describe what the user expects from the system – in other words, what the system will do for the user. When defining the requirements of a system, the system should be viewed as a black box, so that only the external characteristics of the system are considered. Both functional and nonfunctional requirements need to be considered. Requirements modeling consists of requirements analysis and requirements specification. Use case modeling is an approach for describing the functional requirements of the system, as described in this chapter. The system's data requirements in terms of the information that needs to be stored by the system are determined using static modeling, as described in Chapter 7. The inputs to the system and the outputs from the system are described initially in the use case models and then specified in more detail during static modeling. This chapter gives an overview of software requirements analysis and specification in Section 6.1. It then goes on to describe the use case approach to defining functional requirements, as well as how to extend use cases to describe nonfunctional requirements. This chapter describes the concepts of actors and use cases , and then goes on to describe use case relationships, in particular, the include and extend relationships. Section 6.2 gives an overview of use case modeling followed by an example of a simple use case. Section 6.3 then describes actors and their role in use case modeling.

Basically, aircraft engines can be divided into a control embedded system and a controlled system with its environment. The behaviour of the controlled system is given a priori, while the control system still needs to be designed in a way guaranteeing the correct overall behaviour under all operational conditions depending on the flight domain. A large quantity of functions in control systems can be described by a formal system expressed in block diagrams and state-based representations. These representations can be translated to formal based tools relying on the synchronous languages Signal and Statecharts. SACRES is a tool set supporting the design of safety-critical embedded control systems. It integrates the tools and specification techniques Statemate, Sildex, and Timing Diagrams with tool components for automatic code generation, formal verification based on model checking techniques, and an innovative approach for automatic code validation for target code generated from DC+. Technical achievements are The main benefits of the SACRES approach are reduced risks for design errors and decreased design times and costs for the development of dependable (safety critical) embedded systems. SACRES is an attempt to avoid unpredictability (particularly that arising from late feedback from testing) associated with development of safety critical systems, through the use of the maximum degree of automation, especially in respect of code generation and verification. An outstanding property of SACRES is the combination of specification styles and specification tools being applied in practice with automatic tools to establish provable correctness with respect to required properties. Both dependability and productivity are increased by automatic code generation from high-level specifications such that the generated code can be validated against higher levels by rigorous proofs. These techniques allow traditional tests by sampling to be replaced by rigorous checking techniques which correspond to 100% coverage of test cases. In order to address a global innovative approach in the near future which match the whole software configuration, the SACRES tool set should be interfaced with asynchronous techniques matching the operating system development. This raises an open question in the software development future new process.

Collecting and analyzing user requirements is undoubtedly a really complicated and often problematic process in software development projects. There are several approaches, which suggest ways of managing user’s requirements; some of the most well-known are IEEE 830 software requirements specification (SRS), use cases, interaction design scenarios, etc. Many software experts believe the real user requirements emerge during the development phase. By constantly viewing functional sub-systems of the whole system and participating, in fact, in all phases of system development, customers/users can revise their requirements by adding, deleting, or modifying them. However, in order for this to become possible, it is important to adopt a totally different approach than the traditional one (waterfall model approach), concerning not only the management of user’s requirements, but also the entire software development process in general. Agile methodologies represent this different approach since the iterative and incremental way of development they propose includes user requirements revision mechanisms and user active participation throughout the development of the system. The most famous approach concerning requirements specification among the supporters of the agile methodologies is probably user stories. User stories and their main characteristics are thoroughly demonstrated in this chapter. After reading this chapter, the authors hope that the reader may have gained all the basic understanding regarding the use of user stories.

Collecting and analyzing user requirements is undoubtedly a really complicated and often problematic process in software development projects. There are several approaches, which suggest ways of managing user’s requirements; some of the most well-known are IEEE 830 software requirements specification (SRS), use cases, interaction design scenarios, etc. Many software experts believe the real user requirements emerge during the development phase. By constantly viewing functional sub-systems of the whole system and participating, in fact, in all phases of system development, customers/users can revise their requirements by adding, deleting, or modifying them. However, in order for this to become possible, it is important to adopt a totally different approach than the traditional one (waterfall model approach), concerning not only the management of user’s requirements, but also the entire software development process in general. Agile methodologies represent this different approach since the iterative and incremental way of development they propose includes user requirements revision mechanisms and user active participation throughout the development of the system. The most famous approach concerning requirements specification among the supporters of the agile methodologies is probably user stories. User stories and their main characteristics are thoroughly demonstrated in this chapter. After reading this chapter, the authors hope that the reader may have gained all the basic understanding regarding the use of user stories.

SummaryFormal requirements specifications, eg, software cost reduction (SCR) specifications, are challenging to analyse using automated techniques such as model checking. Since such specifications are meant to capturerequirements, they tend to refer to real‐world magnitudes often characterized through variables over large domains. At the same time, they feature a high degree of nondeterminism, as opposed to other analysis contexts such as (sequential) program verification. This makes model checking of SCR specifications difficult even for symbolic approaches. Moreover, automated abstraction refinement techniques such as counterexample guided abstraction refinement fail in many cases in this context, since the concrete state space is typically large, and reaching specific states of interest may require complex executions involving many different states, causing these approaches to perform many abstraction refinements, and making them ineffective in practice. In this paper, an approach to tackle the above situation, through a 2‐stage abstraction, is presented. The specification is first relaxed, by disregarding the constraints imposed in the specification by physical laws or by the environment, before being fed to a counterexample guided abstraction refinement procedure, tailored to SCR. By relaxing the original specification, shorter spurious counterexamples are produced, favouring the abstraction refinement through the introduction of fewer abstraction predicates. Then, when a counterexample is concretizable with respect to the relaxed (concrete) specification but it is spurious with respect to the original specification, an efficient though incomplete refinement step is applied to the constraints, to cause the removal of the spurious case. This approach is experimentally assessed, comparing it with related techniques in the verification of properties and in automated test case generation, using various SCR specifications drawn from the literature as case studies. The experiments show that this new approach runs faster and scales better to larger, more complex specifications than related techniques.