Relevance for Software Engineering

If you ask experienced software developers for the five most serious problems of software engineering, it is reasonable to assume that one of the problems would be requirements are changed. For example, Fairley and Willshire present a list of 10 problems and some antidotes for software projects. On that list, changing needs is the second item, and requirements creep is the seventh [Fairley and Willshire03]. Needless to say, a customer s conception of the developed application changes is independent of what software development method is used. Requirements change is a given fact in software development. Customers should not be blamed for changing their requirements. It is simply impossible to predict at the beginning of the software development process how the conception of the developed software system will be shaped.

When requirements are changed and the final product does not meet the customer s expectations, software developers may still claim that their development process is accomplished perfectly , in order to justify their creation. They can even be right. However, since software success is also measured according to how well it meets the customers requirements, if customers change their mind during the course of software development, changes should be made in the software. If the software is not used eventually because it does not fit customer s needs, it does not matter whether it was developed adequately according to some established software development method. One conclusion that can be drawn from this fact is that when you consider what software development method to follow, you should also check whether it supports changes and updating of requirements that are introduced during the development process.

This chapter attempts to increase readers awareness of the fact the requirements cannot be formulated formally and completely in advance. Some freedom for changing and updating should be provided. This chapter presents characteristics of tools that enable the management of these changes.

How to start the collection of the requirements in the first place? An answer to this question is presented in the first part of this chapter, which is dedicated to methods for data collection that can be used for defining software requirements.