From: Adriano Comai (comai@analisi-disegno.com)
Date: Wed Dec 18 2002 - 18:01:49 EST
Often there is a chain of customer-supplier relationships. A very simple
one:
Both in 1. and in 2. there are requirements on the left, and design on the right.
The same situation occurs when work (in an IT department or company) is further subdivided into a chain of different organization units. In some IT companies, one business unit (made of "Business Analysts") receives requirements from customers, then gives its own requirements (something more, and different, from those received from the business customer) to another business unit (made of "Developers").
Whenever I am asked to accomplish a new task (not a simple repetition of a previous one), I receive requirements, and I design a solution. Both when I'm asked from a business customer to make a new system, and when I'm asked from another technical group to realize a particular software module or component.
Requirements are a part of every work relationship, IMHO.
Adriano Comai
www.analisi-disegno.com
> -----Messaggio originale-----
> Da: owner-re-online@it.uts.edu.au
> [mailto:owner-re-online@it.uts.edu.au]Per conto di Andrew Gabb
> Inviato: martedi 17 dicembre 2002 3.15
> A: RE-online
> Oggetto: Re: [re-online] Requirements & Design
>
>
> Don Mills wrote:
> > A question regarding what I wrote: What, in the opinion of the list
> > members, is the domain of Requirements? Is it restricted to
> the customer
> > (business) domain, or does it make sense to regard design features as
> > "requirements"?
>
> This is a nasty question, Don, but one that needs an answer.
> Requirements may come from different domains. Product 'features' may
> be required, and hence requirements, but in my experience it's more
> common to refer to what is required as 'functions' and some of what
> is designed and delivered as 'features'.
>
> 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. That includes 'user
> requirements' and design constraints, which covers both your
> domains.
>
> Secondly, and more nastily, the systems engineering process consists
> of a number of 'decompositions' from system to subsystems to
> components in a form of hierarchy. (I put decomposition in quotes
> because the process is rarely complete top-down decomposition as
> such.) At each branch in this system breakdown we do design,
> resulting in requirements for the element below. So system design
> may include user interface design resulting in requirements for the
> components (hardware, software, service, process, whatever) below
> them.
>
> One final example. The requirement to use a 16 bit bus would not
> normally be a user (or business) requirement, but it could easily be
> a requirement that a hardware designer is working to, passed to him
> from the architect above him. By tracing that requirement back, we
> could find out how that requirement arose. It might be traceable to
> a user requirement, but not necessarily. It may be just the way this
> shop designs this type of equipment (a de facto design constraint).
> It's a requirement, none the less.
>
> Andrew
> --
> Andrew Gabb
> email: agabb@tpgi.com.au Adelaide, South Australia
> phone: +61 8 8342-1021, fax: +61 8 8269-3280
> -----
>
> ------------------------------------------------------------------
> -------------
> 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 : Fri Feb 21 2003 - 11:30:49 EST