Testing requirements | 29
the definition of the solution evolves a solution by dictating requirements
you should continuously validate the usually ends up with everyone less
"concept" of the solution with the than satisfied.
stakeholders. There are a variety of techniques
- Third, this continuous validation can't to breaking through the initial
occur if you are heads-down writing requirements posed by the users,
Studies have shown that up
requirements documents. You need to but they all centre on focusing
to 50 percent of consumer
capture the ideas simply and succinctly on uncovering the needs of the
electronics product returns
and communicate them frequently. stakeholders and not, at least initially,
are due to complexity -
An old adage to remember is that soliciting requirements from them.
users don't know what they want, but Eventually you will uncover
users could not figure out
they know what they don't want when requirements, and as you do you need
how to use the products
they see it. This means that you will to relate them directly back to needs; (but presumably wanted
probably have to develop a number of if the connection to needs is weak then
the functionality that the
different prototypes to walk-through eliminate the requirement - it's either
various aspects of the system in order not needed (or there is a need that you
product provided). The
to make sure that you are building the are not clear about).
important thing about this
right solution. A final problem can occur that is that significant effort
Other sources for errors is a kind of ‘error of conception’:
was expended to create the
of conception relate to poor sometimes the problem to be solved
capabilities that people
understanding of the needs of the or the needs are clear, but it's just
business (or sponsoring organisation not a problem that is worth solving.
were unable to use, or
if the solution is being developed This situation occurs when the cost perhaps did not even want.
for a not-for-profit organisation or of developing a solution outweighs
government agency), which really the benefits, or the solution is simply
means the needs of the stakeholders technically infeasible.
for the project. By this I mean going It's best to figure this out early,
beyond what they say they need and and so focussing early on identifying
uncovering the real needs that often needs and then exploring the cost
lie hidden. and technical feasibility of solutions
An example from another domain through one or more prototypes is the
illustrates the difference: A patient best way to figure this out quickly.
walks into a doctor's office saying
that he needs to get a prescription Disambiguation
for painkillers. When the doctor asks Errors of conception are the most
why, the patient complains of severe significant kind of requirement errors,
headaches, but insists that it's no big and they are the hardest to detect,
deal, he just needs to get something but avoiding them has the greatest
to dull the pain and he doesn't need benefit. By preventing them you
more tests or treatments. Against ensure that the solution will better
these protestations the doctor insists meet the real needs of stakeholders;
on more tests and eventually finds failing to prevent them, no amount
that the patient has an operable but of ‘disambiguation’ of requirements
benign tumour. After the operation, language will yield a good result.
the patient's headaches disappear No amount of precision can help a
completely and he makes a speedy requirement that specifies the wrong
recovery. behaviour. In this first article in a
In this example, giving the patient two-part series, I have covered the
what he is asking for is exactly the ‘errors of conception’, which relate to
wrong course of treatment. Similarly, if requirements errors that arise from
you give your users exactly what they problems with the basic conception
ask for you may simply be treating the of the solution. In the next issue I will
symptoms of a problem and fail to find discuss ‘errors of specification’, which
a better solution to the real problem relate to errors in how the requirement
at hand. Users are not very good at is expressed, as well as ‘errors of
coming up with solutions to their implementation’, which arise from
Kurt Bittner
Chief Technology Officer
problems – that's where you can add problems in how the requirements
Ivar Jacobsen International
www.ivarjacobson.com
real value – and letting them ‘dictate’ are implemented.
www.testmagazineonline.com September 09 | T.E.S.T
Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52