Formal Methods for Specifying Validating, and Verifying Requirements

During the past three decades, many formal methods have been proposed whose purpose is to reduce the cost of constructing computer systems and to improve their quality. Informally, a formal method is a mathematically-based technique or too

A Security Model for Military Message Systems

Military systems that process classified information must operate in a secure manner; i.e., they must adequately protect information against unauthorized disclosure, modification, and withholding. A goal of current research in computer security is to facilitate the construction of multilevel secure systems, systems that protect information of different classifications from users with different clearances. Security models are used to define the concept of security embodied by a computer system. A single model, called the Bell and LaPadula model, has dominated recent efforts to build secure systems but has deficiencies. We are developing a new approach to defining security models based on the idea that a security model should be derived from a specific application. To evaluate our approach, we have formulated a security model for a family of military message systems. This paper introduces the message system application, describes the problems of using the Bell-LaPadula model in real applications, and presents our security model both informally and formally. Significant aspects of the security model are its definition of multi-level objects and its inclusion of application-dependent security assertions. Prototypes based on this model are being developed. 1

Applying a formal requirements method to three NASA systems: Lessons learned

Abstract — Recently, a formal requirements method called SCR (Software Cost Reduction) was used to specify software requirements of mission-critical components of three NASA systems. The components included a fault protection engine, which determines how a spacecraft should respond to a detected fault; a fault detection, isolation and recovery component, which, in response to an undesirable event, outputs a failure notification and raises one or more alarms; and a display system, which allows a space crew to monitor and control on-orbit scientific experiments. This paper demonstrates how significant and complex requirements of one of the components can be translated into an SCR specification and describes the errors detected when the authors formulated the requirements in SCR. It also discusses lessons learned in using formal methods to document the software requirements of the three components. Based on the authors ’ experiences, the paper presents several recommendations for improving the quality of requirements specifications of safety-critical aerospace software. 1

Formal Methods For Developing High Assurance Computer Systems: Working Group Report

This report summarizes the discussions conducted on the topic "Formal Methods for Developing High Assurance Systems." High assurance computer systems are computer systems where convincing evidence is required that the system satisfies a collection of critical properties. To operate correctly, these systems must satisfy properties such as safety and security. Examples of high assurance systems include flight control systems, medical systems, and control systems for nuclear plants. In addition, increased reliance on communications is moving many communications systems, such as telephone networks and cellular and satellite communications systems, into the domain of high assurance systems. The aim of the 1998 discussion was to revisit and continue a discussion began in the working group with the same name at the first WIFT in 1995. A report describing the discussions at WIFT'95 is available at the web site: http://www.cse.msu.edu/WIFT98

Program Synthesis from Formal Requirements Specifications using APTS

Abstract. 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 node; 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

Automated Consistency Checking of Requirements Specifications

This paper describes a formal analysis technique, called consistency checking, for automatic detection of errors, such as type errors, nondeterminism, missing cases, and circular definitions, in requirements specifications. The technique is designed to analyze requirements specifications expressed in the SCR (Software Cost Reduction) tabular notation. As background, the SCR approach to specifying requirements is reviewed. To provide a formal semantics for the SCR notation and a foundation for consistency checking, a formal requirements model is introduced; the model represents a software system as a finite state automaton, which produces externally visible outputs in response to changes in monitored environmental quantities. Results are presented of two experiments which evaluated the utility and sealability of our technique for consistency checking in a real-world avionics application. The role of consistency checking during the requirements phase of software development is discussed