Page 113 - Software and Systems Requirements Engineering in Practice

82 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

it was impossible to tell, from the model and the requirements derived
from the model, whether the resultant components would be hardware,
software, or firmware [Bradley et al. 1991].
The use of MDRE processes requires a significant amount of
up-front planning, skilled staff, and viable tool sets. The creation and
use of an MDRE process will be described in the following sections,
with a suggested set of modeling heuristics and best practices.
Results of the use of MDRE techniques are reported in [Berenbach
and Borotto 2006].
With MDRE, instead of using text as the framework for the
requirements in a project, models are used. In Chapter 2, we saw how
artifact models can improve the quality and productivity of RE
processes. When using MDRE, as many artifacts as possible are
generated from or stored in the requirements artifact model. For
third-party artifacts or objects that cannot be stored in or generated
from the model, traces are used to create hyperlinks (see Figure 4.3
and Table 4.1, later in this chapter).
All MDRE artifacts either are stored in a model or have a
placeholder in the model to represent them. Ideally, the textual
description for an artifact will be stored with the artifact. On demand,
the text can be extracted to a specification or transformed as needed.
External documentation such as standards and government
regulations are usually referenced via hyperlinks, which are object
links in the model. However, hyperlinks should be used with
discretion, as they can only point to a whole “something.” That is, a
requirement in a model referencing an external document via a
hyperlink can only reference the entire document. In order for the
links to be effective, they should ideally have a tighter granularity;
e.g., they should reference a paragraph or sentence.
The most commonly used tools tend to be disjoint. That is,
information is kept in different databases, with synchronization
requiring manual effort of custom programming. Keeping a model

Requirements Product Project
Database Features Plan

Project
Documents Analysis Test Plan
Model

Hazard Business Design
Analysis Goals Outline

FIGURE 4.3 The analysis model as a nexus for project activities