Page 318 -

CHAPTER 11 ANALYSIS CONCEPTS AND PRINCIPLES 289

We have already noted that software requirements engineering should focus on
what the software is to accomplish, rather than on how processing will be imple-
mented. However, the implementation view should not necessarily be interpreted as
a representation of how. Rather, an implementation model represents the current
mode of operation; that is, the existing or proposed allocation for all system elements.
The essential model (of function or data) is generic in the sense that realization of
function is not explicitly indicated.

11.4 SOFTWARE PROTOTYPING

Analysis should be conducted regardless of the software engineering paradigm that
is applied. However, the form that analysis takes will vary. In some cases it is possi-
“Developers may ble to apply operational analysis principles and derive a model of software from which
build and test
against a design can be developed. In other situations, requirements elicitation (via FAST,
specifications but QFD, use-cases, or other "brainstorming" techniques [JOR89]) is conducted, analysis
users accept or reject principles are applied, and a model of the software to be built, called a prototype, is
against current and constructed for customer and developer assessment. Finally, some circumstances
actual operational
realities.” require the construction of a prototype at the beginning of analysis, since the model
is the only means through which requirements can be effectively derived. The model
Bernard Boar
then evolves into production software.

11.4.1 Selecting the Prototyping Approach
The prototyping paradigm can be either close-ended or open-ended. The close-ended
approach is often called throwaway prototyping. Using this approach, a prototype
serves solely as a rough demonstration of requirements. It is then discarded, and the
software is engineered using a different paradigm. An open-ended approach, called
evolutionary prototyping, uses the prototype as the first part of an analysis activity that
will be continued into design and construction. The prototype of the software is the
first evolution of the finished system.
Before a close-ended or open-ended approach can be chosen, it is necessary to
? What do I determine whether the system to be built is amenable to prototyping. A number of
look for to
determine prototyping candidacy factors [BOA84] can be defined: application area, application
whether or not complexity, customer characteristics, and project characteristics. 8
prototyping is a In general, any application that creates dynamic visual displays, interacts heavily
viable approach?
with a user, or demands algorithms or combinatorial processing that must be devel-
oped in an evolutionary fashion is a candidate for prototyping. However, these appli-
cation areas must be weighed against application complexity. If a candidate application
(one that has the characteristics noted) will require the development of tens of thou-
sands of lines of code before any demonstrable function can be performed, it is likely

8 A useful discussion of other candidacy factors—”when to prototype”— can be found in [DAV95b].