Page 127 -

110 Chapter 4 Requirements engineering

Requirements reviews

A requirements review is a process where a group of people from the system customer and the system
developer read the requirements document in detail and check for errors, anomalies, and inconsistencies. Once
these have been detected and recorded, it is then up to the customer and the developer to negotiate how the
identified problems should be solved.
http://www.SoftwareEngineering-9.com/Web/Requirements/Reviews.html

4.6 Requirements validation

Requirements validation is the process of checking that requirements actually define
the system that the customer really wants. It overlaps with analysis as it is concerned
with finding problems with the requirements. Requirements validation is important
because errors in a requirements document can lead to extensive rework costs when
these problems are discovered during development or after the system is in service.
The cost of fixing a requirements problem by making a system change is usually
much greater than repairing design or coding errors. The reason for this is that a
change to the requirements usually means that the system design and implementa-
tion must also be changed. Furthermore the system must then be re-tested.
During the requirements validation process, different types of checks should be
carried out on the requirements in the requirements document. These checks include:

1. Validity checks A user may think that a system is needed to perform certain func-
tions. However, further thought and analysis may identify additional or different
functions that are required. Systems have diverse stakeholders with different
needs and any set of requirements is inevitably a compromise across the stake-
holder community.
2. Consistency checks Requirements in the document should not conflict. That is,
there should not be contradictory constraints or different descriptions of the
same system function.

3. Completeness checks The requirements document should include requirements
that define all functions and the constraints intended by the system user.

4. Realism checks Using knowledge of existing technology, the requirements
should be checked to ensure that they can actually be implemented. These checks
should also take account of the budget and schedule for the system development.
5. Verifiability To reduce the potential for dispute between customer and contrac-
tor, system requirements should always be written so that they are verifiable.
This means that you should be able to write a set of tests that can demonstrate
that the delivered system meets each specified requirement.