Page 119 - Software and Systems Requirements Engineering in Practice

88 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

product features need to trace to test cases. If organizational barriers
prevent the creation of those traces, then an organization may not be
mature enough to support MDRE. MDRE does require skilled staff,
and that means training, mentoring, and broad experience across the
life cycle. We have also seen situations where business analysts who
have been using text-based elicitation and analysis techniques were
very apprehensive about trying new methods, especially techniques
with which they would be working at a novice skill level.
Another organizational issue is that of finding the right first
project. As MDRE techniques might not work as well as desired the
first time they are used, a small, noncritical first-time project would
be best. Sometimes organizations are in constant “fire-fighting” mode
and cannot spare staff to try something new.
“Begin at the beginning”, the King said, gravely,
“and go till you come to the end; then stop.”
—Lewis Carroll, Alice’s Adventures in Wonderland, 1865

4.5 MDRE Processes
MDRE processes include requirements gathering activities up to but
not including design, where the focus of the elicitation and analysis
activities is model creation and utilization. That includes, for example,
goal and feature modeling activities, hazard analysis, threat modeling,
and requirements elicitation and analysis using models. Depending
on the sophistication of the modeling tools used, a full implementation
of the URML would permit an organization to do most of its RE
activities with a URML, generating artifacts such as documents or
requirement specifications as needed on an ad hoc basis. If less
sophisticated tooling is used, or more traditional tools are used for
storing requirements, a traditional process modeling tool (e.g., IDEF,
UML, etc.) can be used for process modeling. In this section, we will
start with a holistic view of MDRE processes, and then later in the
chapter, we will provide step-by-step guidance for model creation
during elicitation and analysis. We use the UML as a starting point
because of its acceptance and available tool sets. It must be noted that
limitations of MDRE are often imposed by the tools used. Since the
focus of the MDRE effort is the creation of models from which high-
level requirements can be extracted, tools must enable whatever
techniques are used. Where tools cannot provide the needed
functionality, then customization or the additional use of other tools
may be necessary.

Initial Understanding
In the beginning of a project, we would like to know why a system or
product is being built. There are, of course, conflicting points of view