Page 109 - Software and Systems Requirements Engineering in Practice

78 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

• Aid in identifying potential hazards (to users of a product).
• Identify all possible users of a product and external systems,
and how each of them interacts with the system or product
under consideration.
Each engineering discipline and domain has its own standards
for design or modeling. In civil and mechanical engineering, for
example, blueprints are often used. More generally, the term
“blueprint” has come to be used to refer to any detailed plan. In
electrical engineering, there is the traditional circuit diagram. This
has been augmented in electronics design with standards for circuit
board design. In the software world, it is recognized that working in
the problem domain results in higher productivity and better quality
products than working at a low level (www.darpa.mil/ipto/
programs/hpcs/). When modeling for elicitation and analysis,
depending on where you are in the product development life cycle,
there are many different approaches to modeling (see Figure 3.4 in
the preceding chapter).
Goal modeling is used to define business goals and relate them to
needs and features (see “Eliciting Business Goals” under Section 3.3 in
the preceding chapter). Goal modeling can be done at any time, but it
is usually correlated with the definition of product features, to ensure
that the features are synchronized with business needs or goals. Goal
modeling is sometimes used to show nonfunctional requirements and
their relation to goals and functional requirements.
Feature modeling is a modeling approach normally associated with
defining product lines. The model shows all possible features in all
products in the product line, their dependencies, and their mutual
incompatibilities. Since an unconstrained feature model is generally
too broad in scope to be useful, the models are normally coupled with
product maps that identify which features are associated with
identified products. Feature models can also be used to identify
potential variations within a single product; e.g., user configurations.
Process modeling is typically used to show user workflows either
before or after a product is delivered (or sometimes at both times).
Some modeling techniques, such as the UML, are also used for
software design, as the diagrams that are used to show customer
processes can also be used to illustrate software processes. Unlike
Goal and Feature Models, which tend to be static representations of
structure, process models can show both static structures (e.g., the
structure of an organization) and temporal behavior (steps in
activities, changes in the state of an object over time, etc.). There are
many types of process models, including Integrated Definition (IDEF)
methods developed for military contractors [IEEE 1320.2-1998]. Other
techniques such as those of [Gane 1979] and [Yourdon 1988] enjoyed
some early success but were limited by the quality of the tools
available and the limited functionality of early desktop computers