The requirements specification must contain all the requirements that are to
be solved by our system. The specification should objectively specify everything
our system must do and the conditions under which it must perform. Management of
the number and complexity of the requirements is one part of the task.
The most challenging aspect of requirements gathering is communicating with
the people who are supplying the requirements. If we have a consistent way of
recording requirements we make it possible for the stakeholders to participate
in the requirements process. As soon as we make a requirement visible we can
start testing it. and asking the stakeholders detailed questions. We can apply a
variety of tests to ensure that each requirement is relevant, and that everyone
has the same understanding of its meaning. We can ask the stakeholders to define
the relative value of requirements. We can define a quality measure for each
requirement, and we can use that quality measure to test the eventual solutions.
Testing starts at the beginning of the project, not at the end of the coding.
We apply tests to assure the quality of the requirements. Then the later stages
of the project can concentrate on testing for good design and good code. The
advantages of this approach are that we minimise expensive rework by minimising
requirements-related defects that could have been discovered, or prevented,
early in the project's life.
