From: Adriano Comai (comai@analisi-disegno.com)
Date: Sat Dec 21 2002 - 06:08:02 EST
Yes. Anyway, in your perspective, the lifecycle of "constraints" (i.e.
"requirements"), which could be modeled with a state-transition diagram,
seems to be determined mainly by the characteristics of the "rational
negotiation process". In other words, there are (it seems to me) as many
possible "requirements lifecycles" as the number of possible "negotiation
processes".
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 SQEGelp@aol.com
Inviato: giovedi 19 dicembre 2002 21.05
A: re-online@it.uts.edu.au
Oggetto: [re-online] Requirements Definition
Here is a different perspective based on a non-standard use of "constraint". I would appreciate comments.
Begin Perspective
A "requirement" is not a thing, but the name of a time-sensitive state.
The fundamental "thing" is a product, project, or service-level constraint. Constraints are in states such as <proposed, <preferred, required>, satisfied, rescheduled, delayed, dropped>.
Constraints are required during a time interval based on economic or political power or the results of a rational negotiation process.
In an ever changing world, a required constraint may revert to proposed, or be rescheduled, delayed, or dropped due to new information. A satisfied constraint in one software release may be dropped in the next.
End Perspective
David Gelperin
LiveSpecs Software
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:49 EST