From: Dale C. Maley (dmaley@route24.net)
Date: Tue Dec 17 2002 - 04:11:58 EST
I generally agree with Don's reply....particularly the issue about a
sequential process making 1 process's output the next process's inputs.
I specify, purchase, and implement manufacturing systems which include software and hardware. In the past, we would only specify a big input-output box for our system.....give no specs on key interfaces the new system must make with existing systems.....and give no design standards.
As you would predict, nobody was happy with these systems. Each system took too long for start-up, each system had different operator interfaces and maintenance requirements, and key interfaces with outside existing systems was a nightmare.
In many cases, we knew how to design key elements of the system......but we did not tell the supplier how to design it...and almost bankrupted the supplier(s).
Our new approach is working much better and includes:
-Developing a computer architecture/software standard specification for
all new systems
-Specify how key subsystems must be designed based upon our experience.
-Specify all key interfaces with outside existing systems
Based upon our learing experience, we have to dig deep into the Design side.....and include Design specs for our suppliers if our projects are going to succeed.
One should realize the pros and cons of including Design specs in the over-all system Requirements.....then include the proper amount of design specs based upon the situation/application/industry.
Dale Maley
Envelope-to: dmaley@route24.net
Received: from mail by pop3.Route24.net with spam-scanned (Exim 3.12 #1 (Debian))
id 18NxRK-0004V2-00 for <dmaley@route24.net>; Mon, 16 Dec 2002 09:45:55 -0600 Received: from ns1.route24.net ([65.199.64.2]) by pop3.Route24.net with smtp (Exim 3.12 #1 (Debian)) id 18NxRK-0004Uf-00 for <dmaley@route24.net>; Mon, 16 Dec 2002 09:45:54 -0600Received: from marcie.it.uts.edu.au ([138.25.9.4]) by ns1.route24.net (NAVGW 2.5.2.12) with SMTP id M2002121609513316151 for <dmaley@route24.net>; Mon, 16 Dec 2002 09:51:37 -0600 Received: (from majordom@localhost)
by marcie.it.uts.edu.au (8.9.1a/8.9.3) id XAA08905 for re-online-outgoing; Mon, 16 Dec 2002 23:51:31 +1100 (EST) Received: from softed.com (210-54-118-66.adsl.xtra.co.nz [210.54.118.66]) by marcie.it.uts.edu.au (8.9.1a/8.9.3) with ESMTP id TAA24044 for <RE-online@it.uts.edu.au>; Mon, 16 Dec 2002 19:09:12 +1100 (EST) Received: from don.SoftEd.com ([210.86.37.195]) by softed.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.5.1.R) for <RE-online@it.uts.edu.au>; Mon, 16 Dec 2002 20:59:26 +1300Message-Id: <5.1.0.14.0.20021216210806.0255bbd0@210.54.118.66> X-Sender: DonM@210.54.118.66
X-Authenticated-Sender: DonM@softed.com X-MDRemoteIP: 210.86.37.195 X-Return-Path: DonM@SoftEd.com X-MDaemon-Deliver-To: RE-online@it.uts.edu.auSender: owner-re-online@it.uts.EDU.AU
X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: X-Mozilla-Status2: 00000000
--=======4C6620FF=======
Content-Type: text/plain; x-avg-checked=avg-ok-60403AE8; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
With apologies ... I accidentally sent the following to Tere (at 15:40 on=
=20
the 15th), instead of to the list!
A question regarding what I wrote: What, in the opinion of the list=20 members, is the domain of Requirements? Is it restricted to the customer=20 (business) domain, or does it make sense to regard design features as=20 "requirements"?
At 16:53 13/12/02 -0600, Tere Ventura wrote:
-----<snip>-----
>We are trying to improvement some process, and we want have a process
>called "Requirements Engineering". The question is:
>
>=BFDesign process is part of Requierement Design . Design =3D software
>requirements? =BFDesign process is part of Development Process (logic
>part)? or =BFDesign is other process?
-----<end>-----
Tere, undoubtedly others more experienced than myself will wish to offer=20 answers, but I seem to be getting in first.
The distinctions between requirements and design are somewhat conventional,=
=20
but the first point to notice is this: "Requirements" are about "the=20
problem"; "Design" is about "the solution".
That said, it's also true that, in an assembly-line sort of process, one=20
person's design is the next persons requirement. A Requirements Engineer=20
analyses the details of the problem, and states them in a "Requirements=20
Document" (which should itself be the product of a design process). The=20
"Design Engineer" is "required" to design a conforming product, and states=
=20
the design details in a "Product Specification Document". A "Development=20
Engineer" is "required" to create the solution product as specified (that's=
=20
the theory!), but note that, to the "Development Engineer", the design=20
details are "requirements" ("things called for or demanded; conditions=20
which must be complied with", according to the New Shorter Oxford English=20
Dictionary).
For this reason, you will sometimes encounter terms such as "Customer=20
Requirements" (or "Business Requirements": statements that define the=20
original problem domain), "Software Requirements" (or "System Requirements"=
=20
or "Product Requirements": statements that shift the problem domain from=20
the business field to the product development field), "User Requirements"=20
(or "use cases": statements that define the required interaction between=20
the solution product and its intended users); and "Design Requirements"=20
(statements of designed features that must be incorporated into the=20
solution product). There are also "Test Requirements" (factors that must=20
be incorporated into the design and construction of testware products).
For myself, I think it's safest to constrain the term "Requirement"=20 (capital "R") to the customer's problem domain, and the term "Design"=20 (capital "D") to the development team's product domain. We can then use=20 lower-case terms more generically, such as "the RE's design of the=20 Requirements Document", or "the engineering requirements contained within=20 the Product Design Document".
To recap: "Requirements" are about a Problem, "Design" is about a Solution;=
=20
but besides "The Customer Problem" and "The Systems Solution", there are=20
miniature problems-and-solutions all the way down the line.
Regards,
No content checking was done on this email
--=======4C6620FF=======--
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:48 EST