SOFTWARE REQUIREMENTS: ARE THEY REALLY A PROBLEM? T. E. Bell and T. A. Thayer TRW Defense and Space Systems Group Redondo Beach, California ,Keywords and Phrases Space Systems Group* to examine and improve the quality of requirements. Ballistic Missile Defense Requirements One of the first efforts in SREP has been to Requirements Problems characterize the problems with requirements so that Software Engineering techniques can be developed to improve the situation. Software Requirements Instead of pursuing philosophical discussions about Software Requirements Engineering what the problems might be, we have undertaken empiri- Software Requirements Problems cal studies to determine what the problems actually SREM are. A limitation on the number of Ballistic Missile SREP Defense (BMD) systems currently being developed (there is only one) has led us to examine both BMD and more Abstract common data processing systems to ensure that our results are characteristic of software requirements in Do requirements arise naturally from an obvious general, rather than just one particular project. need, or do they come about only through diligent effort -- and even then contain problems? Data on This paper reports on initial results that have two very different types of software requirements were set much of the direction pursued in the Software analyzed to determine what kinds of problems occur and Requirements Engineering Methodology [2], the Require- whether these problems are important. The results are ments Statement Language [3], and the Requirements dramatic: software requirements are important, and Engineering and Validation System [4]. The initial their problems are surprisingly similar across pro- efforts were oriented to determine the magnitude and jects. New software engineering techniques are characteristics of the problems, and to indicate what clearly needed to improve both the development and types of techniques could correct the problems. The statement of requirements. empirical study of software problems is continuing in parallel with technology development so that the I. Introduction technology can be refined and tested for effectiveness in solving the identified problems. Identifying the cause of a problem in a software system is often very easy -- if the cause is a problem II, What are Software Requirements? in code. Typically, identified coding problems result in clearly incorrect answers or in abnormal termina- One school of thought maintains that software tions of the software. Similarly, problems in a soft- requirements arise naturally, and that they are correct ware system caused by deficiencies in design are often by definition. If these requirements merely state a easy to identify from unexpected software operation or basic need (e.g., "do payroll"),then that's all that from extreme difficulty in maintaining and modifying is needed. On the other hand, if the requirements state the system. Problems in the system caused by defi- each subroutine's detailed characteristics, then those ciencies in software requirements, on the other hand, are the required characteristics, and the implementer are often not identified at all, or are thought to be should not question them. caused by bad design or limitations of computing tech- nology. If there are problems in developing require- Adherents to this school of thought have grown ments, however, the software system meeting those fewer and fewer as the software industry has gathered requirements will clearly not be effective in solving experience with this approach to developing software. the basic need, even if the causes of the problems When every requirement ranging in detail from needs are incorrectly identified. statements to subroutine specifications is considered in the same way, the resulting systems tend to be The Ballistic Missile Defense Advanced Technology seriously deficient. If coding personnel are assigned Center (BMDATC) is sponsoring an integrated software the task of implementing a system with only a needs development research program Ill to improve the tech- statement, the critical phase of software design will niques for developing correct, reliable BMD software. likely be skipped -- with disasterous results. On the Reflecting the critical importance of requirements in other end of the scale, if detailed subroutine speci- the development process; the Software Requirements fications are accepted without ever having been Engineering Program (SREP) has been undertaken as a part of this integrated program by TRW Defense and *Under Contract DASG60-75-C-O022 61 examined for correctness, the resulting software will of having a complete set of requirements, all at pre- probably fail to complete execution normally, much cisely one level, seldom occurs because requirements less produce correct results. engineers find less difficulty in stating a specific design, or leaving statements very general, in certain The evolution of approaches for the development areas [6]. Therefore, our empirical studies have of software systems has generally paralleled the concentrated on the documents that have their major evolution of ideas for the implementation of code. emphasis on the software requirements that we have Over the last ten years more structure and discipline defined, even if they have some requirements at dif- have been adopted, and practicioneers have concluded ferent levels of detail. that a top-down approach is superior to the bottom-up approach of the past. The Military Standard set MIL- III. Empirical Data STD 490/483 recognized this newer approach by speci- fying a system requirements document, a "design-to" The remembrances of engineers who participated on requirements document that is created in response to a requirements engineering project are usually faulty. the system requirements, and then a "code-to" re- Memories are biased by personal conflicts and occur- quirements document for each software module in the rences from long after the software is implemented. design. Each of these is at a lower level of detail An empirical study of requirements must therefore than the former, so the system developers are led either be based on information documented during the through a top-down process. The same top-down approach project or be based on data collected during the pro- to a series of requirements statements is explained, ject through observation. We have used data from two without the specialized military jargon, in an ex- projects in our analyses; for one project we used only cellent paper by Royce [5]; he introduced the concept documented data while in the other we used both docu- of the "waterfall" of development activities. In mented data and observation. this approach software is developed in the disciplined sequence of activities shown in Figure I. The pieces of paper recording ~oftware require- ments deficiencies are typically called problem reports Each of the documents in the early phases of the and are written either to record the results of reviews waterfall can be considered as stating a set of or to request changes in the requirements during the requirements. At each level a set of requirements software development project. The points indicated in serve as the input and a design is produced as output. Figure 2 during a software development project's life This design then becomes the requirements set for the are the times when most of the problem reports in- designer at the next level down. volving software requirements are generated; during reviews, during design, and during implementation. The With so many levels of requirements documents, same software requirements deficiency might be iden- and with so few software projects mapping nicely into tified at any of several points in the project's life, the scheme, we must be more specific about what we so it may be documented on a design problem report, a mean by the term "software requirements" as used in software problem report, or a test problem report. our studies. We do not mean all the various levels of requirements, but only a single one, one that can Problem reports are only written to document usually be identified in large software development significant deficiencies -- those that could cause projects that have ended successfully. At this level major or catastrophic problems in the ultimate system. the software requirements describe functions that the The effort in writing a problem report is actually software must perform, but not how they must be quite small, but the psychological cost of putting a implemented. For example, they might contain a criticism in written form, and then being willing to requirement that a BMD system identify erroneous defind it, is high enough that irrelevant and minor P~ADAR returns that have any of five specific charac- problems (e.g., spelling errors and indentation) are teristics. However, the software to meet this ignored. requirement might be spread through twelve sub- routines using any of a large number of identification Problem reports do not generally document the techniques. correction of deficiencies (except for suggested re- visions), but they do record the symptoms of the pro- In weapon systems like BMD, these software blem. Therefore, data are available for frequency requirements lie at lower (more detailed) levels of analysis of symptoms, but not usually for analysis detail than the general, summary Data Processing Sub- about the types of correction to the requirement system Performance Requirements (DPSPR); DPSPR re- statement. In some cases