No abstract

In an effort to improve the quality of software and system requirements, Formal methods (FM) is being investigated by NASA because evidence existed that FM is useful in creating consistent and verifiable specifications. This investigation of FM consists of trial projects that are used to gather data on FM's cost-effectiveness and to demonstrate this effectiveness to prospective users. These trial projects were specifically constructed to maximize the likelihood that requirements analysts will recognize the benefits of FM and integrate it into their existing approaches. A key aspect of these trial-projects is the make-up of the teams which influenced the planning, execution, and evaluation of results. Through these projects, much has been learned about the use of FM and its potential for being accepted as a viable way to improve requirements analysis. 1: Background and Logistics ProblemRecent studies of software subsystems in critical applications are yielding data which expose a software requirements quality problem facing current and future projects. It appears that early stages of the software life cycle are especially prone to errors that can have a lasting influence on the reliability, cost, and safety of a system. A sample of the conclusions from these studies points to requirements and design specifications as a high priority candidate for better software engineering techniques:Most hazardous software safety errors found during system integration and test of two NASA spacecraft were the result of requirements discrepancies or interface specifications [7]The highest density of major defects found through the use of software inspections was during the requirements phase. This was 7 times higher than the density of major defects found in code inspections [6] Requirements errors are between 10 and 100 times more costly to fix at later phases of the software life cycle than at the requirements phase itself [ 11, [2], [6].These observations indicate the need to advance the state-of-the-practice in the area of software requirements engineering.One reason that requirements engineering deserves special attention is its general lack of tools and effective procedures relative to later life cycle phases (e.g., detailed design and code), which are already supported by well-defined methods, languages, and automated tools.In contrast, current requirements engineering practice suffers from too much dependence on ad hoc methods and ambiguous natural language specifications, and from little or no automated support. Another motivation for moving beyond status quo techniques for requirements engineering is illustrated by the so-called "quality ceiling" which advanced organizations are encountering in some of their high-end software development products. This occurs when the currently employed 30 0-8186-7005-3/95 $04.00 0 1995 IEEE development and assurance techniques undergo so much optimization and fine-tuning that no additional major quality improvements can be expected. The demands of developing software systems in a high-c...

No abstract

No abstract

No abstract