Software Engineering (phần 8) pptx

.
' j !
@ 2 '.
I i
'
i i
t
'
! i1
1*.1 REQUIREMENTS ELICITATION Q@3 l
'
j
.
' : !
.
. i
'
events. A storyboard ' qld up a storyboard
,
a series of diagram s depicting the sequence ot g
as ' can be considered a paper prototype (Rettig, 19941, that is, a series of sheets of paper l
ly each depicting the relevant screens and the user's response. But, whatever method is k j
n- chosen, the scenario should depict the starting state, the expected sequence of events, l ':
i k
lt. and the hnishing state, together with the exceptions to the expected sequence. 4
ty Scenarios are useful in a number of different ways. 21 j
ht r '1
. They can demonstrate the behavior of the product in a way that is comprehensible I ji
t . t
o the user. This can result in additional requirements com ing to light, as in the i
'

jae
weight-loss planner example. ! l
.e. ë
'
2 Because scenarios can be understood by users, the utilization of scenarios can i
zd ' .
ensure that the client and users play an active role throughout the requirements )3e
-
the requirements analysis phase is to elicit i
.analysis process. After all, the aim ot ë 1
the real needs of the client, and the only source of this information is the client )àe r
and the users. l 'a
! .
er 3. Scenarios (or more precisely, use cases) play an important role in object-oriented i I!
!zn analvsis
. This is discussed in detail in Section l 2.3. i 1 j
t -'' I 1
th ë lW
e now consider other techniques for eliciting requirements. q l I .
ày l Ii l
Or ,1
'
3
j il@
.
l.a @THKR RequlkzMxxTs EU<ITATION W tHNlquEs ) ! (
)1-t ' l1
'rt ' Yet another way of eliciting needs is to send a questionnaire to the relevant members i
:r- of the client organization. This technique is useful when the opinions of, say. hundreds I
of individuals need to be determ ined. Furthermore, a carefully thought-out written j

be more accurate than an immediate verbal response to a question posed ' ' lanswer may
by an interviewer. However, an unstructured interview conducted by a methodical 1 1
l 1i
nterviewer who listens carefully and poses questions that expand on initial responses j i
J ' .usually yields far better information than a thoughtfully worded questionnaire
. Be-
l ier cause questionnaires are preplanned
,
there is no way that a question can be posed in !
!
se response to an answer. !
Lat A different way of eliciting requirements, particularly in a business environment, ; t.tal is to examine the various forms used by the client
.
For example, a form in a print shop j !
lis might retlect press number, paper roll size, humidity, ink temperature, paper tension, ( g
1ts and so on. The various fields in this form shed light on the flow of print jobs and j 11
ts, the relative importance of the steps in the printing process. Other documents, such I k
k f ',rs as operating procedures and job descriptions
,
also can be powerful tools for finding j .
ny out exactly what is done and how. Such comprehensive intormation regarding how j ! j
to the client currently does business can be extraordinarily helpful in determining the :1 t .client's needs. Therefore, careful perusal of client documentation should never be
.
j '
km overlooked as a source of information that can lead to an accurate assessment of the : : 1
n- client's needs. ' .
he A newer way of obtaining such information is to set up videotape cameras w ithin E :
the workplace to record (with the prior written permission of those being observed) i i 1!
!he exactly what is being done
.

One difhculty of this technique is that it can take a long time ! i :
! i (
;et to analyze the tapes. In general, one or more members of the requirements analysis r 1
'
j
ù
'
.
r j
.
'
j
i
Please purchase Image To PDF Converter on to remove this message, thank you.
l 1
2 1
i )i
.
( 2@* t u A p T : R 1. @ Requiremenls Plw se '
( l
.
team has to spend an hour playing back the tape forevery hourthat the cameras record
.
l This time is in addition to what is needed to assess what was observed
. More seriously,1
1 this technique has been known to backhre badly because employees may view the '
l h cameras as an unwarranted invasion of privacy. lt is important that the requirements ' ql
2 analysis team have the full cooperation of a1l employees'
,
it can be extremely difficult ,1 ) b

tain the necessary information if people feel threatened or harassed. The possible (p to or
-
l ; risks should be considered carefully before introducing cameras or, for that matter, j
I ë t
aking any other action that has the potential to anger employees.;
! Once an initial set of requirements has been elicited, the next step is to refine t
p .
j them. a process called requirelnents analysis. )
1 r
$
l . C
1 a
d a
l ù 41 2 Rzqulpzm zxTs A xakysls1 j *
( ; J( !
,
r) i i ' At this stage in the process, the requirements team has a preliminary set of require- pj
'
k
.
ments. These requirements are of two types, functional and nonfunctional. Functional pl ' . irements relate to the functionality of the target software; for example
,
Séltoyal- ul $ requ
'
.
l d ties for each artist shall be computed from the playlist data using the May 1998 CMS Ti
'
formula.'' Nonfunctional specifieations speeify properties of the target software, such a! iT
Iiability and maintainability, or relate to the environment in which the software irl 1 , as re
i ' ç(

.
j I , must run; for example, AIl bar codes shall be read using the Mach/zor ASRCA inptlt ft
.
' i device.'' jl t
21
; It is essential that the software be traceable; that is, it must be possible to trace
each statement in the requirements document through the specifications
,
design, and
i code. In this way, the SQA group can check that every statement in the requirements$
'
j . has been implemented and that this has been done correctly. To achieve traceability,
l each statement in the requirements document needs to be numbered
.!
'
:t A1l the items in the preliminary requirements document are given to the client to
p get their priorities. The client (or a client team) ranks each preliminary requirement
.
!l using categories sueh as essential
,
highly desirable, desirable, and so on. During the
i f this process
,
it may becom e apparent that certain requirements are incorrect; cotlrse o
! or invlevant
. Any such requirements are corrected or deleted. '
I E
'
The next step is to further refine the preliminary requirements document
. First, r1

'
j the m embers of the requirements team discuss the list of requirements w ith the various ;
j i individuals interviewed to determ ine if anything has been omitted
.
Then, because the; q
.
$ 1 i most accurate and powerful requirements analysis technique is rapid prototyping, a
.
' ! !' rapid prototype is built
.
This is described in the next section.I t ' - ,
' ! t i .' j
,
.
( ê
'
.
i : .
1@.a pIp pmoToTyplN.:
j A rapid prototype is hastily built software that exhibits the key funetionality of the
;
1 target product. For example, a product that helps manage an apartment com plex mustt
.
r '
y '
Please purchase Image To PDF Converter on to remove this message, thank you.
' I 1 .
! q
'
j (

!
!
I@.a RAplD PROTOTYPING Q@5 l
'
t
:
'
.
j '
'rd. : incoroorate an input screen that allows the userto enterdetails ofa new tenant and print : '
ily. . an occupancy report for each month
. These aspects are incorporated into the rapid j ':
the prototype
. However, error-checking capabilities, file-updating routines, and complex I :
! !nts ta
x computations probably are not included. The key point is that a rapid prototype .
lult renects the functionality that the client sees
,
such as input screens and reports, but 1
b1e its tthidden'' aspects such as file updating. (For a diftkrent way of looking at rapid iOm :
t b b low ) ier, prototypes
,
see the Just in Case You Wanted to Know ox e . i
The client and intended users of the product now experiment with the rapid pro- I lI
rine t
otype, while mem bers of the developm ent team watch and take notes. Based on their I :
hands-on experience, users tell the developers how the rapid prototype satislies their
needs and, more important, identify the areas that need improvem ent. The developers t
change the rapid prototype until both sides are convinced that the needs of the client i ;;
l encapsulated in the rapid prototype. The rapid prototype then is used !

. Eare accurate y
,!
'
as the basis for drawing up the specifications. l : l
An important aspect ot the rapid prototyping model is embodied in the word i ,
'
! rapid. The whole idea is to build the prototype as quickly as possible. After all, the i
.
1
Lre- . purpose of the rapid prototype is to provide the client with an understanding of the i 1
1 : i
naI ' product, and the sooner, the better. It does not matter if the rapid prototype hardly j ) 'j
l z
.
.ral- works, if it crashes every few minutes, or if the screen Iayouts are less than perfect. y : I
h Iient and the developers to agree 1 lWS The purpose of the rapid prototype is to enable t e c !
lch as quickly as possible on what the product is to do. Therefore. any imperfections l li
i
in the rapid prototype may be ignored. provided they do not seriously impair the l i ire
iï I
put functionality of the rapid prototype and thereby give a misleading impression of how : i
'
L *' *' '*' ''' '*
'
*' '' -'''' ''
'
j 'the product will behave
.
@ j
1 1aCe

$
j j'
I !md ' (
'
ë
LIXS C i
;
:
!ity
,
: !
'
: .i:
j
'
t to ' C i
'
j! JusT IN ZASE You W ANTEP To KNow I
ent i l'
j ttlltl
. .
l
C f 1'ect T
he idea of constructing models to show key aspects of prototype to determine the client's real needs. Sec- 't i j''l
a product goes back a Iong time. For example, a 1 6 1 8 ond, in an age before architectural drawings, the model l
j
:
1
rst, ' painting by Domenico Cresti (known as ''11 Passignano'' showed the builder the structure of the building antt in- ) :
ous : because he was born in the town of Passignano in the dicated to the stone masons how the building was to j . j

the 'ï Chianti region of Italy) shows Michelangelo presenting be decorated. This is similar to the way we now build i ' '
) !
.
a wooden model of his design for St. Peter's (in Rome) a rapid prototype of the user interface, as described in ;;
.
a
, .
!
to Pope Paul IV. Such architectural models could be Section 10.4. ) 'L
huge; a model of an earlier design proposal for St. Pe- It is not a good idea, however, to draw too close 1 j
' ter's by the architect Bramante is more than 20 feet long a parallel between such architectural models and soft- 1 j'
'
on each side. ware rapid prototypes. Rapid prototypes are used dur-
,
'
1
I
Architectural models were used for a number of ing the requirements phase to elicit the client's needs. 'j
First, as depicted in the Cresti Unlike architectural models, they are not used to rep- 1, different purposes
.
I
i painting (now hanging in Casa Buonarroti in Flo- resent either the architectural design or the detailed de- I I
' dels were used to try to interest a client in sign', the design is prodtlced two phases Iateq that is, l 1.rence), mo
.
:
the tunding a project. This is analogous to the use of a rapid during the design phase. .
'
(
'
lust g .

l
.
'
j .
.
I l
l' i
j
Please purchase Image To PDF Converter on to remove this message, thank you.
'
:
j
l
I !
'
I 2@ê t H A p T E * 1* * Requiremenls Phose1
1
!
A second major aspect of the rapid prototyping model is that the rapid prototype1
.
must be built for change. If the first version of the rapid prototype is not what the
I1 client needs
,
then the prototype must be transformed rapidly into a second versionIj j that, it is hoped, better satisfies the client's requirements. To achieve rapid develop-
: ment throughout the rapid prototyping process
. fourth-generation languages (4GLs) gI q
! i and interpreted languages, such as Smalltalk, Prolog, and Lisp, have been used. Pop-!
i : ular rapid prototyping languages of today include HTM L and Perl
,
as well as visualI

! C++ and J++. Concerns have been expressed about the maintainability of certain
1 interpreted Ianguages
, but from the viewpoint of classic rapid prototyping, this is irrel-1 !
,
l 2 evant. All that counts is, Can a given language be used to produce a rapid prototype?
i And can the rapid prototype be changed quickly? lf the answer to both questions is
;
I yes
.
then that language probably is a good candidate for rapid prototyping.;
'
j Turning now to the use Of rapid prototyping in conjunction with the object-
i Orientod Paradigm
.
three very different Object-oriented projects canied Out by lBM 1
;
'
.
1 j showed significant improvements compared to projects using the structured paradigm
r ,
j' j gcapper, Colgate, Hunter. andlames, 19941. Oneof therecommendations thatresulted
I i !' ( from these projects is that it is important to build a rapid prototype as early as possible
.
I
; : in the object-oriented Iife cycle.l i i Rapid prototyping also is particularlyet-fective when developingthe userinterface
'
j 1 !i t
o a product. This use is discussed in the next section.1 : ;
I i rI '
; Il 11

'
1 ; .
'
j 1 r
! 1 1*.4 HUM AN FAtToRsi
i
I lt is important that both the client and the future users of the product interact with
the rapid prototype of the user interface. Encouraging users to experiment with theI
human-computer interface (HCl) greatly reduces the risk thatthe finished productwill
; have to be altered. ln particular, this experimentation helps achieve user-friendliness
,1 a vital objective for all software products
.
l
! The term user-friendlinen' refers to the ease with which human beings can com-
! municate with the software product. lf users have difliculty learning how to use a
i roduct or tind the screens confusing or in-itating
,
then they will either not use thepi
duct or use it incorrectly. To try to eliminate this problem , menu-driven productsprol
i were introduced. lnstead of having to enter a command such as Perform computo-
:
!! ë tion or Print service rate report. the user merely has to select from a set of possible
? responses
,
such as1 i
.'
t .
I 1 ) ! perform computation
I
y

2. Print service rate report1
1 3. Select view to be grophed
:
! 'j 2, ln this example, the user enters 1 , 2, or 3 to invoke the corresponding command.
Nowadays, instead of simply displaying lines of text, HCIs employ graphics
.
'
W indow s, icons, and pull-down menus are components of a graphical user interface
2
J
I I ,
.
i $
.
Please purchase Image To PDF Converter on to remove this message, thank you.
4*.* HUMAN FM TORS A*V
pe (GUI). Because of the plethora of windowing systems, standards such as X W indow
3e ' have evolved. Also, ûlpoint and click'' selection is becoming the norm. The user moves
m a mouse (that is, a handheld pointing device) to move the screen cursor to the desired l
é' int'') and pushes a mouse button (diclick'') to select that response. iP- response ( po
s) ' However, even when the target product employs modern technology, the design- q
L
:
p- ers m ust never forget that the product is to be used by human beings. In other words, y
al the HCl designers must consider humanfactors such as size of letters, capitalization, : ,
in color, line length, and the number of lines on the screen. !
! '
:l- Another example of hum an factors applies to the preceding menu. If the user ' !
z? chooses option 3. Selectview to be graphed, then anothermenu appears with another l ji
is list of choices. Unless a m enu-driven system is thoughtfully designed, there is the 1

danger that the users will encounter a lengthy sequence of m enus to achieve even a
, j
2t- relatively simple operation. This delay can anger users, sometimes causing them to
M) make inappropriate menu selections. Also, the HCl must allow the user to change a ë
.
;m
previous selection without having to return to the top-level menu and start again. This
td problem can exist even when a GUI is used because many graphical user interfaces r j
le essentially are a series of menus displayed in an attractive screen format. ' : 2T
t
Som etimes, a single user interface cannot cater to al1 users. For exam ple, if a ,
:
'
i
ze product is to be used by both computer professionals and high-school dropouts with 1 t
no previous computer experience, then it is preferable that two different sets of HCIs i i
! lb
e designed, each carefully tailored to the skill Ievel and psychological prohle of its 1 i
t
'
i -intended users
.
This technique can be extended by incorporating sets of user interfaces !
requiring varied levels of sophistication. If the product deduces that the user would be ; j:(
'
I
-
. more comfortable with a less-sophisticated user interface, perhaps because the user : 1
.
E lis making frequent mistakes or is continually invoking help facilities

,
then the user ,
;
! (automatically is shown screens more appropriate to his or hercurrent skill level. But, as
th the user becomes more familiar with the product
,
streamlined screens that provide less i
le information are displayed, leading to speedier completion. This automated approach ! C
ill reduces userfrustration and leads to increased productivity (Schach and Wood, 19861. : .
'
S, M any benefits can accrue when human factors are taken into account during the : j
design of an HCI. including reduced Iearning time and Iowererrorrates. Although help ' i
'
'''-' ja
-
facilities always mustbe provided, they are utilized less with acarefully designed HCI. j t
'
. ,. ., . , ; 1a Thi
s, tOO, increases productivity. Unllorm ity ol Htil appearance across a product or l 2 'j
le group of products can result in users intuitively knowing how to use a screen they have l I
I '
ts never seen before because it is similar to other screens with which they are familiar. ' 1
,
i I7
-
Designers of Macintosh software have taken this principle into account', this is one I j
le f the many reasons that software for the M acintosh generally is so user-friendly
.
:
.

lo
.
I E I
' It has been suggested that simple common sense is alI that is needed to design ; ,1 i la user-friendly HCI. Whether or not this charge is true. it is essential that a rapid
'
prototype Of the HCI of every product be constructed. Intended users of the product l I
' iment with the rapid prototype of the HCl and inform the designers whether ! 1
.
can exper i
the target product indeed will be user-friendly. that is, whether the designers have i
taken the necessary human factors into account. '
s. ln the next two sections, superhcially attractive but dangerous variants of the i : j
le rapid prototyping model are discussed. C i
'
r
'
:
'
j1
j 1
l l
1 !
: q l
Please purchase Image To PDF Converter on to remove this message, thank you.
l .l '
'
I jl 1 .
.
) ' i 2@8 t H A p T : R ;@ * Requirem en's Phose
1 '

!
' 1*.5 pIp PR/T/TTPIN/ As A SPEtIFICATI@N ;
TKtHNIQUE
! The conventional form of the rapid prototyping model, as described in Section 3.3 and
l i depicted in Figure 3
.
3, is reproduced here as Figure 10. l . (Again. the implementation1
and integration steps generally are performed in parallel.) The rapid prototype is used
I ,
l
I
t r - - - - - - - a
l Rapid I changed <
- - - -
'
j rototype I req
uirements I II p
a I Lj k
- - - - - - - -
j'
verify r - I verify I Ii :l
, % a Ii ' l
j( I ( I
I j I
i i s ecification lj
E p - . - . . -
. - - - . m ji ' phase
,
I I I
! 1 verify I lI , ' I I

'
iij .1
*
'
'
y
'
!1 !1
j 1 '
l I I lI
-
I 11 E oesign
- - - - - - -
j j:
'
i
! l . phase I j j .i
.
l 1;
! 1 : I I ,
'
.
verify 1I
l l
i I I .
ë l
I l I I
1 I I I
! lmglementation - - o jjj
q phase

.
I I I 1
,
j j j j jTest
1 ' ' l II I
1 1I I
j
'
j .
.
; I II I
.
. : lntegration I II I
i phase I Il I
l I I
- . ) j $ j
'
j Test I I I I
'
: i .I I I I
'
'
!
! '.
.
1 : ' Maintenance
( : phaseE'
t ( .
J
'

'
;
h j .
1 * Development Retirement
:l - - -*' Maintenance
! .
FI@vr@ 1*.1 kapid prototyping model. k
E
J @
f
'
j
r 't
1
1 '
!
.
.
1' . '
. : '
Please purchase Image To PDF Converter on to remove this message, thank you.
: :
:
:
. '@.s RAplp PRoToa plNo As A 5p!c1FIEATIoN TEEHNIQUE 2@@
'
as a means to determine that the client's needs have been elicited accurately. O nce
the client has signed off on the specihcations, the rapid prototype implementation is
E ;discarded (but the lessons learned are retained and used in subsequent development
,

phases). A second approach is to dispense with specihcations as such and use the i
.
rapid prototype itself either as the specifications or a significant part of them . This
d t pe of rapid prototyping m odel is show n in Figure 10.2. The approach of-secon y .
j .fers both speed and accuracy
.
No time is wasted drawing up written specihcations, ;
i
and the difficulties associated with specifications, such as am biguities, om issions, :
and contradictions, cannot arise. lnstead, because the rapid prototype constitutes the E l
specihcations, all that needs to be done is to state that the product will do what the
id rototype does and list any additional features the product must support, such jrap p j
as file updating, security, and error handling. 1
g '
i - - - a ëT
d ;- !Rapid I Change
- -
irements l I i .prototype I requ
-
1 I i (ç
- - - - - - -
;

1 Verify l l : 1Verify
r - L
- - - - - - - - -
1 I q l lI
j - 1I :
II i I
I . i T

'
Design j
- - - - - - - m j g gphase 1
I I 5 i 1
I l (
'
Verify i j
,
I I !!
I I ' l
I I : l! . (
.
I lI
mplementation l
- - -a I I 1
phase TI I I
j .I I I
Test j rI 1
: '
I I l ! ! i
I ! ! ;I I - i
l I I I i
Integration I I ' lI I l
phase 1 !I I
j ' :I
I I I j kTest
1 I l l l
I I l j!1
, lM
aintenance '. II

phase ! jI
.
i
:
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''d
.
y 1t
l -
netirement : 1
)
'
.
''- - -
+ ' Development E
- - -
+. Maintenance l j!
'
.
.
! t
à
'
'
, ; Flgure I@.Q qapid prototyping with the rapid protofype !
'
t serving as specifications. ; j '
7 I 1
: lE
.
.

!
: ';
.
t
.
2l
i
I
i
Please purchase Image To PDF Converter on to remove this message, thank you.
)( j
.
j !l i
'
j :a@@ t H A p ' E R 1* * Requiremen's Phose
! .
k
This version of the rapid prototyping model can have a major drawback. lf there
is a disagreement as to whether the developers have satisfactorily discharged their
obligations, it is unlikely that a rapid prototype will stand as a legal statement of a
j contract between developer and client. For this reason, the rapid prototype should
I never be used as the sole specihcation
,
not even if the software is developed inter- '
: nally (that is, when the client and developers are members of the same organization).
L Although it is unlikely that the head of the investment m anagement division of a
f bank will take the data processing division to court
,
disagreements between clientI ;
l and developers nevertheless can arisejust as easily within an organization. Therefore, . '

'
f to protect themselves, sottware developers should not use the rapid prototype as the ,'
l specihcations even when software is developed internally
.1
.
, A second reason why the rapid prototype should not take the plaee of written
.
I
specifications is potential problems with maintenance. As described in Chapter 16,
.
t
J maintenance is challenging, even when a11 the documentation is available and up to
: 1 date
.
If there are no specilications, maintenance rapidly can become a nightmare. Thet 1 i
)
) 1 '! ' problem is particularly acute in the case of enhancement, where changes in require-l
: .
: i I ments have to be implemented. lt can be exceedingly difhcult to change the design
'
l ) documents to reflect the new specifications because, in the absence of written speci-
: ê l i the maintenance team have no clear statement of the current specilications
.
,
ficat ons,l l
' 1 ' For both these reasons
,
the rapid prototype should be used simply as a require- .
j l l s
.

.
j ments analysis technique, that is, a means of ensuring that the client s real needs
.
1
1 ) ; have been elicited correctly. Thereafter, written specihcation documents should be! ! ;
j ' i produced using the rapid prototype as a basis. ;4 .
$'
j
i
2
k 1*.* RKUSIN/ THK pIp PRW @TYPK
l
!
k ln b0th versions of the rapid prototyping model discussed previously, thc rapid pro-
. is discarded early in the software proeess. A n alternate, but generally unwise,: totype
I '''' '''
.( way of proceeding is to develop and rehnc the rapid prototype until it becomes the
1 product. This is shown in Figure 10.3. ln theory, this approach should lead to fast soft- .)
I ware development'
,
after all, instead of throwing away the code constituting the rapid
; j prototype, along with the knowledge built into it, the rapid prototype is converted into
l y the tinal product. However, in practice the proeess is very similar to the build-and-tix
? h of Figure 3
. 1 . As with the build-and-fix model, the tirst problem with this k! ! i approac
1 : i form of the rapid prototyping model is that
, in the course of rehning the rapid pro-!
; y totype, changes have to be made to a working product
.
This is an expensive way to

l i d as shown in Figure l
.
5. A second problem is that a primary objective whenj procee ,!
'
. j constructing a rapid prototype is speed of building. A rapid prototype (correctly) is
I put together hurriedly
,
rather than carefully specitied, designed, and implemented. 'i I
In the absence of specihcation and design documents, the resulting code is difficult C
.
'
and expensive to maintain. lt might seem wasteful to construct a rapid prototype then i
throw it away and design the product from scratch, but it is far cheaper in both the
l
.
1
1 .
; I
' j .
.
! k
Please purchase Image To PDF Converter on to remove this message, thank you.
.
ù E
l i :
-
i i
@ !1
!
.*.* REUSING THE RAplp PROTOTYPE 3@% I

!
i 2 .
iere T 1 7
Rapid I Changed I ' 'h
eir -*. - - = !
prototype I requirements I l .
f a
-
1 IO j
- - - - - - - - 1 !
nuld verify 1- - - 1 Verify i j
t- - - - - - - - -1 E (lter
-
I I ( .
I
on). I j j
1 lof a n
efine - - l j '
Lient prototype I
? l .ore
,
IT
est l
; the I I .
l .1 1
I
itten '
1 .Maintenance - - - - - -
.
'

16 hase : '
.
, p
Lp to j!
The . +' Development :
- - '+ Maintenance Retirement
Jire- j j
i n . l ls g
r j .Flgure 1@
.a Unwise version of rapid prototypins model.
leci- 1 I
i I
ons. I lI
ire- i I
.1 !
ds . ize
i !
d be short term and the Iong term to do this ratherthan try to convert a rapid prototype into $ i
I
- k l 9751. iproduction
-
quality sottware (Broo s, i
. .
'
i :
Another reason for discarding the rapid prototype is the issue ot pertormance, 1,
particularly of real-time systems. To ensure that time constraints are met, it is nec- !
,
g
essary to design the product carefully. ln contrast, a rapid prototype is constructed (

to display key functionality to the client', performance issues are not handled. As a ! :
: iresult
,
if an attempt is m ade to refine a rapid prototype into a delivered product. it is '
unlikely that response times and other timing constraints w ill be met. :
PrO- One way of ensuring that the rapid prototype is thrown away and the product !
! iVise
,
is properly designed and implemented is to build the rapid prototype in a different j5 the l
anguage from that of the product. For exam ple, the client may specify that the product i
soft- must be written in Java
.
It the rapid prototype is implemented in HTML, tor example, j
apid it will have to be discarded
.
First. the rapid prototype is implemented in HTML and ik I
j
into . refined until the client is satisfied that it does everything
,
or alm ost everything, the I
EI-EX target product is to do
.
Next, the product is designed, relying on the knowledge and 1 :
l E! !thi
s skills acquired in constructing the rapid prototype. Finally, the design is implemented j . '
;
pro- in Java, and the tested product handed over to the client in the usual way. I i
ty to Nevertheless, there is one instance when it is permissible to reline a rapid proto- i ji
-
the rapid l lzhen type or. more specihcally, portions of the rapid prototype. When portions ot

:
ly) is prototype are computer generated
,
then those portions m ay be used in the final prod- .
lted. uct
.
For example, user intert-aces often are a key aspect of a rapid prototype (Section
icult 10
.
3). When CASE tools such as screen generators and report generators (Section :
then 5
.
4) are utilized to generate the user interfaces, those portions of the rapid prototype . j
1 the indeed may be used as part of production-quality software
.
i è
1
E
'
'
.
: : I
i l
I t ll
.
Please purchase Image To PDF Converter on to remove this message, thank you.
.
k
'
j 'i

C
'
h l
1
l:
j a@2 < H A p T : R 1* @ Requiremengs PhoseL
1
The desire not to ''waste'' the rapid prototype has resulted in a m odihed version
'
of the rapid prototyping model being adopted by some organizations
. Here, m anage-
I ment decides before the rapid prototype is built that portions may be utilized in the
'
l i final product
,
provided those portions pass the same quality assurance tests as other' 1 l ftware components
. Therefore. after the rapid prototype is complete. those sectionsso
l that the developers wish to continue to use must pass design and code inspections
.:2
, This approach goes beyond rapid prototyping. For example
, components of suffi-
i iently high quality to pass design and code inspections usually are
not found in a !! c
,
' :
, l rapid prototype. Furthermore
, design documents are not part of classic rapid proto-
. i
.
I typing. Nevertheless. this hybrid approach is attractive to som e organizations hoping

l to recover some of the time and money invested in the rapid prototype
.
However, tot I
,
! ensure that the quality of the code is sufficiently high, the rapid prototype has to be
'
I
'
j built somewhat more slowly than is customary for a û'rapid'' prototype
.i
q
2 The management implications of the rapid prototyping model now are considered.
:: i
l I r$
1 I
: t . l :
'
:
)
'
jl 1
-
.
.
I ! 1@.y M ANAOKM ZNT I- pkltv loxs o: TuK pIp
; t l pRoToa plxo M opzk
,
'
j : g
,,

11 1: ( ':
' ! One difhculty with rapid prototyping is that the ease w ith which changes generally
k. l
I j can be made to a rapid prototype may encourage the client to request all sorts of majorr
'
! . g r
:
I l
j . changes to the delivered operational-quality version of the product. Furthermore, the
j client may expect the changes to be implemented as rapidly as changes to the rapid
I prototype. A related challenge is having to explain to the client that the rapid prototype
is not of operational quality and the client will have to wait tbr the operational-quality
2 version, even though the rapid prototype appears to do everything needed
. Before
l rapid prototyping is used
, it is essential that the managers responsible for developing1
the product discuss these and related issues with the client
.
'
I
! A s with the introduction ofany new technology
,
betbre an organization introduces
. ë
I the rapid prototyping model it is vital that management be aware of the advantages
.
! and disadvantages of rapid prototyping. ln a1I tairness
,
although the case for rapid
!:

j prototyping is strong, it has not yet been proven beyond al1 doubt
. For example, a
'
i frequently quoted experim ent is that of Boehm
, Gray, and Seewaldt, who compared' j
.
p 'j ! seven different versions of a product gBoehm, Gray, and Seewaldt, 19841. Four ver-
: ! ions were specihed and three were pr
ototyped w ith the rapid prototype serving as thel : s1 :
I ! specifications. The results were that rapid prototyping and specifying yielded products
1 ' ' with roughly equivalent performance, but the prototyped versions contained about 40i
. percent less code and required about 45 percent Iess effort. The reason was that the;
i
: specification teams had no compunctions about adding bells and whistles to the spec-'
( !itication document
. On the other hand, the rapid prototypers realized that they would
have to build every feature into the rapid prototype and
,
therefore, were reluctant to
incorporate any functionality that did not seem essential
. W ith, on average, 40 percent
l Iess code, it is not surprising that the prototyped versions were rated somewhat lower
'
I
!
) 'l
t '
,
j '
Please purchase Image To PDF Converter on to remove this message, thank you.

. l l j
'
j
h .
1@.y M ANAGEMENT IMPLICATIONS OF THE RAPID PROTOW PING MODEL 3@3 ê
r
:
:
on functionality and robustness. But, interestingly enough, they were rated higher on
t
,
ease of use and ease of learning. Finally, specifying produced more coherent designs ;
: ' ' and software that was easier to integrate.
'
One important point about this experiment was that it was conducted on seven t
. '
teams of graduate students, three two-member teams and four three-member teams.
The project was only 10 weeks in duration, and no maintenance of the product was )

performed. ln other words, the experiment is not typical of real products with respect i
to number of participants, team size, project size, or software process. It therefore i
r
1
.
perhaps is unwise to accept Boehm's results as a blanket endorsement for rapid pro- 1
totyping. lnstead, they should be taken as indications of the comparative strengths (
and weaknesses of rapid prototyping when compared to specifying. ln addition to the ( !
his collaborators found that proto- i l .
,
weaknesses pointed out previously, Boehm and

typed products are harder to integrate than specihed products. Ease of integration is
.
'
important for large-scale products. especially C4I (command. control, communica- '!
tions, computers, and intelligence) software. This is a further reason to use the rapid
prototyping model depicted in Figure 1 0. 1, where rapid prototyping is em ployed as j
a requirements analysis technique, and not use the model of Figure l 0.2 where rapid l ë
'
l
prototyping takes the place of specifying. ') j
T ts of rapid prototyping must be taken into account by any manager. i lwo aspec
!
Section 10.5 pointed out that it is shortsighted to turn a rapid prototype into the l
. I
final product', the rapid prototype should be used solely as a means of accurately (!
!d
etermining the client's requirements. A second important issue is that, under some , j
f circumstances, rapid prototyping can take the place of the specifications phase', it $ $
! 1
r can never replace the design phase. A team certainly can use the information and j
experience gained from the rapid prototype as a guide to t-ashioning a good design', ' l
1 ' however
, because the rapid prototype is thrown together rapidly. it is unlikely that a 2 i I
: h
D good rapid prototype will have a good design. ; ,
( A more fundamental issue is that managing the rapid prototyping model requires l 1
z a major change in outlook for a manager accustomed to managing only the waterfall !
é model. The concept underlying the waterfall m odel is to do things correctly the lirst l
del incorporates a number of feedback loops if the ; iti
me. Certainly, the waterfall mo ;

s team does not aecomplish this goal (and the goal is seldom, if ever, reached). However, r )
' !
s the ideal for the waterfall model team is to perform each phase of the development i
El process one time only. In contrast, a rapid prototype is built specihcally to be changed ' i qi
) 'i
R frequently then thrown away. This concept is diametrically opposed to the approach to
.
!
:1 which the average manager is accustomed. The rapid prototyping approach of taking ':
-
several iterations to get it right probably is a more realistic approach than the first- , j
z time-right waterfall model expectation, and this logic may help convince a manager j !
s to change to the rapid prototyping model. ë !
) Another aspect of the rapid prototyping model that requires a different approach ( 1l
z on the part of the m anager is the increased interaction between the client and the 2 i
.
I ' I
-
developerss particularly the rapid prototyping team . ln the watertall model, interaction l
El between client and developers essentially is restricted to a series of interviews between 1 )
irements team and the client and its employees. When rapid prototyping is ) i j3 the requ
t ' used. there is almost continual interaction between the rapid prototyping team and :
r the client's team until the rapid prototype has been aceepted. , l
; q
: 1
ë -1
: i
'
: !
g '

i
' 1
Please purchase Image To PDF Converter on to remove this message, thank you.
i .
.
i
!
l
' i ao* t u A p v : p lo . Requirements phose r
h
1 .
'
; j 1*.* Kxp:RI:Nt:s wITH Plp PR@T@TYPIN/
i I
' ' Gordon and Bieman analyzed 39 published and unpublished case studies that use rapid
, prototyping (Gordon and Bieman, 19951. Of these, 33 were considered successes, 3
'
1 ere considered failures
,
and 3 were not rated. Gordon and Bieman have pointed out .WI 1
' ' that studies of unsuccessful cases rarely are published. Consequently, theydo notclaim;
.
'
I that their analysis reiects a high success rate as a consequence of rapid prototyping.
j : 'Their work rather is a report on a number of commercial software projects in which1
'
.
l rapid prototyping was used with some success.
I Not all the case studies, as published, reqected every issue of interest. For exam-
' 1 i l 17 of the case studies

. Improved ease' ple, comments on ease of use appeared n on yî
'
!
l of use of the delivered product as a consequence of rapid prototyping was reported in
a11 l 7 instances', none of the other 22 case studies claimed that the product w as harder
;
'
I '
l to use. Therefore, although the data are incomplete and specilic topics may not be
) explicitly mentioned, it is possible to draw some conclusions.
t ' All the case studies that commented on user participation reported enthusiastic'
'
) participation early in the process. Also, rapid prototyping was found to meet clientE d Th
ere was less unanimity in other issues. For example, four sources reported, nCC S.l 1. that rapid prototyping resulted in smaller delivered products, and one reported in-
.
1 j creased code size. Many case studies mentioned that fewer unnecessary features were
'
i l l implemented with rapid prototyping
,
but tw o reported an inerease in such features.
l I , choice of Ianguage for rapid prototyping does not appearto be of critical impor-
.
! . I! t
ance. A total of 26 different languages were used in the 39 case studies. The most
-
p
.
1 popular Ianguages were Lisp (four instances) and Smalltalk (three instances)
.
.' 1 . ,

: i The most controversial part of the results relates to whether the rapid prototype
,
'
t ! should be disearded. lt is diftieult to reac.h definite conclusions on this issue because
! ,
I of the wide variety of software processes used. ln som e cases, the rapid prototype
'
j as a whole was successively refined until it became the final product. In others, only l
'
'
i id rototype was retained and the rest discarded. In one instance, apart of the rap p1
:
! design phase was required for each iteration of the rapid prototype. For some of the
2
i case studies, management speeified in advanee that the rapid prototype would be
' j retained and refined
. Of the cases studied, 22 specihcally recom mended retaining
.
I
k
l and refining all or part of the rapid prototype, and 8 insisted that it be discarded.
'
' It has been suggested that retaining the rapid prototype is particularly important for
l
.
'
4 Iarge products. Of the 39 case studies, 7 were considered large (over 100,000 lines of
' t code), and all 7 recommended retaining all or part of the rapid prototype. ln view of@ i
k : ' the generally held belief that rapid prototypes for all products should be discarded,
! 1 '

.
further research needs to be conducted in this area. In particular, it is important to know
: whether the modified rapid prototyping model described at the end of Section 10.51
@ ' was followed. That is, did management decide before the rapid prototypes were built
' i ; that portions might be utilized in the hnal product and the parts that the developers
j :
h wished to retain first had to pass design and code inspections.
1 Some tentative conclusions can be draw n from this work. The first is that rapid
'
prototyping is a viable technique that can lead to successful softw are development. At '
the same time, there are a num ber of possible risks. If the rapid prototype is retained,
.
2 there is a danger that the resulting product will be badly designed
,
hard to m aintain,
.
h .
. ; '
'
i ( '
!
'
j
: j '
Please purchase Image To PDF Converter on to remove this message, thank you.
.
!
t
g. 2
'

j
4 44 TEsTlNo DuRINo THE REQUIREMENTS PHASE a@5
' j: .
and perform poorly', these risks appear to grow in proportion to the size ofthe product. E
However, the risks can be reduced. One way is to use the modihed version of rapid p
prototyping described in Section 10.5. j ;id
:There is a difference between reporting on case studies and conducting controlled ;
3 !
'
exoeriments. But bearine in mind that controlled exoerimentation in software enei- i
Llt r = ' '-' y
neering can be extremely difhcult, one alternative is to learn from the experiences of
m I ' jothers
.
Ig
.
I i
h ; Il
.
1
.
,
j
n- i
' j'e 1* @ Tztuxlques FoR R:quIR:M :NTs i
irl <' 2
ELIZITATI@N ANp A NAW SIS 7er
7e
'
The primary requirements elicitation technique is interviewing (Section 10. 1 . 1). To. 1

ic illustrate this, suppose that the requirements analysis team decides at the start of the ! i
nt project to build a rapid prototype. Before the first iteration of the rapid prototype can : l
'
be built, however. the team must interview the relevant client personnel. The more q l
jzd
n- thoroughly these interviews are conducted, the greater is the probability that the hrst ) 1
' h ther hand, simply throwing ( lre iteration accurately will reflect the client s needs. On t e o j
together a rapid prototype and then going through a Iengthy retinement process will 1
,
I
a.
' j
not be time or cost effective, precisely because rapid prototyping is a requirem ents ' ':)r-
'
1 sis technique and not a requirements elicitation technique. i 1)st 2na y
.
ll
nterviewing also is required if the forms technique is used (Section 1 0. l .3). , j
'
l f forms. reports, andjob descriptions can be extremely useful. How- l 'Careful perusa oPe : i
se ever, the only way to be sure of the accuracy of the inform ation gleaned from this
!
e ' study is to interview the relevant members of the client organization. Consequently, jP
ly as claimed at the beginning of this section, interview ing indeed is the primary require-!
'
.
ts elicitation technique. On the other hand, as pointed out in Section 1 0.2, rapid ia men
he prototyping is the most accurate requirements analysis technique. Rapid prototyping l !
l lb
e results in the construction of a working model of the product and is m ore likely to !

9 l
ng meet the client s real needs than other techniques. Unless rapid prototyping is utilized, i j
i
:d. ' there is a significant risk that the requirements analysis phase will not be adequately ! 1
' il1 not be completely met by the target product. ib
r Performed and that the client s needs w
of E )! Eof
: l
. I
: .l
j
:d, . ;
p
'
'
)%!? p
1*.1* TESTIN/ PURIN/ THK REQUIREM ENTS ' i)
. 15
r Ililt puas: ; j
.
i,rs
r ;
Although the aim of the requirements phase is to establish the client's real needs, l Ip
'
j)id usually the client will not be the primary user of the target product
.
It therefore is !
i ' j ,At essential to give the users the opportunity to experiment with the rapid prototype i l
,! ; l
,d, ! and suggest changes that, when approved by the client, will be implemented in the r j

in, ' delivered version of the software product. l
l
l
: l'
E j
.
i j
Please purchase Image To PDF Converter on to remove this message, thank you.
(
'
I '
.
:
1
!
.I a@ê t H A p # E k .@ * Requiremenls Phosei
.
Therefore. the role of the software quality assurance group during the rapid
: prototyping phase is to ensure that the relevant individuals in the client organization
have the opportunity to interact with the rapid prototype and their suggestions actually
. reach the client ors perhaps, a com mittee of client managers responsible for analyzing
'
j
the suggestions of the users.
.
lI
'
t As mentioned in Section 10.2, from the viewpoint of testing during the phases '
2 ( that are to com e
.

it is essential that the requirements be traceable. To achieve this, the !
I
! statements of the requirements need to be numbered to enable the SQA to trace them
) i through the subsequent phases. The numbering should appear in the rapid prototype
t : in the form of comments adjacent to the group of statements that implements each
1 item in the requirem ents
.
1
.
I
1
' j
.
'
t' I r
i I j -'t j 4*
.11 tA :K Toots FoR TH: RzqulR:- uxvs
' '
. (
,
j puas:1
'
Interpreted languages generally serve as good media for rapid prototyping
.
Because .
) g interpreted languages need not be compiled or linked, the development of the rapid
; : 1 prototype is faster. Also, minor changes requested by the client often can be imple-
'
) t mented while the rapid prototype is being demonstrated. Interpreted languages, in1
.

1
-
'
! general, are less efficient to execute than compiled languages
,
and difficulties witht 2 t ; maintenance have been associated with some intemreted languages. However, neither
t
j of these issues is relevant within the context of rapid prototyping. The key point is1
'
that a rapid prototype is put together quickly then discarded, and m ost interpreted
S
I languages are ideal for this purpose
.
.
i
.
j Further efliciency can be gained by using CASE tools associated with the rapid
j prototyping language. For example, Smalltalk has an environment that assists the
I user with a variety of tools and speeds up the rapid prototyping process
. The lnterlisp
r environment is a similar product that assists Lisp programmers
. Java is afully portable' i
,
p interpreted language. Many Java environments currently are on the market, and more
! are expected in the future. As previously m entioned. Perl is a popular programming
I
j language for constructing rapid prototypes. HTML is another important. widely used
, t rapid prototyping language. If the rapid prototype will be discarded (as described in
1 Section l 0.7). then HTML has a further advantage. lt is almost inconceivable that the '
; 'F delivered product will be written i

n HTM L, so use of HTM L virtually guarantees that!
!
:
j the rapid prototype will be discarded.
.
! For some years now, fourth-generation languages sueh as Oracle, PowerBuilder,
j : 'ù and DB2 have been used for rapid prototyping (4GLs are discussed in Section 14
.
2).
, ' There are a number of reasons for this
. First, a design goal of every 4GL is that fewer '!
.
; statements are needed to achieve the sam e functionality than with a third-generation
i language Iike Java
,
Ada, or C++. Thus, the rapid prototype is likely to be delivered
l idly when a4G L is used
. second, many 4GLs are interpreted. This speeds up, / more rap
1.
'
j rapid prototyping. as explained at the beginning of this section. Third, many 4GLs areF
@ supported by powerful CASE tools, thus speeding up the rapid prototyping process
eYen more.;
; '
.
I
Please purchase Image To PDF Converter on to remove this message, thank you.
. : .
.
:

1*.12 METRICS FoR THE REQUIREMENTS PHASE a@y
- I
.
.
).
id ' i 'tP On the other hand
,
the use ot a 4GL for rapid prototyping can have an inherent y
'
.
;
.
Lion disadvantage
. The CASE environment in which a 4GL is embedded trequently is '
ally part of a larger set of tools to be used for the com plete software process
. The soft-
ing
r ware process usually recommended by a 4GL supplier is to build the rapid prototype 'j 1
,
:
then to refine it successively until it becomes the hnal product. After all, the supplier jtses f
requently does not care if the software process degenerates into the build-and-fix lthe ê model
.
Unfortunately, the sole aim of m any 4GL suppliers is to ensure that develop- i
'
.
; l
1em ment organizations purchase its product. a single CASE environment that can handle : j' :
yPC : al1 aspects of a project. ' ji
'

tware development manager has just paid tens if not hundreds ijach suppose that a sot
' of thousands of dollars for a CASE environm ent that will support every phase of the : 1
:. . ) ! !
software process. It certainly is not easy to convince that manager to spend still more i i
. ,
. .
. s
money on a workbench tor a ditterent language to be used tor rapid prototyping to
ensure that rapid prototypes can be discarded. The manager may well retort that he or !
1
she has purchased a perfectly good rapid prototyping tool as part of the new environ-
'
ment and now is being asked to throw away m oney buying an unnecessary additional
rapid prototyping tool so that rapid prototypes can be thrown away. The m anager must , 1
1
be shown that the cost of an additional tool or workbench for rapid prototyping is l j1
,use : small compared to the potentially huge expense of trying to convert a rapid prototype ' i
1 :kpid
.
into production-quality software then attempting to m aintain that product. j 1
?le- ! l
! iirl
& g
k'ith i il
!
rher (
'
jLt is ! !@
.
!Q KTRlts Fo R THz RzqulRzM zxTs PHAS: I 1

1
g
1
rtk, (1 ' I
z
'
j
A key feature of the requirements phase is how rapidly the requirem ents team de- 4
zpid ' termines the client's real needs
.
So a useful metric during this phase is a measure of !
'
. jth
e requirements volatility. Keeping a record of how frequently the requirements change ; I
lisp during the requirements phase gives management a way of determining the rate at l r
J
'
jtble
.
which the requirem ents team converges on the actual requirements of the product. This l i
I ë
Lore . metric has the further advantage that it can be applied to any requirements elicitation : 'i
Cing technique
,
such as interviewing or scenarios. : )
Sed Another measure of how well the requirements team is doing itsjob is the number 1
El in of requirements that change during the rest of the software developm ent process
.
lf ' : 1
1th

e a large number of requirements have to be changed during the specification, design, '; I
S' 1Ehat and subsequent phases
,
then it is clear that the way that the team carries out the ' .i .
) requirements phase should be thoroughly analyzed. Again, this metric is applicable ! ii
-
ler, ' to all the requirements elicitation techniques described in this chapter
.
I j
- l tric when rapid prototyping is used is the number oftimes each feature : t.2). i A usetu me
Ner f the rapid prototype is tried when the client and users experiment with the rapid iO
1lion
prototype. For example, if every user selects Screen J from the m enu at least once but
'
j
'red no one ever chooses Screen B
,
then the development team should ask the client about i
; UP those two screens. Specitically, the developers need to know whether Screen J is so ; i
are important that the design should minimize execution time for that screen and whether
ICSS Screen B even needs to be included in the product. If so, then at least one user should 1
E I
experiment with Screen B', it is vital that alI screens should meet the users' needs. !
. 1
t
'
.
1
1 :
Please purchase Image To PDF Converter on to remove this message, thank you.

'
l 'r
i ' .
i
t aoa < u A p T . p .@ @ Requirem en#s Phose
t
.
! .
'
.
lo.Ia @ ezztT-@ RIzNTzp R eq ulpz- exTs*.
1 N
othing in this chapter appertains to the object-oriented paradigm. It certainly is
t p reasonable to ask why this is so. After all, the title of this book is Object-orientedand
' ) Classical Software Engineering, and lack of material on object-oriented requirements
1 i appears to be a serious omission. .
' ; kq 1, ' )) The answer is that there is no such thing as obiect-oriented requirements
,
nor
1 should there be such a thing
.
The aim of the requirements phase is to determine
;g l
$ the elient's needs', that is, what should be the funetionality of the target system.
' I The requirements phase has nothing to do with how the system is to be built. It is
1 meaningless to refer to the classical paradigm or the object-oriented paradigm withinh l
; ; the context of the requirements phase, just as it is meaningless to refer to a classical
'
1 i ted user manual
.

The user manual describes the steps to be followedr or object-or en! $
r by the user when running the software product and has nothing to do with how the
i product has been built
. In the same way, the requirements phase results in a statement
) ' ! ,
. ,
l of what the product is to do', the way that the product will be built does not enterj ' l.
,
.
into it.
.
' .
Having stated categorically that there is no such thing as object-oriented require-1
ts it nevertheless should be mentioned that there is one way that the object-ë men .
h ! oriented oaradiem indeed can enter into the reuuirements ohase. Suonose that. as
2 q 1 * %.''' .k ;: .' ik ' l has been strongly recommended in this chapter
,
the requirements phase for a specificl ' 1 includes building a rapid prototype
.
As a consequence of writing the code.
,
i project
'
for the rapid prototype, the development team will acquire insights into the problem
: l
1 domain, including ideas as to what might constitute a class within the target software.
i That is
,
even if the rapid prototype has been written in a classical language like C or
Lisp, the team will become aware of the fundamental building blocks of the prod-

l uct to be constructed. Then, in the next phase, object-oriented analysis (OOA), this
l information can be of assistance in the tirst step of OOA
,
extracting the classes (seel
'
l Section 12.2). Other than this, the object-oriented paradigm does not play a role in1
he requirements phase. .t$
.
r . ;
j '
j .
i
l :
l
I 1*.14 A IR * @URM ET QAS: $TupYtl
.
i 1 Rzqulu M zwTs puAs:9 ! .
l è
'
l :! '
.
l ' ;' Many airline passengers have dietary requirements, and the majority of airlines en-
! ! deavor to provide food that meets their needs
. For example, given sufûcient notice,.
2
h
I j ; most airlines will serve vegetarian. vegan, seafood, Kosher. or Halaal meals, as well
'
i as diabetic. low-fat, low-cholesterol. low-protein, low-calorie, or low-sodium meals.
l A child's m eal alm ost always can be ordered

. Some airlines will supply lactose-freeI
.
'
; meals. Flight attendants are provided a Iist of the passengers who have requested
special meaI.% and their seat numbers', the special m eals then are served at the same
: r time as the regular meals.
! '
i
1
Please purchase Image To PDF Converter on to remove this message, thank you.
: '
.
. ; : j
'
1@.1* AIR GOURMET CASE STUDY: REQUIREMENTS PHME 3@@ 1
I
'
I
- '
Like almost all business decisions, a trade-off is involved in providing these spe- '; ji
al meals. The benefits include increased passenger volume and passenger goodwill; 7 lc
; I
after all, if an airline does not provide special meals it will Iose passengers to air-
S lines that provide them
. On the other hand, signilicant costs are involved in providing 1d
jspecial meals:
s ' :
.
1
1. The ingredients that go into special meals can cost more than those of regular I jI !

lr meals. I g 1
I . ie 2
.
Because relatively few special meals are served, there can be no savings via bulk i
1. purchases. 1
!s
r3. Few airlines prepare special meals in their ow n kitchens. lnstead, they contract
n
.
with outside caterers to provide special meals, which increases the cost further. g ë
tl ,
4. Each special meal has to be transported from a central kitchen to the airport 1d
5 here the relevant Qight originates; signihcant handling and paperwork costs are ! lw
e ,
.
involved in this process.lt
5 Frequently, a special meal is not consum ed by its intended recipient. For example, llr .
'
i !
q' if a passenger changes his or her Eight plans at the last minute or a connecting !
.
; 1
-
,- flight anives late, the meal will have been Ioaded on the original qight for which :l
L- it w as ordered. I k
i
LS 6. Even if a special meal has been ordered well in advance, due to human error it :
'
IC '
sometim es is not loaded aboard the correct aircraft. (

Le ' I
' Overall, however. most airlines have found that the benefits of providing special meals 1 'j
n E
,
far outweigh the costs. i $D
.
.
.
jA i
r Gourmet always prided itself on the high standard of the food it serves in ; qlr
iights, where its competitors currently provide at most q i 1
,
the air, even on those shorter1
-
,
.
just a small bag of tasteless peanuts. Up to now, Air Gourmet's proftability has been ' Eis ë
!
'
assured by a steady supply of air travelers willing to pay a slightly higher air fare to
re ,
'
s profit margins have l !enjoy gourmet food in the air. Lately, however, Air Gourmet
n .
been shrinking, and its executives are looking for ways to cut expenses. The high cost 1
,
'
of providing special m eals. combined with anecdotal evidence suggesting that only I ! E
.
a small fraction of special meals reach the passengers who ordered them, have made ! y ,

' special meals a tempting target for the Air G ourmet bean counters.
. )
'
E
Before taking any action, however, Air Gourmet management wants to obtain k

'
. .
j j
reliable data concerning the success or tailure ot the special meals program . Also. i y !
because the special meals are provided by outside caterers, som e Air Gourmet ex- : i l
( ë l
ecutives suspect that these meals may not meet the high standards of the regular Air ( .
' Gourmet food subject to quality control in the Air Gourmet kitchens. A passenger ''
:3
-
satisfaction survey therefore must be conducted to determine the perceived quality of 1
l '!e
, . special meals. Also, Air Gourmet executives need to know what percentage of special ;
11 meals are not loaded on the correct aircraft. ' i l
.
.
I l
S. ' As with most other airlines that serve special meals, 24 hours before each sched- ! t
-
the Air Gourmet reservation system is scanned for special j 1le uled qight the database ot
rd ' meal requests
.
Reports are generated so that the caterers can ensure that the special i
lle meals are transported to the relevant aircraft on time

.
Then, just after each takeoff, a
report for the qight attendants is printed onboard the aircraft. This report contains the ii
L
'
! l
I' j
j l
Please purchase Image To PDF Converter on to remove this message, thank you.
.
l
I 6 1
1
, 1 :
'
a%@ t H A p ' : R 1* * Requirem enfs Phose
i reservation identilier, name, and seat number of each passenger onboard that flight
!
who ordered a special meal and the type of that meal. (Passengers are required to)
. -
show some torm ot identification before boarding a flight. Thus, the flight computer!
:
has the information needed to print this report.)
I
i
.
. To obtain the information requested by management regarding special meals,1
1 certain modifications have to be made to the Air Gourmet software. First, each time a ,
'
j :' special meal is ordered

,
the following information must be recorded: the reservationl
ï l identitier; tlight number, date, and time; passenger name and address', and type Of i
l I special meal ordered. This information will be used by the new software to be written .
I E to analyze the special meals data. Second, the list of special meals printed onboard theI
: aircraft will include a column of squares. Flight attendants will shade in the square if)
i the relevant meal has been loaded onboard the aircraft
. After the iight, the list will! l
'
; be scanned. lf the square has been shaded and the passenger was onboard the aircraft,
' i d bearing the reservation identifier will be mailed to the passenger askinga oostcar
j him or her to rate the meal on a scale of l (unacceptable) through 5 (superlative).
l h d is returned
,
it too, w ill be scanned and the reservation identifier 'W hen t e postcar
,
,
1 '
! and response recorded for later reporting.1 ! 'rhere thus are three separate sequential stages for the special meals analysis
1
i : j software: the additional records generated 24 hours before departure, the scanned
. j ' lists, and the scanned postcards. The formats of the recorded data elements are asl
follows (optional fields are in bracketsl: ': . rl
.
1
I i '
.
Reservation identifier (6 uppercase letters)
.
i Flight number (3 digits, right justified and zero filled)

y Flight date (9 characters: z-digit day, 3-uppercase letter month, 4-digit year)
i seat number (3 digits
,
rightjustilied and zero filled, followed by an uppercase. (
i letter)
-
l
j Passenger name:
' '
j ''''''''
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''d
.
, First name (up to 15 characters)
'
gMiddle initial ( l characterllI
I Last name (up to l 5 characters)
i gsuffix (up to 5 charactersll
i P
assenger address:
.
l
j 1 ; First Iine of address (up to 25 characters)
i j '
I
I I (Second line of address (up to 25 charactersllI i
!
j ; J City (u# to 14 characters)
! ; 7
.
; (State, province, or region (up to 14 charactersll '

' ! : (Postal code (up to 10 letters, digits, hyphens, and blanksll '
; ' ç
'
I Country (up to 20 characters) :
1
ë j Special meal type (child, diabetic, Halaal, Kosher. lactose free, low calorie, low
i cholesterol, low fat, low protein, low sodium, sea food, vegan, vegetarian)
I
Was the passenger on board the flight? ( l character)
; '
7
: '
,
Please purchase Image To PDF Converter on to remove this message, thank you.
l
'
! k II
'
:
'
)
'
'
.
I1*
.:5 AIR GOURMET CM E STUDY: RAPID PROTOTYPE 3l1 r
I
l
tt was the special meal loaded? (1 character) I
o perceived meal quality (1 through 5) 1

'''
The new software must enter information from the database and allow the us
-
er
l
I; to select from the following four reports
. For each report, the start and end dates tor ,
'
be obtained from the user. la that report must
! In Il
.
For each special meal type and for the special meals program as a whole: 1
lf , !l
n Percentage of special meals loaded as specitied; p
.
l
Le Percentage of passengers onboard the tlight for which they ordered a : 2
I
if ecial meal '
.
:
(sp
11 ' P
ercentage of passengers onboard the flight for which they ordered a r
t !'
special meal but whose meal was not loaded. ! 1
g i I
)' The customer Relations Department requires the following reports:
lr
l

2. The name and address of every passenger whose special meal was not loaded t : '1
i
.is more than once within the time period of the report, and the dates of occurrence. '
td . 3 The name and address of every passenger who felt that the quality of his or her
:
'S : special meal was less than superlative (5 on the scale), the date of occurrence, t ;
'
: 2
and the m eal type.
.
:
The outside caterer who provides the low-sodium meals has her own quality control i j
program. To assist her, the following report is also required: !
l
! ; i4
. For each low-sodium meal served, the flight number and date, and perceived meal ;!
quality. '.
T .
Air Gourmet management is greatly concerned about the risks of modifying its j I
existing computer system to incorporate this additional functionality. Also, manage- !
ment is reluctant to purchase the various scanners until the new product is complete. l .
I
Accordingly, it would Iike a keyboard-driven, stand-alone product to be constnlcted .
that will enter reservations, check in passengers, scan lists of special meals printed 'I
l:
'
.
on board (this is to be simulated by keyboard inputl', scan postcards (also keyboard , :
input), and produce the various reports. As a further precaution against premature 'i i
changes to the existing computer system , Air Gourmet management decides to hire I j g

.
.
I
an outside software organization to build the stand-alone product. ; )
1I i
p i
:
I
.
1
j
. .:
1*.15 AIR G@URMET CASE STUPY: pIp ! j' )
PROT/TTPE '
, 1
w :Notwithstanding the care taken when interviewing Air Gourmet management and
2 lstaff to determine their requirements accurately
,
the only way to be sure the final I)
'
-
l
product indeed will meet the real needs of the client is to build a rapid prototype. ii
;
'
t I
k :
'
' j !
$ i

i
Please purchase Image To PDF Converter on to remove this message, thank you.
:
'
i
1
- -
l
1
a12 t H A p T E R 4* * Requlrem en's Phose
'
The only languages available on the computer to be used for the Air Gourmet
product are C, C++, and Java. lf the product is to be im plemented in C++, it is
, r appropriate to write the rapid prototype in Java, an interpreted language. However, the
'
j danger is that the implementation team will convert the Java rapid prototype into C++ ')
ê I d add additional functionality
,
notwithstanding the problems of the resulting build-, I an
and-fix model (Section 3. 1). On the other hand, if the product is to be implemented in?
'
: .Java
,
neither C or C++ is a particular good alternative. Of the two, C probably is thei
; : better choice
,
because then the rapid prototype will have to be com pletely rewritten
.
! i in Java; if c++ is used
,

again, the implementation team might convert the rapidEl
rototype (this time from C++ into Java) and modify it, instead of implementing thep P
!
1 production-quality version from scratch.
! The C and Java rapid prototypes are available at www
.
mhhe.com/engcs/1 1
.
;
.
compsci/schach. The code generally is straightforward. Nevertheless, three aspects E
i need to be discussed here
.
'
'
j
j A portion of the C rapid prototype is shown in Figure 10.4., the corresponding
'
l tion of the Java rapid prototype is show n in Figure 10
.
5. First, as shown in FigureI ) por
' l 0.4 or 10.5, up to l 0 passenger records are stored in an array. In the delivered .l ! duct
,
a data structure that allows for a variable num ber of passengers is needed.
.
: pro
! For example, a file or a dynamic data structure could be used. In the rapid prototype, :
) however, an array is used because it is easy and quick to implement, and the rapid 1
' ! 1 be tested with a small number of passenger records
.

Analogously, up i
.
I I prototype canl
! . to 20 night records are stored in another array; this also is reflected in Figures 10
.4 .
! . j
and l 0.5. .
'
i The second im portant aspect of the rapid prototype is that it is unfinished
.
For' 1 !
i example. only two of the six reports have been implemented, the report on low-
i sodium meals and the report on meals onboard the iight. This is because the other .
four reports are similar to the two that are implemented. These four reports are coded
'
as stubs, that is, dummy routines consisting of an interface but with no body; theyjust )
display a message when invoked. One instance of this is shown in Figures 10
.4 and ;
.
l
I , 10.5. Omitting the body of these routines speeds up development of a rapid prototype ;
'
I ithout signilicantly detracting from its functionality
.
:, W
' . i 11 the user interface of the rapid protot
ype is menu driven; this is im plicit! F na y,
.
: ' in the last line of Figures l 0
.4 and 10.5. A menu-driven interface certainly is notI

.;
as elegant as a graphical user interface, but it has two advantages. First
, in rapidi
,
; prototyping, the emphasis is on speed. Unless a powerful GUl generator is available,
'
I q
!i E
.! i
j E i #define NUM-FASSENGER RECORDS 10! #define NUM FLIGHT RECURDS 20
;
.; slrud passenger-fype possenger-recordsINUM-PASSENGER-RECORDSl;
! slrud fliqhtrecord
-
type fliqht recordsgNuM FLIGHT RECORDSI;
' '
j ''''''' * ''
'
''''''' - '''
'
''''''''' '''''''''
'
'''' '
,
1 prinùf (''y tq t 2: HOUR CATERER LISTq ny n''); '
.h 1
printf ('zy q t This report is not implemented in the rapid prototypey ny ny n''),.i
printf ('' Press <ENTER> to return fo the menu '?);
2'
j '

Fl ur@ 1@.4 Forfion of the C rapid prototype for the Air Gourmet product
.
I , %
1
i .
.
1
.
Please purchase Image To PDF Converter on to remove this message, thank you.
.
' j
'
; . j(
.
.
l
1*.1* CHALLENGES OF THE REQUIREMENTS PHM E 3X3 !
I
.
l
met public stokic fincl int NUM
-
FASSENGER RECORDS = 1O, I
it is ! public sioik finol int NUM
-
FLIGHT
-
RECURDS = 20,. ( j
the r j; publk stoiic Cpassenger passengersl) = new Cpassenger ENUM
-

PASSENGER
-
RECORDS);++ :
!
public sfclk CFlightRecord fltRecsl) = new CFlightRecord INUM-FLIGHT-RECORDS);ild
-
. , . .
(
d in ,' ag HouR CATERER LIsTy ny n'') . 2 tsysiem
.
out.println ( , jth
e . System.out.println (z' This report is not implemented in the rapid prototypey ny ny n''); l I
tten system.out.println ('' Press <ENTER> to return lo lhe menu. . .''); '' 1i
: Itpid
.
( j
the Flvuye 1@.S Fortion of the ropid prototype for tFe Air Gourmet product. ; !' k
,è
'
ë
; ',
Ics/ : j
ects l
it usually is quicker to code a simple menu-driven user interface. Second, a GUl often l
ling is hardware-operating system dependent. lf the delivered product is implemented on j
ure a hardware-operating system platform significantly different from that on which the I4
. . - - - . - . -
p
lred rapid prototype was run, tllen the t.jul may llave to be relmplemented lrom Scratch, ! :
ing additional cost and time. For both these reasons, it often is better to build l lEled

.
Consum
.
1
e a rapid prototype with a sim ple textual user interface. Decisions regarding more I8'P
,
'
e cycle. 1
.àpid elaborate user interfaces can be made later in the lit ,
!
'
,
UP ;
l 0 4 L 1
i I
:
'
.
j
'
For i I
:
1 lOW
'
1*.1* ZHALLKNG': @F THE R EQUIREM ENT: P HM E , l
ther ) $
'
:
'ded I
-ike every other phase of the software development process. potential problems and !

jtlst itfalls are associated with the requirements phase. First, it is essential to have the 4 ;P
ë !and
wholehearted cooperation of the potential users of the target product from the be- ' ' !
Eype ' inning of the process
.
lndividuals often feel threatened by computerization, fearing ! 'g
:
,
ithat the computer will take their jobs
. There is some truth to that fear. Over the past
licit ' f terization has been to reduce the need for un- ) 7' . 30 years or so, the impact o compu :
nOt skilled workers but also to generate jobs for skilled workers. Overall, the number of i .
I ; rapid
well-paying employm ent opportunities created as a direct consequence of computer- ; k
tble, ization has far exceeded the number of relatively unskilled jobs made redundant, as ! 1
' i i: evidenced by both decreased unemployment rates and increased average compensa
-
: é l
tion. But the unparalled economic growth of so many countries worldwide as a direct I !
f I
: or indirect consequence ofthe so-called Computer Age in no way can compensate for ! j
' the negative impact on individuals who Iose theirjobs as a result of computerization. ' j t
: lt is essential that every member of the requirements analysis team be aware at ; ;
.
!
11 times that the members of the client organization with whom they interact in alI : ! l
:
a
' k
'

t
.
probability are deeply concerned about the potential impact of the target software j j
; product On theirjobs. ln the worst case, employees may deliberately give misleading j l
1 or wrong intormation to try to ensure that the product does not meet the client's needs ! :
' d hence. protect those employees' jobs. But, even with no sabotage of this kind. ian , j
som e mem bers of the client organization may be less than helptul sim ply because j 1
they have a vague teeling of being threatened by computerization. k !
l l
'
j
'
.
j
.
l
Please purchase Image To PDF Converter on to remove this message, thank you.
i
i I .

1- : , i.
1 l
I a%* t H A p T : R 1* * Requirem en's Phose
1 A
nother challenge of the requirements phase is the ability to negotiate. For ex-
ample, it often is essential to scale down what the client wants. Not surprisingly
,
almost every client would love to have a software product that can do everything that
' j might conceivably be needed. Such a product would take an unacceptably long time
j to build and cost far more than the client considers reasonable. Therefore, it often

i is necessary to persuade the client to accept less (sometimes far Iess) than he or she
j wants. Computing the costs and benetits (see Section 5.2) of each requirement in
I dispute can help in this regard.
' j Anotherexampleof the negotiating skill needed istheabilityto anive atacompro
-1 mise among managers regarding the functionality of the target product
.
For example, '1
acunning m anager may attempt to extend his or her power by including a requirement1
.
g that can be implemented only by incorporating into his or her areas of responsibility
1 certain business tknctions currently the responsibility of another manager. Not sur-
1 prisingly, the other manager will object strongly on discovering what is going on. Thej '
requirements team must sit down with both managers and resolve the issue.1
! A third challenge of the requirements phase is that, in many organizations, the
I I 1 .
.
individuals who possess intormation the requirements team needs to elieit, simplyl l lack the time to meet for in-depth discussions
. w hen this happens, the team m ust;
j inform the client, who then must decide which is more important, the individuals'
) f current job responsibilities or the software product to be constructed. And, if the
j! l t client fails to illsist that the software product eomes first, the developers may have no
I ', 11
: alternative but to withdraw from a project all but doomed to failure.t '
' '
! y'inally
.
flexibility and objectivity are essential for requirements elicitation. lt is
; p vital that the members of the requirements team approach each interview with no
1 j '
y preconceived ideas. ln particular, an interviewer must never make assum ptions about

'
the requirements as a result of earlier interviews, then conduct subsequent interviews
within the fram ework of those assumptions. lnstead, an interviewer must consciously
suppress any information gleaned at previous interview s and conduct each interview
in an im partial way. M aking prem ature assumptions regarding the requirements is
,l dangerous'
,
making any assum ptions during the requirements phase regarding the .
ft to be built can be disastrous. 'so ware
t
1
:
) How To PKRFORM THz RzqulR- zNTs PHAS:I
; !
2 t
i ! '.
Requirements elicitation:: i
'
'
'
.
. Build a rapid prototype that incorporates the key) * lnterview members ot the client organization and
.
E
.
tunctionality of the target product.2 d
etermine their needs.
. . M odity the rapid prototype in response to feed-
'
! ' Requirements analysis: b

ack from members of the client organization who;
.
t . oraw up the preliminary requirements uocument
.
experimented with it. ,
1
7 * Rcfine the requirements document.
h
p
'
l
; 1
t 1(
-
( .i
,
p
.
Please purchase Image To PDF Converter on to remove this message, thank you.
:
'
I
l'
j
FoR FURTHER READINO a4s
.
1
2
l
Il)(

- lI
y, QHAPTER Rzvlzw , l
11at
I
ne The chapter begins with a description of requirements elicitation techniques (Section II
en 1 0. l ), followed by an outline of requirements analysis (Section 10.2), summarized in ; I
he the box on page 3 1 4. A careful definition is given of rapid prototyping (Section 10.3). l'
j
'
in The importance of taking human factors into account when designing user interfaces I l
' jis discussed in Section 10
.
4. The use of rapid prototyping as a specilication tech- l
ro- nique is discouraged in Section 10.5, as is reusing a rapid prototype in Section 10.6. ; t
.le, Managem ent implications of the rapid prototyping m odel appear in Section l 0.7. f
!
mt : Experiences with rapid prototyping are discussed in Section 10
.8. Techniques for re- i E '
ity quirements elicitation are discussed and compared in Section 10.9, as are techniques I
ur- . for requirements analysis. Next are presented ways of checking the rapid prototype p
'he (Section l 0. l 0), CASE tools for the requirements phase (Section l0. 1 1), and metrics (
for the requirements phase (Section I 0. 12). The chapter concludes with a discussion E 1
: , 1
;he of whether there is an object-oriented requirements phase (Section l 0. l 3)., the re- 1
.
l
?ly , quirements phase of the Air Gourmet case study (Section 10. 14). including the rapid ;
ust prototype (Section I 0. l 5)., and challenges of the requirements phase (Section l 0. l 6). i
.
: j

ls' I
!Ae
i
no :
l
I
:is yop FupTuzp Rzaplxo E: ii
no ;!
Jut . . : ' EBooks on requirements analysis include (Gause and Weinberg
,
1990, Davis, 1993, and
WS Jackson
,
19951. t'rhayer and Dorfman. 19991 is a collection of papers on requirements i
j ;S y
analysis. The strengths of paper prototypes are discussed in glkettig, 19941. Articles ;
WW on the requirements phase appear in the M ay 1 995 issue of the Communitxltions l
; is ' i
of the ACM and the March/April 1998 issue of IEEE Software. The use of cost-
u mLHC: beneht analysis in ranking requirements is described in gKarlsson and Ryan
,
19971.
The December l 998 issue of the Communications ofthe ACM contains a number of
articles on requirem ents tracing. g9
.For an introduction to rapid prototyping, suggested books include gconnell and j
Shafer, 1 989*, and Gane, l 9891. The February I 995 issue of IEEE Computer contains !
: a num ber of articles on rapid prototyping. The report on the use of rapid prototyping ! i
:
in 39 commercial products is an extremely useful source of information (Gordon and . !$
Bieman, 19951. (Lichter. Schneider-l-lufschmidt, and Ziillighoven, 1994) give details ' , ;

of five industrial software projects in which prototyping played a major role. The ! k 'j
id prototyping model is one version of rapid application development (RADI; a l i irap l I
variety of articles on RAD appear in the September 1995 issue of IEEE Software. 2i
Human factors are discussed in (Dix, Finlay, Abowd, and Beale, 1993., Brownes .
,
jl
:1994., and Preece, 19941. (Nielsen, 19931 describes how user interaction with a user h
: 1interface can signiticantly improve usability. (Myers and Rosson, 19921 point out that
i
up to half the total software effort can be devoted to portions of the product related :
l lto the user interface
. 1
7
: : 7
.
)
.
) :
i i
Please purchase Image To PDF Converter on to remove this message, thank you.
l .
i
1
1
1 . a1@ t H A p T : R 4* @ Requiremen's Phose
1
1 Articles on user-interface design can be found in the April 1993 issue of Com- ! !
munications of the ACM. gGentner and Grudin, 19961 analyze models underlying .
user-interface design. The July/August 1997 issue of IEEE Software has a number
of articles on user intedaces, especially tsears and Lund, 19971. A elassic work on

user interface design is (Shneiderman, 19971. Usability of software is the subject of
.12
a collection of papers in the May 1999 issue of the Communications of the ACM.
1 The proceedings of the Annual Conference on Human Factors in Computer Systems
l
I (sponsored by ACM SIGCHI) are a valuable source of information on wide-ranging
1 aspects of human factors
.1 lz
I
14
j
'
'
'
,
!
I
i PR@RKZM S IS' j
5 '
,
'
' j
l 10
.
1 You have justjoined Victoria & Niagara Software as a software manager. Victoria &E
.
i
l Niagarahas been developing accounting software for sm all businesses for many years,
) Jl
using the waterfall model. usually with some success. On the basis of your experience,1 j l

, 1 you think thatthe rapid prototyping model is a far superiorway of developing software
.
1*l - 1 -
i W rite a report addressed to the vice-president for software development explaining
why you believe that the organization should switch to the rapid prototyping model.
Remember that vice-presidents do not Iike reports more than one page in length.
. k
i 10.2 You are the vice-president for software development of Victoria & Niagara. Reply to
the report of Problem l0. l .
I
10.3 Of the programming languages available to you, which should not be used for rapid '
t prototyping? Give reasons for your answer.
10.4 Describe a project in which rapid prototyping is unlikely to be of much assistance to '
the development team . :
10.5 Section 10.3 stated that rapid prototyping is particularly effective when developing!
j the user interface. Under what circumstances is there an equally effective alternative
1 way to determine the client's needs in this regard?
1
: 1
i ! 10.6 Under what circumstances does it make sense to refine a rapid prototype?
1 ! '
i . 1 O.7 W hat is the result if a rapid prototype is not constructed rapidly?l
q
7 :
, .
10.8 Should rapid prototyping be used if the product is to be developed using the object- :
1 oriented paradigm?
I1 :
1 10.9 (Term Project) Construct a rapid prototype for the Broadlands Area Children's Hospi-
1 tal project in Appendix A. Use the software and hardware specified by your instructor.I

I 1 0.10 (Case Study) Starting with the requirements of Section l0. l 4. construct a rapid pro-
! in an interpreted language such as Lisp
,
Sm alltalk, or Perl.totype
j '
! '
. i
Please purchase Image To PDF Converter on to remove this message, thank you.
'
$
.
' j
,
.
j '. i
' '
j
' jR
EFERENCES a1y !
'
'
j'
t
'
)
.1 1 (Case Study) Suppose the rapid prototype for the Air Gourmet product has been I
written in C and the production-quality implementation is to be written in C++ . ; )
. .
i ;
Because C is syntactically a subset of C++, how would you prevent the rapid proto- ' l r

t e from being rehned into the delivered version of the product? q !
.
YP : )
1Q (Case Study) Suppose the rapid prototype for the Air Gourmet product has been '#
.
ity im plem entation also is to be written in iwritten in Java and the production
-
qual r
Java. How would you prevent the rapid prototype from being refined into the delivered '
.
1 ;
' version of the product? 1:
.
.13 (Case Study) lf the software is available to you, add a graphical user interface to the ! ' .1
q '
rapid orototvoe of Section l0. 15. I
' A
.t ''''
d
't
j' g
.14 (Case Study) ln the rapid prototype ot Section I 0. l 5, arrays of records are used to ; I
Store passenger and flight records. W as this a good decision on the part Of the rapid !
j' t
'
:
prototyping team? To supportyouranswer, recode the rapid prototype using a dynamic f ': i
data structure. k i
.
k

'
.
15 (Case Study) A number of the routines of the rapid prototype of Section I0. 15 are j
empty. For example, the routine to print the report containing the name and address ') i
' jof every passenger whose special meal was not loaded more than once has not been 2
' ; j i
coded. W as this a good decision on the part of the rapid prototyping team? To support
y ; r
your answer, com plete the bodies of the empty routines. ! !
l .
.1ô (Readings in Software Engineering) Your instnlctorwill distribute copies of gKarlsson ë
. ; ;
'
and Ryan. 19971. How could Karlsson and Ryan's approach be extended to a complete ' I
life-cycle model based on cost-benefit analysis? , ,
i : '
'
i 1!
, .i ! '
'
j i '
l i
.
j )
RzFzpzxezs gl
E !
l(Boehm
,
Gray, and Seewaldt, 19841 B. W. BOEHM, T. E. GRAY, AND T. SEEWALDT, j
T'Prototyping versus Specifying: A Multi-project Experiment.'' IEEE Transactions on 1 ë

Software Engineering SE-IO (May I 984), pp. 290-303. E
(Brooks, 1 9751 F. P. BROOKS, JR.s The M)'//Jït,w/ Man-Month: Essays On 5k#àli'are' ''
Engineering, Addison-Wesley. Reading, MA, 1975. Twentieth Anniversary Edition, j ' I
Addison-Wesley, Reading, MA, 1 995. 'j ' i1
(Browne, l 9941 D. BROwNE, STUDIO: STructured User-interface Designfor Interaction j ; (
'
Optimization, Prentice Hall, Englewood Cliffs, NJ, l 994. )
. j
1
(Capper, Colgate, Hunter, and James, 19941 N. P. CAI/PER, R. J. COI-GATE, J. C. HUNTER, AND @ I' 1 1 I
) V. F. J AMES, ivhe lmpact of Object-oriented Technology on Software Quality: Three ' 1.
Case Histories,'' 1BM k&v.î/c/'?1.ç' Journal 33 (No. 1 , l 994), pp. I 3 l -57. ' ''
,

) l
(Connell and Shafer. l 9891 J. L. CONNELL AND L. SHAFER. Structured Rapid Prototyping: An l I
Evolutionary ztppmlc/l to sk//warc Development, Yourdon Press, Englewood Cliffs, NJ. r I
E Il 989
.
.
j j
I Davis, 1 9931 A. M. DAvls, Software Requirements: OWdcls', Functions, and States. rev. ed., : k I' ''
' ' ' ' ' ë (
'
. Prentice Hall, Englewood Cliffs, NJ, l 993. 1 l
J à
'
'
1 'i I
'

.
j l
1I
:
l '
'
; '
I l I
Please purchase Image To PDF Converter on to remove this message, thank you.