SOME PROBLEMS WITH REQUIREMENTS DETERMINATION

All computer science students get extensive experience in software coding as part of their undergraduate and graduate education. Students often have to supply both internal docu- mentation (in the form of comments within their programs) and external documentation (often in the form of project reports). They may also have some experience with software testing within their academic setting. Some students even get experience in software main- tenance during their academic careers, although this is relatively rare. Students may see testing and maintenance during work experiences outside of their formal education setting. Although such work experience is highly desirable, not all students have this experience at

this stage of their academic careers, and hence such familiarity will not be assumed in the discussion in this book.

Two topics are often missing from the typical education of computer science students (prior to taking a course emphasizing software engineering principles): detailed, practical instruction in (1) requirements and (2) design.

Unfortunately, most of the other software engineering activities are irrelevant if the requirements are wrong, incomplete, or vague. One way in which the term “wrong” here is used is the sense of being inconsistent; one requirement contradicts another. Let us con- sider what can happen in each of these three cases.

If the requirements for a project are wrong, then the rest of the software engineering activities will have to be redone, assuming that someone recognizes the error or errors in the requirements. This is extremely expensive, and often means that much of the subsequent work is wrong and has to be discarded. In the worst case, all the project effort must be scrapped.

What else can “wrong” mean? It may mean that the requirements do not fit the desired system’s initial use. This is called “building the system wrong.” “Wrong” might also mean that the requirements are for a system that is obsolete or completely the opposite of what most customers want. This is called “building the wrong system.”

There are two possibilities if the requirements are incomplete. The best-case scenario when the requirements are incomplete is that the requirements are so modular that the project’s design and code also can be developed in a modular manner. In this case, it is possible that the missing requirement can be fulfilled by additions both to the design and the source code implementation with relatively few changes needed to incorporate the new requirements. This flexibility is one of the main advantages of iterative approaches such as the rapid prototyping or spiral development life cycle models. The flexibility is even greater in projects using agile methods.

If the requirements were complete but not modular, then it is unlikely that the design and the resulting source code will be modular. In this case, major portions of the design and source code will have to be scrapped because they are difficult to create given the lack of consistency with modern programming techniques and the software engineering goal of modularity. The experience of many failed software projects strongly indicates that the lack of modular requirements is very expensive.

The third category of poor requirements occurs when the requirements are vague. In this situation, it is difficult to know if the design is correct, because the software designers do not know precisely what requirements mean. The designers may make some unwar- ranted assumptions about the intentions of the requirements engineer. These assumptions, if not correct, can be the major source of disaster for projects. The most common problem is that the unwarranted assumptions become part of the culture of the project and there- fore are never questioned.

There is one more thing to keep in mind about vague requirements. If the requirements are vague as stated, but the software engineers working on the project are highly knowl- edgeable in a particular application domain and have the unquestioned capability to fill in the gaps and complete them in a clear, unambiguous manner, an agile software develop- ment process may work, provided there is support from senior management.

In some cases, the term nonfunctional requirement is used. The term usually is taken to mean that some particular software attribute is desirable, but there is no description of how the attribute is to be obtained or if there are, say, any performance requirements. Often, such requirements are only employed by highly experienced software engineers knowl- edgeable in a particular application domain. I have often seen student project proposals where a software system is promised to be “user-friendly,” a term that always indicates little knowledge of human–computer interaction. For which class of users is the system to be user-friendly? Is “user-friendly” the opposite of “user-nasty”? We will not discuss non- functional requirements any further in this book.

The end result of vague requirements are software systems that either do not quite work as the customer wanted or do not work at all, often because the interfaces with other soft- ware were not properly specified. Vague requirements may lead to problems that cannot be solved on technical grounds and, therefore, must be resolved in the legal system. Having software problems resolved in court means that a jury of relatively nontechnical people has to determine the precise meaning of requirements that were too vague to be understood by the technical software people involved. This is hardly an appealing scenario.

In fact, the problem is more serious than meets the eye. The cheapest time to correct errors in software is in the requirements development phase (see Table 3.2 later). This is true regardless of the model of development: classical waterfall, rapid prototyping, spi- ral, or other. On the other hand, the most expensive time to correct problems in software is during the maintenance phase, because all previous life cycle activities (requirements, design, coding, testing, integration, documentation, delivery, and installation) have been performed. Software maintenance also requires a high level of understanding of the code. We will fully discuss software maintenance in Chapter 8.

You might think that using an iterative software development approach might elimi- nate most of these problems. It is true that the iterative models allow incomplete require- ments to be discovered earlier than in the classical waterfall model. Inconsistent, or wrong, requirements tend to be discovered earlier with the iterative methods.

However, vague requirements may not be discovered unless the various evaluation reviews are done carefully. Without healthy skepticism at reviews, the vague requirements are still likely to become part of the project’s culture, with the vagueness never being resolved.

An important study by Dolores Wallace of the National Institute of Science and Tech- nology (NIST) and Herbert Hecht and Myron Hecht of SoHar Corporation in California shows that there is a pyramid effect due to the nature of errors in software systems (Hecht et al., 1997). They examined a large number of projects and classified the errors according to the life cycle phase in which the errors occurred. An informal summary of their results is shown in Table 3.1. Clearly, many errors occur during the requirements phase.

How important is it to discover errors or inconsistencies at requirements time? There are many studies that consider the cost of fixing a software problem at different phases of the software life cycle. The results of one (proprietary) study are shown in Table 3.2. Note the huge advantage to finding errors early in the software life cycle, during the requirements phase.

It should be clear that accurate determination of a software system’s requirements is essential. Even in an agile process, or indeed any iterative software development process,

requirements must be determined eventually, and the more accurate and complete the ini- tial requirements are, the fewer and less costly the iterations will be. We will discuss some techniques for the determination of requirements in an efficient manner.

Of course, many projects will have their requirements change over time due to changes in technology and new directions for the organization. This is especially true of larger projects, which might have their development times extend over several years. An initial set of high-quality, modular requirements and an effective software development process can support incorporation of changes in a systematic, efficient manner.

What about agile processes? I believe that the most important advantage of an agile process is that well-chosen project teams whose members have considerable experience in developing software in a particular application domain have an intuitive feel for what detailed requirements arise from a higher-level requirement. As such, they can shorten the development process by shortening the requirements process, because they can precisely determine the large-scale components and subsystems that can be used in the desired sys- tem. The constant improvement of prototypes reduces the risk of the informality of agile processes. You will see this during the continuing description of a case study of an agile software development process throughout this book.

It has been my experience that without this essential application domain expertise, agile processes can lead to disaster in critical projects and are best left to back-burner efforts whose failure will not be catastrophic to the organization. The literature suggests that agile processes should not be used for applications in which security is essential. See the 2013 article by Carol Woody of the Software Engineering Institute (Woody, 2013) for a more detailed discussion of this issue.