Objectives


Objectives

  • Readers will conceive of the customer as part of the human aspect of software development.

  • Readers will increase their awareness with respect to the fact that requirements change during the process of software development.

  • Readers will be familiar with data-gathering tools that may help them in formulating customers requirements.

  • Readers will be familiar with the concept of requirements management and tools that may support this process.



Study Questions

  1. Why do we write software? What are the purposes of code writing?

  2. What human beings needs do software systems serve?

  3. What software projects would you consider successes? Failures?

  4. In your opinion, what percentage of software products succeeds? Fails?

  5. According to [Mullet99], three quarters of all large software products delivered to the customer are failures. Sometimes they are not used at all; in other cases, they do not meet the customer s requirements. How would you explain this phenomenon ? Where do the problems lie?

  6. Based on Chapter 2, how do different software development methods attempt to develop software systems that fit customers needs?



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.