Page 148 - Software and Systems Requirements Engineering in Practice

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
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 115 115

4.8 Transitioning from Analysis to Design
At some point, we may be interested in taking an analysis model, and
creating a design model from it. We must ensure that traceability is
maintained from analysis to design, where the development effort is
relatively straightforward, with the target hardware and/or software
platform known in advance. A good starting point for design
heuristics can be found in the Design Patterns text by Gamma et al.
[Gamma et al. 1994], and the text on Design Heuristics by Arthur Riel
[Riel 1996]. Note that the heuristics described here are primarily for
software components.

4.9 Suggested Model Conversion Heuristics

We will start with some important low-level heuristics and then
describe some high-level heuristics/guidelines.

Design Model Package Structure
The design package structure will resemble, but not be exactly the
same as, the analysis structure. This is because the analysis views
mirror the problem, whereas the logical views show the design of the
solution to the problem.

Use Case Tracing
Use case tracing can be done with “off the shelf” CASE tool
techniques. A concrete use case in the analysis model MUST be
realized by one or more use case realizations in the design model.
2
The use case realization then becomes a subsystem, set of components,
etc., further down in the model (see Figure 4.24).

Interface Tracing
Interface tracing is illustrated in Figure 4.25. In general, a boundary
in the analysis model will be realized by one or more interfaces in the
design model.

Artifact Tracing
Tracing between the analysis and design model elements can be done
using the “<<realize>>” stereotyped association. Table 4.3 lists the
most important elements and their relationships.

2 “Realized” is UML terminology meaning “implemented by.” In the UML the
arrows are drawn from the solution back to the problem definition (requirements)
and the stereotype of the line is “<<realize>>.”