Page 104 - Software and Systems Requirements Engineering in Practice

74 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

“‘What is the use of a book,’ thought Alice,
‘without pictures or conversations?’”
—Lewis Carroll, Alice’s Adventures in Wonderland, 1865
“A picture shows me at a glance what it takes
dozens of pages of a book to expound.”
—Ivan Turgenev, Fathers and Sons, 1862

4.1 Introduction
As products become more complex with increasing functionality, it
becomes harder to describe and understand their requirements.
Furthermore, some product concepts that may be easily represented
by a picture can become extraordinarily difficult to comprehend
when transcribed to text. A good example of this is a bicycle. Its
design is easily understood when viewed as a picture, but incredibly
complex and difficult to describe textually. Pictures may be used in
different ways; for instance, they may precisely describe something,
or they may describe an abstraction of something. An abstraction is
defined as “a mental representation or concept that isolates and
generalizes an aspect of an object or group of objects from which
relationships may be perceived” [White et al. 2002]. When a set of
related pictures are combined such that the objects contained in the
pictures are stored along with their relationships, a model is created.
The associated pictures are then views into the model.
In Chapter 2, we discussed the basics of requirements engineering
artifact models to help define the product development life cycle, or
processes used to build a product. In this chapter, we discuss models
that help describe the product itself.
Models require work and skill to produce. Consequently, there is
always a rationale for creation of a model. For example, a fault tree is
a model that graphically represents the interactions of failures and
other events within a system. A fault tree may be mandated when
there are hazards associated with a system, and an analysis is
necessary to determine that there is no danger to the users of the
system or the environment. Sometimes the use of such a model is
mandated by regulation (e.g., medical devices).
Models can be created at different levels of abstraction for different
purposes. In software, a business model can describe why a product is
needed. A feature model then describes the features of a product being
created to enable the business model. A requirements analysis model
then explains the features in sufficient detail to define product
specifications. A design model illustrates the architecture for the product.
An implementation model describes the construction of the product (for
software, the actual source code is the implementation model). Finally,
a test model would describe how the product would be tested
(see Chapter 8 for more information on test models). All these models