Page 128 -

4.7 Requirements management 111

Initial Changed
Understanding Understanding
of Problem of Problem

Initial Changed
Figure 4.17 Requirements Requirements
Requirements
evolution Time

There are a number of requirements validation techniques that can be used
individually or in conjunction with one another:

1. Requirements reviews The requirements are analyzed systematically by a team
of reviewers who check for errors and inconsistencies.
2. Prototyping In this approach to validation, an executable model of the system in
question is demonstrated to end-users and customers. They can experiment with
this model to see if it meets their real needs.

3. Test-case generation Requirements should be testable. If the tests for the
requirements are devised as part of the validation process, this often reveals
requirements problems. If a test is difficult or impossible to design, this usually
means that the requirements will be difficult to implement and should be recon-
sidered. Developing tests from the user requirements before any code is written
is an integral part of extreme programming.

You should not underestimate the problems involved in requirements validation.
Ultimately, it is difficult to show that a set of requirements does in fact meet a user’s
needs. Users need to picture the system in operation and imagine how that system
would fit into their work. It is hard even for skilled computer professionals to per-
form this type of abstract analysis and harder still for system users. As a result, you
rarely find all requirements problems during the requirements validation process. It
is inevitable that there will be further requirements changes to correct omissions and
misunderstandings after the requirements document has been agreed upon.

4.7 Requirements management

The requirements for large software systems are always changing. One reason for this is
that these systems are usually developed to address ‘wicked’ problems—problems that
cannot be completely defined. Because the problem cannot be fully defined, the soft-
ware requirements are bound to be incomplete. During the software process, the stake-
holders’ understanding of the problem is constantly changing (Figure 4.17). The system
requirements must then also evolve to reflect this changed problem view.