We want to be sure that the requirements specification contains all the
requirements that are known about. While we know that there will be evolutionary
changes and additions, we would like to restrict those changes to new
requirements, and not have to play "catch-up" with requirements that we should
have known about in the first place. Thus we want to avoid omitting requirements
just because we did not think of asking the right questions. If we have set a
context for our project, then we can test whether the context is
accurate. We can also test whether we have considered all the likely
requirements within that context.
The context defines the problem that we are trying to solve. The context
includes all the requirements that we must eventually meet: it contains anything
that we have to build, or anything we have to change. Naturally if our software
is going to change the way people do their jobs, then those jobs must be within
the context of study. The most common defect is to limit the context to the part
of the system that will be eventually automated. The result of this
restricted view is that nobody correctly understands the organisation's culture
and way of working. Consequently there is misfit between the eventual computer
system and the rest of the business system and the people that it is intended to
help.
Requirements Test 4
Is the context of the requirements wide
enough to cover everything we need to understand?
Of course this is easy to say, but we still have to be able to test whether
or not the context is large enough to include the complete business system, not
just the software. ("Business" in this sense should be means not just a
commercial business, but whatever activity - scientific, engineering, artistic -
the organisation is doing.) We do this test by observing the questions asked by
the systems analysts: Are they considering the parts of the system that will be
external to the software? Are questions being asked that relate to people or
systems that are shown as being outside the context? Are any of the interfaces
around the boundary of the context being changed?
Another test for completeness is to question whether we have captured all the
requirements that are currently known. The obstacle is that our source of
requirements is people. And every person views the world differently according
to his own job and his own idea of what is important, or what is wrong with the
current system. It helps to consider the types of requirements that we are
searching for:
Conscious Requirements
Problems that the new system must solve
Unconscious Requirements
Already solved by the current system
Undreamed of Requirements
Would be a requirement if we knew it was possible or could imagine it
Conscious requirements are easier to discover because they are uppermost in
the stakeholders' minds. Unconscious requirements are more difficult to
discover. If a problem is already satisfactorily solved by the current system
then it is less likely for it to be mentioned as a requirement for a new system.
Other unconscious requirements are often those relating to legal, governmental
and cultural issues. Undreamt of requirements are even more difficult to
discover. These are the ones that surface after the new system has been in use
for a while. "I didn't know that it was possible otherwise I would have asked
for it."
Requirements Test 5
Have we asked the stakeholders about
conscious, unconscious and undreamed of requirements?
Requirements engineering experience with other systems helps to discover
missing requirements. The idea is to compare your current requirements
specification with specifications for similar systems. For instance, suppose
that a previous specification has a requirement related to the risk of damage to
property. It makes sense to ask whether our current system has any requirements
of that type, or anything similar. It is quite possible, indeed quite probable,
to discover unconscious and undreamed of requirements by looking at other
specification.
We have distilled experience from many projects and built a generic
requirements template that can be used to test for missing requirement
types. I urge you to look through the template and use it to stimulate questions
about requirements that otherwise would have been missed. Similarly, you can
build your own template by distilling your own requirements specifications, and
thus uncover most of the questions that need to be asked.
Another aid in discovering unconscious and undreamed of requirements is to
build models and prototypes to show people different views of the requirements.
Most important of all is to remember that each stakeholder is an individual
person. Human communication skills are the best aid to complete requirements.
Requirements Test 5
(enlarged)
Have we asked the stakeholders about
conscious, unconscious and undreamed of requirements? Can you show that a
modelling effort has taken place to discover the unconscious requirements?
Can you demonstrate that brainstorming or similar efforts taken place to
find the undreamed of requirements?
