From: Rolf.Goetz@sophist.de
Date: Fri Feb 27 2004 - 21:22:23 EST
Hello,
I'd like to add another aspect.
Going up and down through the levels and adding information is a way to
*validate* requirements.
I know there are a lot of different meanings of "validation", ask 3
analysts and get 5 answers, so here's mine:
Valid is related to the words significant and effectual. Validated
requirements are the "real" requirements. By deriving level n requirements
from a level n-1 requirement, we think about it again, and we add a
different perspectives. A perspective might be:
How does this requirement translate to my system architecture? or
What has to be done to make it unambiguous and testable? or - going up the
hierarchy instead -
What is the reason for this requirement?
All the perspectives help to see if a requirement is valid. So in order to validate requirements, one might structure them in different abstraction levels. The result is different levels for different purposes.
Cheers
Rolf Goetz
SOPHIST GROUP
owner-re-online@it.uts.edu.au wrote on 26.02.2004 12:38:50:
> Hello all,
> I'm wary when I hear the term High level requirement because it often
means
> - we know we have some requirements to do with this subject but we're not
> sure what they are. The "High Level" requirement is usually a springboard
> for discovering requirements that can be quantified well enough to be
> unambiguous and testable.
> Once you have defined the unambiguous, testable requirements then the
> question is whether it will benefit you to maintain the high level
> requirements and to maintain a trace. In other words, the high level
> requirements are often a means to an end.
> If you have a rationale for each of the measurable requirements then this
> quite often satisfies of your need for tracing. It helps to answer the
> question - why is this a requirement and where did it come from.
> Another useful trace is to be able to connect each requirement to all the
> chunks of product to which it applies. If you are using use cases to
chunk
> your product, then it makes sense to be able to trace each measurable
> requirement to all the relevant use cases.
> If you wish to maintain more levels in your requirement hierarchy you
should
> have a reason and a benefit for each additional level that you choose to
> maintain.
> Regards
> Suzanne
>
> > Hello,
> >
> > I am investigating aspects of abstraction level of requirements, i.e.
on
> > what level a requirement can/should be specified regarding the aim of
the
> > requirement. Aim could be e.g. who uses the req. and for what
purpose...
> > Example:
> > High level -> "...open standards should be supported"
> > ...
> > Lower level -> "...the application should be compliant to USB2.0"
> >
> >
> > I wonder if there has been any research regarding this aspect, as well
as
> > the mapping of the high-low level requirements to each other, and to
> > company/product strategies.
> >
> > Would appreciate any tips, references and links.
> >
> > Best regards,
> >
> >
> > Tony B. Gorschek
> > PhD Student in Software Engineering
> >
> > ________________________________________________
> >
> > Blekinge Institute of Technology
> > School of Engineering
> > PO Box 520, SE-372 25 Ronneby Sweden
> >
> > direct : +46 457-38 58 17
> > mobile : +46 708-25 46 92
> > phone : +46 457-38 50 00
> > fax : +46 457-271 25
> > e-mail : tony.gorschek@bth.se, tgo@bth.se
> > url : www.bth.se/ipd and http://194.47.142.27
> >
> >
> >
> >
> >
>
------------------------------------------------------------------------------>
> -
> > To send a message to this mailing list send it to
re-online@it.uts.edu.au.
> > To unsubscribe from this mailing list, email majordomo@it.uts.edu.
> au with the
> > message `unsubscribe re-online' in the BODY of the mail.
> ==============================================================
> Our new seminar ³Extended Requirements Workshop² is will be held in
London
> March 22-23, 2004.
> The seminar, a follow on from our requirements skills workshop, is about
how
> to link project success factors to effective requirements practices and
how
> to get business value from requirements. See our web site for further
> details http://www.systemsguild.com
>
> Suzanne Robertson The Atlantic Systems Guild Ltd.
> 11 St. Mary's Terrace London
> W2 1SU UK
> mail: suzanne@systemsguild.com
> phone: +44(0)20 7262 3395
> http://www.systemsguild.com
>
> Mastering the Requirements Process by Suzanne and James Robertson
> foreword by Jerry Weinberg - published by Addison-Wesley
> http://www.amazon.com/exec/obidos/ASIN/0201360462/theatlanticsyste?
> ==============================================================
>
> To send a message to this mailing list send it to
re-online@it.uts.edu.au.
> To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with
the
> message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Mar 01 2004 - 09:00:16 EST