From: Anderson, Douglas W. (Anderson.Douglas@MAYO.EDU)
Date: Fri Dec 20 2002 - 04:36:11 EST
Don,
Your definition of a requirement certainly works for me. I appreciate its "grounding" of requirements in the real world. Also, the focus on capability nicely defines the space between the stakeholder's "need" or "want" and whatever solution may be designed and implemented.
Presumably a business need that drives a requirement for a capability ought to be captured as background for the requirement. I'm interested to know whether re-online listmembers typically make capture of this "need" a part of the structural design of their requirements specification? If so, (where it is explicitly known) is it usually in a separate section cross-referenced with the resulting requirements, or is it a separate component within the statement of each requirement? I imagine a single business need may drive multiple requirements, suggesting the former approach. What's the most practical way of both capturing the needs and making them traceable?
Thanks for great discussions & insights on this list!
Doug Anderson
Mayo Clinic
Rochester, MN USA
Opinions expressed are necessarily mine, not necessarily those of the Mayo Foundation.
> ----------
> From: Don Mills
> Sent: Tuesday, December 17, 2002 7:23 PM
> To: RE-online@it.uts.EDU.AU
> Subject: Re: [re-online] Requirements & Design
>
> At 12:44 17/12/02 +1030, Andrew Gabb wrote:
>
> -----<snip>-----
> >Firstly I'll give my definition of 'requirement': 'an expression of
> >a perceived need that something be accomplished or realised'.
> >Rationale for this carefully constructed definition, and some notes
> >on the deficiencies in other definitions, is provided in the paper
> >'Requirements Categorization' at http://www.incose.org/rwg/. For
> >those who want it easy, I'll post the rationale here if asked.
> >
> >So anything which intentionally constrains the design and shapes the
> >product (or service) is a requirement.
> -----<snip to end>-----
>
> Thanks, Andrew; my wife and I are trying to recover the state of our house
> following a kitchen fire, so I'll defer reading your paper until later
> (leaving your email in my In Tray to remind me!). Some comments now, however:
>
> My preference would be to constrain the term (capitalised if necessary) to
> the realm of "real world" problems. And my preference would be to solve
> *real* problems rather than *supposed* problems.
>
> Here's the definition of "requirement" I've evolved for a course I'm
> working on:
>
> "A real-world capability needed by some defined stakeholder or set of
> stakeholders, or a real-world constraint over the provision or operation of
> such a capability."
>
> I stipulate that we must know who has the problem, and who has an interest
> in it and/or in any solution (stakeholders), but I don't stipulate that the
> problem element we call a requirement must be expressed, or even
> known. Your definition, I think, is more the definition of the term,
> "requirement statement" (or some such).
>
> Of course, if a requirement *isn't* expressed, it may not be satisfied, but
> that doesn't make it any less of a real requirement. The "concrete
> lifejacket" comes to mind -- you know, "Look, it's yellow, okay? It's got
> a flashing light, it's got a whistle, it's got straps for putting it
> on. That's everything you asked for -- what more do you want?
> ... Oh! You didn't tell me it was supposed to *float*!"
>
> In my proposal for the course I'm working on, I've written:
>
> "The role of RE is to identify, define, and control the problem space ('the
> requirements'), and thereby to *constrain* (but not define) the solution
> space. Identification, definition, and control of the solution are the
> role of Product Engineering ('the design')"
>
> -- though I'd hasten to add that RE has an ongoing role in ensuring the
> preservation and management of requirements as they relate to a delivered
> product, and of course a more active role where a delivered product
> undergoes revision with new or changed requirements.
>
> What do the list members think?
>
> Regards,
>
> -- Don
> ______________________________
> Don Mills
> Senior Consultant
> Software Education Associates Ltd
> Wellington,
> New Zealand.
> ______________________________
>
>
> ============================================================
> This message has BYPASSED the Software Education Spam Filter
> It is from a subscribed newsgroup.
>
> No content checking was done on this email
>
>
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:49 EST