When one of your stakeholders tells you he wants a graphic user interface and
a mouse, he is presenting you with a solution not a requirement. He has seen
other systems with graphic user interfaces, and he wants what he considers to be
the most up-to-date solution. Or perhaps he thinks that designing the system is
part of his role. Or maybe he has a real requirement that he has mentally solved
by use of a graphic interface. When solutions are mistaken for requirements then
the real requirement is often missed. Also the eventual solution is not as good
as it could be because the designer is not free to consider all possible ways of
meeting the requirements.
Does the specification contain
solutions posturing as requirements?
It is not always easy to tell the difference between a requirement and a
solution. Sometimes there is a piece of technology within the context and the
stakeholders have stated that the new system must use this technology. Things
like: "the new system must be written in COBOL because that is the only language
our programmers know", "the new system must use the existing warehouse layout
because we don't want to make structural changes" are really requirements
because they are genuine constraints that exist within the context of the
problem.
For each requirement ask "Why is this a requirement?" Is it there because of
a genuine constraint? Is it there because it is needed? Or is it the solution to
a perceived problem? If the "requirement" includes a piece of technology, and it
could be implemented by another technology, then unless the specified technology
is a genuine constraint, the "requirement" is really a solution.
