From: Donald Firesmith (donald_firesmith@hotmail.com)
Date: Wed Dec 18 2002 - 03:41:06 EST
Dale Maley raises some good reasons for including designs in with the
requirements when contracting out (or using subcontractors for that matter).
I would argue that specifying external interfaces is quite legitimate requirements specification and should be included with functional requirements, data requirements, quality requirements, and constraints.
I would also argue that there are many reasons to specify architectural, design, implementation, and testing constraints. I would however clearly identify them as constraints in the requirements specification and provide a business justification for each one. Then, the supplier can counter propose a different, potentially better solution that may work if the customer has inappropriately specified the constraint (e.g., because the customer doesn't understand the differences between requirements and design, because the customer assumes that there is only one way to solve the problem).
Donald Firesmith
Firesmith Consulting
Affordable Consulting and Training in:
- Process Engineering - Requirements Engineering - System and Software Architecture - Object-Oriented Design - Object-Oriented Testing
>From: "Dale C. Maley" <dmaley@route24.net>
>Reply-To: dmaley@route24.net
>To: "re-online@it.uts.EDU.AU" <re-online@it.uts.EDU.AU>
>Subject: [Fwd: [re-online] Requirements & Design]
>Date: Mon, 16 Dec 2002 11:11:58 -0600
>
>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
>
><< message3.txt >>
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:48 EST