Page 116 - Software and Systems Requirements Engineering in Practice
P. 116
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 85 85
Use case modeling has also been found to work well when
discovering requirements for service-oriented architecture (SOA)
systems [Lau 2004], and the use of modeling for SOA products seems
to have become the de facto approach for identifying SOA
requirements.
Models used for navigation work especially well when the models
are published to the Web, giving stakeholders unfamiliar with the
project a simple navigation guide for finding documentation. Each
organization, and each project within that organization, needs to do a
cost, benefit, and risk analysis to determine what aspects of MDRE
are desirable. Often, when evaluating methodologies, organizations
will focus on “the easy stuff”—such as “how do we write use case
documents?”—while ignoring the details that can cause problems
later during development. For example, a cross-cutting requirement
is a requirement that may impact several areas (or use cases). A
security requirement, for instance, may impact reports, user interfaces,
logon, etc. As the work products of MDRE are artifacts that can be
queried or mined, MDRE techniques tend to be better than traditional
natural language approaches for managing such cross-cutting
requirements.
MDRE can have significant advantages over other approaches on
large projects. Some of these are listed in the sections that follow.
Using MDRE to Estimate Project Size and Cost
Karner provides guidelines for creating function point estimates from
analysis models [Karner 1993]. His approach involves ranking actors
and use cases as simple or complex using a weighting system. A high-
level use case model is a good fit with function point counting. When
modeling, actors and use cases can be assigned weights based on
Karner’s guidelines. As the directed graph underlying the model is
traversed, “use case points” are summed up and converted to function
points for estimating cost. Note that this approach is not as simple as
it sounds; high-level models should be used, and the numbering
scheme for ranking use case and actor complexity needs to be applied
judiciously. That having been said, it is an excellent way to estimate
the cost of completing very large projects when the first project phase
includes an analysis model.
Improved Management of Cross-Cutting Requirements
Cross-cutting requirements are those that trace to or impact other
requirements in different areas. With traditional approaches, it can be
very difficult to manage change control with nonfunctional
requirements. It can, for example, be difficult to see how a new or
changed requirement impacts other parts of a system. With MDRE,
however, it is relatively easy, as the traces are visual, and since the
views are into a homogeneous model, it is easy to query for changes