The SCR Method for Formally Specifying, Verifying, and Validating Requirements: Tool Support
C. Heitmeyer,J. Kirby,B. Labaw
DOI: https://doi.org/10.1145/253228.253498
1997-05-01
Abstract:I N T R O D U C T I O N Given the high frequency of requirements errors, the serious accidents they may cause, and the high cost of correcting them, techniques for improving the quality of requirements specifications and for early detection of requirements errors are crucial. One promising approach to reducing software errors is to apply formal methods to the requirements specification. Using a formal notation to specify requirements can reduce errors by reducing ambiguity and imprecision. Applying formal analysis to the requirements specification can detect many classes of errors, some automatically. The SCR (Software Cost Reduction) requirements method, which is based on a tabular notation, is a formal method for specifying the requirements of real-time, embedded systems introduced more than a decade ago by the A-7 project. Designed for use by engineers, the SCR method has been applied to a variety of practical systems, including avionics systems, telephone networks, and safety-critical components of nuclear power plants. Recently, a version of SCR was used to specify the requirements of Lockheed’s C-130J Operational Flight Program (OFP) [a]. The OFP contains more than 100K of Ada code, thus demonstrating the scalability of the SCR method. While the above applications of SCR rely on manual techniques, effective use of the method in industry will require powerful and robust tool support. A significant barrier to industrial use of formal methods to date has been the weakness of the methods associated with given formalisms. Although much attention has been focused on the f o r m a l aspects of formal methods, too little effort has been devoted to the supporting methods. To be useful in practice, formal methods must not only provide * This work was supported by ONR and SPAWAR. http:/ /www.itd.nrl .ny.~l /ITD/554O/perso~el /heitmeyer.ht~ rigor, they must also be usable by software developers and supported by robust, well-engineered tools. In many practical cases, a large amount of detail is required to apply a formal method. This detail is unmanageable without some automation. SCR* (also called STSR) is an integrated suite of tools supporting the SCR requirements method [4]. The tools include a specification editor for creating and modifying a requirements specification, a dependency graph browser for displaying the dependencies among the variables in the specification, a s imu la tor for symbolically executing the system based on the specification, a consis tency checker for checking the specification for application-independent properties (e.g., type correctness and completeness), and a verif ier for analyzing the specification for critical application properties. SCR METHOD: B A C K G R O U N D In SCR, the required system behavior is described by a mathematical relation between monitored variables, denoting environmental quantities that the system monitors, and controlled variables, denoting environmental quantities that the system controls. To specify this relation concisely, our method uses conditions, events, and tables. A condi t ion is a predicate defined on one or more variables in the specification. An event occurs when any variable changes value. The environment changes monitored quantities, thus causing i npu t events . In response, the system may change the value of one or more controlled quantities. Each SCR table specifies the required value of a variable as a mathematical function defined on conditions and events. Among the tables in SCR specifications are condition tables, event tables, and mode transition tables. The tables facilitate industrial application of the SCR method. Not only do engineers find tables relatively easy to understand and to develop; in addition, tables can describe large quantities of requirements information concisely. SCR Requirements Model. To provide a precise and detailed semantics for the SCR method, our requirements model represents the system to be built as a finite state automaton and describes the monitored and control variables, conditions, events, and other constructs that make up an SCR specification in terms of that automaton [7]. Our automaton model represents all monitored and controlled quantities, even those which are naturally continuous, as discrete variables. Moreover, because our model initially abstracts away timing and imprecision, it describes the “ideal” system behavior. The system requirements are easier to specify and to