From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Mon Nov 22 2004 - 16:12:17 EST
=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id 60B932127D
=09for <re-online@it.uts.edu.au>; Sun, 21 Nov 2004 18:26:46 +1100 (EST)
Received: from argon.dcs.kcl.ac.uk (argon.dcs.kcl.ac.uk [137.73.8.3])
=09by filter.it.uts.edu.au (Postfix) with ESMTP id 39F821D62C2
=09for <re-online@it.uts.edu.au>; Sun, 21 Nov 2004 18:26:40 +1100 (EST)
Received: from radon
=09([137.73.8.4] helo=3Dwebmail.dcs.kcl.ac.uk ident=3D5550)
=09by argon.dcs.kcl.ac.uk with esmtp (Exim 3.36 #1)
=09id 1CVm73-0000AP-00; Sun, 21 Nov 2004 07:26:21 +0000
Received: from 62.114.90.198
(SquirrelMail authenticated user elmaddah);
by webmail.dcs.kcl.ac.uk with HTTP;
Sun, 21 Nov 2004 07:26:21 -0000 (GMT)
Message-ID: <3495.62.114.90.198.1101021981.squirrel@62.114.90.198>
In-Reply-To: <3265.62.114.90.108.1100374637.squirrel@62.114.90.108>
References: <20041107150318.21503.qmail@web20222.mail.yahoo.com>
<4191109D.70807@tpgi.com.au>
<3265.62.114.90.108.1100374637.squirrel@62.114.90.108>
Date: Sun, 21 Nov 2004 07:26:21 -0000 (GMT)
Subject: Re: [re-online] Requirement Engineering
From: elmaddah@dcs.kcl.ac.uk
To: elmaddah@dcs.kcl.ac.uk
Cc: re-online@it.uts.edu.au
User-Agent: SquirrelMail/1.4.3a
X-Mailer: SquirrelMail/1.4.3a
MIME-Version: 1.0
Content-Type: text/plain;charset=3Diso-8859-1
Content-Transfer-Encoding: 8bit
X-MailScanner: Found to be clean
X-Spam-Status: No, hits=3D0.3 tagged_above=3D0.0 required=3D6.3 tests=3DNO_=
REAL_NAME
X-Spam-Level:
Sender: owner-re-online@it.uts.edu.au
Precedence: bulk
Reply-To: re-online@it.uts.edu.au
> Hello
>
> I think the completence issue concerns two situations:
>
> the easit one is when the client demands some requirements which are
> incomplete (having missing parts), so using some specification and
> formalisation activities, we can arrive at a requirements set that
> includes the missing cases in the client agenda. here, one can look at CS=
R
> and RSM, GOPCSD methods and their requirements treatment
>
> the second issue is when the client is not aware enough to consider the
> different needs intended from his/her application (e.g. missing security
> issue in a web-based application). the developer may be aware (but not
> willing to include such unmentioned requirements in the contract). in thi=
s
> case the requirements elicitaion and refinement are not enough to mine fo=
r
> the unstated requirements, some other techniques need to be targeted to
> encourge inventing requirements that can complete the initial stated ones=
=2E
> see [Robertson 02], [Robertson and Maiden 03], [El-Maddah 03]
>
> in relation to requirements stability, i would like to add a small note
> about it is closely related to the checks and validation applied on the
> intial requirements set, thus a checked requirements list will have less
> chance to be changed or modified compared with unchecked list, that can
> entail changes may be after implementing the application .
>
> kind regards
>
> Islam AM El-Maddah
> Ain Shams University, Cairo, Egypt
> www.dcs.kcl.ac.uk/pg/elmaddah
>
>
>
> [Robertson 02]Robertson, J. (2002) Eureka! why analysts should invent
> requirements, IEEE Software, 19(4) 2002
> [Maiden and Robertson 03]Maiden, N. and Robertson S. (2003) =93Creativity=
,
> the Path to Innovative Requirements=94, RESG One-day Workshop, Imperial
> College
> [El-Maddah 03] I. A. M. El-Maddah, "Innovating Requirements for Process
> Control Systems: Ideas Based on Recent Events of RESG ", British Computer
> Society, REGS, Requirements Quarterly News Letter RQ30 , 2003
>
>> Rizwan Mohsin wrote:
>>> When we are talk about requirement phase, it is
>>> difficult to capture the entire requirement in the
>>> earlier stage, how would n e one be sure about the
>>> requirement is complete and move to later stages of
>>> the development life cycle.
>>>
>>> What is meant by complete / sufficient / enough
>>> requirement and how do we differentiate them ?
>>
>> As far as I've seen, no-one can really answer this question, and
>> most attempts (eg the recent one by the INCOSE RWG) fall well short
>> of being truly useful. It's a very difficult question.
>>
>> Another thing which complicates it is that the 'sufficient' level of
>> completeness is dependent on the actual developer's skills and
>> domain knowledge, ie it is not developer independent (I learnt this
>> by reading bids for large projects - some developers need more, some
>> less).
>>
>> Although it may seem contra-indicatory, it also depends on the
>> design. As the design evolves, holes are seen in the requirements,
>> which might not have been relevant with a different design. This is
>> a more subtle effect admittedly.
>>
>> So it tends to come down to a subjective assessment by the RE, and
>> an experienced RE (with domain knowledge) should be able to give a
>> reasonable answer, although it may take a great deal of effort.
>> Having said that, an independent RE, even one with limited domain
>> knowledge, can often find many holes (and potential holes) in a
>> representation of requirements, quite quickly. I'm a great believer
>> in independent inspection of requirements for this reason.
>>
>>> What is meant by requirement stability?
>>
>> This is easier, and easier to define as its opposite - volatility.
>> Volatility is the rate of change of requirements over time. Usually
>> this is measured by the *number* of requirements which are added,
>> deleted or modified. It can be quite useful in some situations. NASA
>> has done some interesting work in this area - I can provide a link
>> if needed.
>>
>> Andrew
>> --
>> Andrew Gabb
>> email: agabb@tpgi.com.au Adelaide, South Australia
>> phone: +61 8 8342-1021, fax: +61 8 8269-3280
>> -----
>> ------------------------------------------------------------------------=
This archive was generated by hypermail 2.1.6 : Mon Dec 06 2004 - 09:00:20 EST