Page 155 - Software and Systems Requirements Engineering in Practice

e
m
e
q
e

M
C
h
s
e
n
t
r
:
R

4
d
e
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 121 121
n
g
l
i
p
i
u
o
a
r
• Develop process models that are understandable by viewers
who are not experts in the domain being described.
• Develop models that are coherent, with no holes or
discontinuities.
• For creating and viewing models, select tools that are easy to
use and enable processes, not cause difficulties.
• As MDRE techniques might not work as well as desired the
first time they are used, select a small, noncritical project as
the first pilot for MDRE.
• Understand how the model will be used and maintained after
completion—this defines what tools are needed and how
they are to be integrated.
• Have at least one person on the team to act as a facilitator
who has been through a complete MDRE cycle.
• Schedule modeling sessions in the mornings, three or four
times a week. At each session, the subject area to be modeled
is known in advance and the appropriate subject matter
experts or customers are scheduled into the meeting.
• As the modeling sessions continue, have no more than 5–8
people present. A projector is used so that everyone present
can see the model under construction or review. Sessions
should last no more than half a day.
• Avoid entering textual descriptions during modeling sessions,
as it significantly reduces productivity.
• Assure that the starting or context diagram for a model has
only a single entry point in the form of an abstract use case or
product feature.
• Define scope and identify “out-of-scope” domains as quickly
as possible, and color-code any high-level use cases that are
out of scope.
• Review all model diagrams for clarity and completeness.
• Create a Requirements Engineering Artifact Model,
identifying all possible traces or links and how they will be
maintained (during and after project completion), prior to
initial use of the RE tool set.
4.13 Summary
In this chapter, you have seen how the MDRE approach to
requirements engineering can be effective on large projects. We
believe that as projects increase in size and complexity, the use of
hierarchical databases for requirements storage and the review of
textual material may be inadequate to ensure a positive outcome.