Page 105 - Software and Systems Requirements Engineering in Practice

:
R e q u i r e m e n t s M o d e l i n g
h
a
C
4
r

e
p
t
C h a p t e r 4 : R e q u i r e m e n t s M o d e l i n g 75 75
must be interconnected for a variety of reasons (see the section on
traceability in Chapter 7).
Models may have varying degrees of formality, depending on
their use. Models for safety-critical systems (see Chapter 11) tend to
be very formal. A formal model is one where the semantics for model
construction are defined (e.g., a set of rules for creating the model),
and where criteria for determining the correctness of the model are
established. Most models are not formal. For example, software
developers creating designs in the Unified Modeling Language
(UML) or systems engineers creating designs with the Systems
Modeling Language (SysML) are usually not creating formal models
because there are no rules for model creation, and there is no way to
determine if the model is correct (determining correctness requires
validation against the rule set). The degree of formality and the way
the models are described vary depending on the domain and
experience of the team. For example, for many of the domains we
have worked in, models have been described in UML because of
specific applications and customers, but for embedded systems state
charts are often used.
Moreover, it is even possible to create a formal model by describing
objects and their relationships in a database without any diagrams or
pictures [Rugaber et al. 2001]. It is common, for example, to reverse-
engineer or create UML models (www.uml.org) by loading and
analyzing software source code. The model is contained in the objects
and their relationships.
Figure 4.1 illustrates the use of a conceptual diagram to show
abstraction. In it we see a boiler with water feeds, outlets, and valves.
This diagram alone is sufficient to understand how to install the
Parker boiler. Note that
• Minimal expertise is required to read the schematic.
• It conveys a great deal of useful information.
• It is simple enough that a viewer can easily comprehend the
content.
• It is coherent; that is, everything in the schematic is related in
a visible, understandable way.
When using models as part of an engineering process, one of the
objectives is to convey as much information as possible as succinctly
as possible. This is relatively easy to do in domains where each object
in a model represents something tangible such as a door, window,
capacitor, etc. However, how can the relationships among
requirements, hazards, product features, and business goals be
readily understood for a complex product with thousands of
requirements? Furthermore, unlike the boiler shown in Figure 4.1,
electromechanical and software components may have relatively