|
Guys The requirement versus specification problem
is all about call and response. A requirement define the call,
the expressed desires, wants and wishes whereas the specifications define the
(high level) response to those desires et al.
It is part of a process, a flow of understanding and communication and is
always iterative. In theory at least. In practice users mostly think solution
space and typically solutions close to where they currently are and with what
they currently have. This is extremely frustrating but inevitable. Business
analysts are typically tasked with defining the requirements and articulating a
first pass solution (specification) which may or may not bear any resemblance to
the final solution. We often use the wrong people in the wrong place in the
process to effect a transformation that is often ill-defined and even less
understood. I personally
have found the Volere requirements management approach (http://www.volere.co.uk/) extremely useful
is defining a process that starts to put the call and response in some better
managed order. Because it is not software specific is has a generality that
appeals and its sub classifications as to the nature and rationale for a
requirement (wish) provoke discussion and contemplation. However, it is not a
panacea and often there is a need to educate clients and the delivery team in
the art and science of requirements engineering. Sad, really,
but then this is not a problem confined to the software world. Carl From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacques Carette Ruven mentionned a number of
fascinating topics (well worth researching) in PoSE, but one in particular drew
my attention: There *ought* to be a separation, but
there seems to be a huge amount of confusion there. Any research
that could shed light on how to get people to separate goals version the
written version of these goals, as well as cleanly separating statements
about the problem domain versus statements about the solution domain (ie a
clean separation between requirements and design) would be fantastic. A frequent disease of many requirements
documents is talking in terms of the solution space instead of talking clearly
in the problem space. This leads to all sorts of premature design
decisions that are quite costly to revert later. Of course, as Parnas as
cogently argued some years back [1], it seems impossible for people to think in terms of problem
space, so that one must 'fake it'. Getting some real data on this would
be really good. Jacques [1] "A Rational Design Process: How
and Why to Fake it", IEEE Transactions on Software Engineering, Vol.
SE-12, no. 2, Feburary 1986, pp. 251-257) |
|
|
