Automated Analysis of Requirement Specifications

It is generally accepted that poorly written requirements can result in software with the wrong functionality. The Goddard Space Flight Center’s (GSFC) Software Assurance Technology Center (SATC) has developed ,an early life cycle tool for assessing requirements that are specified in natural language. The tool searches the document for terms the SATC has identified as quality indicators, e.g. weak phrases. The reports produced by the tool are used to identify specification statements and structural areas of the requirements specification document that need to be improved. The metrics are used by project managers to recognize and preclude potential areas of risk. INTRODUCTION The SATC is part of the Office of Mission Assurance of the GSFC. The SATC’s mission is to assist National Aeronautics and Space Administration (NASA) projects to improve the quality of software that they acquire or develop. The SATC’s efforts are currently focused on the development and use of metric methodologies and tools that identify and assess risks associated with software performance and scheduled delivery. It is generally accepted that the earlier in the life cycle that potential risks are identified the easier it is to eliminate or manage the risk inducing conditions [l] . Despite the significant advantages attributed to the use of formal specification languages, their use has not become common practice. Because requirements that the acquirer expects the developer to contractually satisfy must ICSE 97 Boston MA USA O-89791-914-9/97/05 be understood by both parties, specifications are most often written in natural language. The use of natural language to prescribe complex, dynamic systems has at least three severe problems: ambiguity, inaccuracy and inconsistency [ 111. Many words and phrases have dual meanings which can be altered by the context in which they are used. For example, Webster’s New World Dictionary identifies three variations in meaning for the word “align”, seventeen for “measure”, and four for the word “model”. Weak sentence structure can also produce ambiguous statements. ‘Twenty seconds prior to engine shutdown anomalies shall be ignored. ” could result in at least three different implementations. Using words such as “large”, “rapid”, and “many’ produces inaccurate requirement specifications. Even though the words “error”, “fault”, and “failure” have been precisely defined by the Institute of Electrical and Electronics Engineers (IEEE) [5] they are frequently used incorrectly. Defining a large, multidimensional capability within the limitations imposed by the two dimensional structure of a document can obscure the relationships between individual groups of requirements. The importance of correctly documenting requirements has caused the software industry to produce a significant number of aids [3] to the creation and management of the requirements specification documents and individual specifications statements. Very few of these aids assist in evaluating the quality of the requirements document or the individual specification statements. This situation has motivated the SATC to develop a tool to provide metrics that NASA project managers can use to assess the quality of their requirements specification documents and to identify risks that poorly specified requirements will introduce into their project. It must be emphasized that the tool does not attempt to assess the correctness of the requirements specified. It assesses the structure of the