From: Adriano Comai (comai@analisi-disegno.com)
Date: Sat Dec 21 2002 - 18:53:26 EST
Donald,
thank you for your answer. Does your illustrative state model come from the OPEN process?
> The above model also fits the traditional major tasks of requirements
> engineering:
> 1) Requirements Elicitation/Gathering/Definition
> 2) Requirements Analysis
> 3) Requirements Specification
> 4) Requirements Management
It seems to me that, if there is no consensus about a lifecycle for requirements, it's very difficult to speak about a requirements "engineering" discipline.
But (another question) which are the main reasons for this absence of consensus about a lifecycle for requirements?
Adriano Comai
www.analisi-disegno.com
> -----Messaggio originale-----
> Da: Donald Firesmith [mailto:donald_firesmith@hotmail.com]
> Inviato: giovedì 19 dicembre 2002 18.54
> A: comai@analisi-disegno.com; re-online@it.uts.EDU.AU
> Oggetto: Re: [re-online] Lifecycle of requirements
>
>
> Adriano Comai wrote:
> >1) Is it possible to specify a state machine for requirements?
> >2) If yes, is there some consensus about a lifecycle for requirements?
> >3) If not, isn't "requirements" a very fuzzy word?
>
> I agree that requirements go through a state model, which is why
> status is
> one of the attributes (metadata) that should be recorded about each
> requirements in a requirements tool (repository).
>
> Requirements start out as raw, draft requirements.
> Then they are analyzed.
> Then they are approved.
> Then they are officially published (specified) to the rest of the
> organization.
> Then they are allocated to releases (milestones).
> Then they are allocated to teams/individuals for implementation.
> Then they are allocated to components (architecture, design,
> implementation)
> and test cases.
> Then they are implemented.
> Then they are tested.
> Then they are delivered/released.
> Then they are retired.
>
> The above sequence is not entirely linear, there is loop back due to
> iteration, there is potentially branches forward (e.g., some requirements
> may never end up prioritized high enough to be implemented before
> they are
> abandoned), and not all requirements pass through the state
> machine in lock
> step (unless you use the old waterfall development cycle). Thus,
> the state
> model is approximate and more illustrative rather than prescriptive.
>
> The above model also fits the traditional major tasks of requirements
> engineering:
> 1) Requirements Elicitation/Gathering/Definition
> 2) Requirements Analysis
> 3) Requirements Specification
> 4) Requirements Management
>
> Donald Firesmith
> Firesmith Consulting
> Affordable Consulting and Training in:
> - Process Engineering
> - Requirements Engineering
> - System and Software Architecture
> - Object-Oriented Design
> - Object-Oriented Testing
> http://www.donald-firesmith.com
>
>
>
>
>
> >From: "Adriano Comai" <comai@analisi-disegno.com>
> >To: "RE-online" <re-online@it.uts.EDU.AU>
> >Subject: [re-online] Lifecycle of requirements
> >Date: Wed, 18 Dec 2002 19:38:19 +0100
> >
> >I need your opinions.
> >
> >I appreciate, at a generic level, the definition of a requirement from
> >Incose: 'an expression of a perceived need that something be
> accomplished
> >or
> >realised'.
> >
> >But it seems to me that every requirement, and every "requirements set",
> >has
> >a story. It is expressed (set aside the fact that there are
> implicit ones,
> >too), analyzed, sometimes agreed upon in a contract, sometimes discarded
> >from the customer (if for example it conflicts with other, more
> important,
> >requirements), may be changed after an agreement, and so on.
> Maybe, at the
> >end, it is satisfied.
> >
> >My questions:
> >1) Is it possible to specify a state machine for requirements?
> >2) If yes, is there some consensus about a lifecycle for requirements?
> >3) If not, isn't "requirements" a very fuzzy word?
> >
> >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
> > >
> >[...]
> > > 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/.
> >[...]
> > > 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.
> > >
> > >
> >
> >
> >
> >-----------------------------------------------------------------
> --------------
> >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.
>
>
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
>
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:49 EST