From: Adriano Comai (comai@analisi-disegno.com)
Date: Tue Dec 31 2002 - 19:01:49 EST
Ian,
do you suggest the meaning, and the primary goal, of "requirements engineering" is "to engineer a specification"?
If so, what about "agile" processes (e.g. extreme programming, Scrum)? There isn't a real "specification" (in XP, there are only customer-defined acceptance tests). Yet requirements are _managed_.
My point: "requirements management", the management of expectations in a relationship between customers and developers, encompasses "requirements engineering".
Adriano Comai
http://www.analisi-disegno.com
> -----Messaggio originale-----
> Da: Ian F Alexander [mailto:iany@easynet.co.uk]
> Inviato: luned́ 30 dicembre 2002 11.41
> A: Adriano Comai
> Cc: RE-online@it.uts.edu.au
> Oggetto: Re: [re-online] Requirements Engineering - Fuzzy
>
>
> Adriano,
>
> I think I'm with Donald here; the terms in use aren't too good
> but they are
> what we have, and we find them of some use.
>
> The fuzziness in what we are doing is our starting-point: the
> vaguely-expressed or vaguely-tacit needs of people. But we are
> engineering a
> quite definite end-product - the specifications for code or motor cars or
> whatever. So our 'engineering' is a special kind: it consists of the
> defuzzification (!) of the inputs to produce a good solid output.
>
> The task is difficult, and we may never succeed perfectly, but I suggest
> that all engineering consists in replacing vagueness with a definite
> solution. We just have rather more of the stuff than is usual in other
> branches of engineering (and until recently, we were pretty vague
> ourselves
> about the definiteness of the output).
>
> Ian
>
> ----- Original Message -----
> From: "Adriano Comai" <comai@analisi-disegno.com>
> Sent: Sunday, December 22, 2002 4:55 PM
>
> >My problem is with the locution "requirements engineering".
> >It's difficult to "engineer" a fuzzy thing.
>
>
>
>
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:49 EST