From: Dale C. Maley (dmaley@route24.net)
Date: Mon Dec 23 2002 - 02:55:12 EST
When I write requirements, I use the Ivy Hooks
technique.............each requirement must have a rationale and each
requirement must have a verification method.
So, any needs of the business that cause a requirement to be written...........would have a requirement written with the rationale listing that particular business need..........and then a method of verifying the requirement is met. If there are multiple business needs, then of course this will drive multiple requirements.
For example, one of my business needs is to have systems meet OSHA noise
limits..........so specification might be "System shall comply with OSHA noise limits.........Rationale is business must comply with OSHA.........Verification would be to measure sound generated 3 ft inall directions from any equipment in the system must be less than 85 dBa using a calibrated hand held sound meter.
Having a rationale and verification method for each specification has
proven to be very effective for us. We have been able to capture the
"expert knowledge" of several key engineers and apply their knowledge to
every project. Because we have captured the rationale..........we can
train new engineers by having them review specs/rationale for previous
similar projects.
Our suppliers like this method because they understand why we want the
specification and how we are going to verify them.
Dale Maley
Envelope-to: dmaley@route24.net
Received: from mail by pop3.Route24.net with spam-scanned (Exim 3.12 #1 (Debian))
id 18PvmK-0001aY-00 for <dmaley@route24.net>; Sat, 21 Dec 2002 20:23:44 -0600 Received: from ns1.route24.net ([65.199.64.2]) by pop3.Route24.net with smtp (Exim 3.12 #1 (Debian)) id 18PvmK-0001aL-00 for <dmaley@route24.net>; Sat, 21 Dec 2002 20:23:44 -0600Received: from marcie.it.uts.edu.au ([138.25.9.4]) by ns1.route24.net (NAVGW 2.5.2.12) with SMTP id M2002122120295927527 for <dmaley@route24.net>; Sat, 21 Dec 2002 20:29:59 -0600 Received: (from majordom@localhost)
by marcie.it.uts.edu.au (8.9.1a/8.9.3) id KAA28086 for re-online-outgoing; Sun, 22 Dec 2002 10:32:45 +1100 (EST) Received: from hotmail.com (f87.law15.hotmail.com [64.4.23.87]) by marcie.it.uts.edu.au (8.9.1a/8.9.3) with ESMTP id BAA05647 for <RE-online@it.uts.EDU.AU>; Sat, 21 Dec 2002 01:11:12 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Dec 2002 06:10:04 -0800 Received: from 172.151.134.90 by lw15fd.law15.hotmail.msn.com with HTTP; Fri, 20 Dec 2002 14:10:04 GMT
X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: X-Mozilla-Status2: 00000000
Doug Anderson wrote:
"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?"
This is an interesting problem, and the traditional solutions have not been very effective. You are right that the same business need can drive multiple requirements and a record of this need (I have traditionally had a business justification part) is useful for numerous reasons. However, as time has gone on, I have come to understand that each requirement has an associated set of attributes (metadata) that is too large to document with the requirements on paper (you lose track of the forest for the trees as the actual requirements get drowned out by their attributes) and yet too important to ignore. I have come to the conclusion that the only practical approach is to use a requirements tool with a fine-grained object-oriented database (e.g., Caliber-RM, Doors) that allows one to store each need and each requirement as a separate object, each with its associated attributes and links to other repository objects. You can then provide multiple views of these requirements (the good old model/view model) to different audiences with different needs and use the requirements metadata to manage the requirements, support the creation of these views (e.g., different requirements specifications with different contents and levels of detail) on demand, support ad hoc queries, and publish/subscribe notifications with requirements change as they always do in an iterative, incremental, parallel development cycle.
By the way, this is the subject matter of my March/April Requirements Engineering column in the Journal of Object Technology (JOT).
Donald Firesmith
Firesmith Consulting
Affordable Consulting and Training in:
- Process Engineering
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:49 EST