Page 120 - 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 89 89
as to why products are created. However, in software and systems
engineering, the view that counts the most is that of the stakeholder
paying for the system (or the requirements elicitation effort, if the
decision to build has not yet been reached). If it is at all possible, we
want to capture the early business goals so that when an impact
analysis is performed later in the project or design tradeoffs are made,
the rationale as to why a feature is in the delivered system is readily
understood. Looking ahead to Figure 4.14 we can see the context
diagram for a sporting event management system. Several of the
diagrams in this chapter use this system as a modeling example. Look
at Figure 4.14 first, then look at Figure 4.5. In Figure 4.5 we see a goal
model fragment showing some of the goals we hope to achieve in
creating a sporting event system (commercially desirable; e.g., make
a profit). The model shows that some business goals are in conflict,
that is, the goal of high reliability may conflict with the goal for a low-
cost system; those goals will need to be resolved. If a documented
goal cannot be in the model (e.g., the goal is part of a strategic vision
document), then at least a symbol in the model can trace to or reference
the original goal. Ideally, when viewing goals in the modeling tool or
a published web model, it should be possible to hyperlink to the goal
details.

Commercially Desirable Sporting
Event Management System
+ +

+

−
+
Low-Cost System
Easy to Use −
−
High Reliability

Feature Rich
FIGURE 4.5 Goal model fragment