From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Fri Jun 11 2004 - 09:11:31 EST
=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id 523E4261D7
=09for <re-online@it.uts.edu.au>; Tue, 8 Jun 2004 23:09:26 +1000 (EST)
Received: from hotmail.com (bay12-f102.bay12.hotmail.com [64.4.35.102])
=09by filter.it.uts.edu.au (Postfix) with ESMTP id AA0241D62BD
=09for <re-online@it.uts.edu.au>; Tue, 8 Jun 2004 23:09:18 +1000 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
=09 Tue, 8 Jun 2004 06:09:15 -0700
Received: from 68.162.169.96 by by12fd.bay12.hotmail.msn.com with HTTP;
=09Tue, 08 Jun 2004 13:09:15 GMT
X-Originating-IP: [68.162.169.96] X-Originating-Email: [donald_firesmith@hotmail.com] X-Sender: donald_firesmith@hotmail.com
Colleagues,
Regarding the use of graphics, especially with regard to RE where more or
less formalized modeling languages are not always used, a process
requirement from the SEI's work on architecture is in order. Too often you
see box and arrow diagrams without any legend defining the meaning of the
boxes and arrows. You also often do not get adequate ancellary text
clarifying the diagram and providing information that is not best presented
in graphic form. If you want unambiguous requirements and you want to use
graphics, it is critical to clearly define what the icons mean and back the
icons up with any necessary textual information.
Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
Software Engineering Institute (SEI)
Carnegie Mellon University (CMU)
Pittsburgh, PA 15213-3890
(412) 268-6874
dgf@sei.cmu.edu
http://www.donald-firesmith.com
>From: Andrew Gabb <agabb@tpgi.com.au>
>Reply-To: re-online@it.uts.edu.au
>To: re-online@it.uts.edu.au
>Subject: Re: [re-online] Rant about the state of reqts. dev. practice
>Date: Mon, 07 Jun 2004 18:41:14 +0930
>
>dorfman@rahul.net wrote:
>> Thanks, Ian. The reason I lumped tables and graphics with "natural
>>language" is not that they are as ambiguous...although the can be, if
>>the variables are improperly described...but because they _usually_
>>require human interpretation, whereas formal languages can be
>>manipulated, by completely objective (mathematical) rules or perhaps
>>by machine.
>> Merlin
>
>I agree that tables and graphics can be part of a natural language
>representation of requirements, or that they can be more formal in
>nature. I'm a great believer in using tables and graphics when they
>improve the understanding of requirements. As Ian points out, there
>is a continuum across the NL/non-NL divide.
>
>Merlin shows one of the strengths of non-NL methods above. The
>downside, of course, is that the actual meaning of such
>representations is rarely immediately obvious to users or others,
>which makes it somewhat more difficult to validate such
>requirements. Individual requirements may be unambiguous but getting
>a handle on the overall requirements is much more difficult.
>
>Another problem is that non-NL methods tend to have limitations in
>the types of requirements they can represent (eg Z is generally
>limited to functional requirements, rather than performance
>requirements or other constraints). This means you normally need a
>mix of NL and non-NL anyway. Or you can just ignore those
>requirements which don't fit your representation, of course, which
>I've also seen bring down projects.
>
>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 Jun 14 2004 - 09:00:17 EST