Page 110 - 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 79 79
and workstations. More recently, simplified modeling techniques
such as SysML have emerged to support systems engineering efforts
(www.sysml.org).
Video-based requirements engineering couples workflow models
with video streams. It is a relatively new field, enabled by advances
in video capture and editing techniques [Creighton et al. 2006].
The remainder of this chapter will focus on our experience with
process modeling techniques that have been successfully used on
Siemens projects to support requirements elicitation and analysis,
specifically model-driven requirements engineering. Sometimes the
two activities are confused because the same tool and physical model
(or files) are used; however, they take place at different points in the life
cycle. Elicitation is an activity accomplished with stakeholders to
determine what their needs are. In order to better understand the
context, a business model may be created that describes business
activities where a new product or set of services will be used. A
prototypical product may then be defined and refined, so that the
customer’s needs are better understood. Once a set of product features
is known, analysis modeling may take place to define in detail how the
product will be used. The Model-Driven Requirements Engineering
(MDRE) methodology described in the next section covers both business
modeling and analysis modeling activities, starting with business
activities and ending with the detailed interaction of users and the
proposed product or system in the same integrated physical model.

4.2 Model-Driven Requirements Engineering (MDRE)

We have used MDRE on Siemens projects because we have found
that, under certain circumstances, it is often a good way to effectively
manage the requirements for large and complex systems. On one
project, for example, there were over eight hundred use cases. Most
of those use cases described product functionality to be developed.
Consequently, tasks had to be placed in a project plan. Creating the
plan manually would have taken at least two weeks, with the risk of
human error (e.g., leaving out tasks). Using the MDRE tool set, the
draft project plan was created directly from the model for use by the
project manager in a matter of minutes, with associated hyperlinks
between the model use cases and the plan tasks.
MDRE uses models as an enabler for all requirements activities
and includes the use of modeling techniques for elicitation (business
modeling and use cases) and analysis (detailed descriptions of the use
cases). Initially, processes are modeled to better understand how a
product might support potential customer activities. For example,
when building a new underwriting system for an insurance company,
we would want to know what systems and roles the new system would
interact with; what kind of data was used, modified, and created; how
the underwriting information was managed; and what constraints the