Scope considerations
Create a single instance of the Goal-Service Model to cover all business domains within the scope of the project.
Given that subject matter experts might be experts in a specific business domain, an iterative approach can be used to
focus on one domain at a time to make interviews or work sessions more efficient.
During Goal-Service Modeling interview or work sessions, consider the knowledge areas that the subject matter experts
can speak to. For example, it might be possible to capture some initial statements of non-functional requirements in
parallel with this task. This can provide valuable input into other more detailed requirements gathering sessions.
Goal modeling considerations
In the same way that goal modeling can be performed either in a UML environment (see Guideline: Defining Business Goals ) or in a requirements management environment
(such as IBM® Rational® RequisitePro®) the modeling of relationships between services and goals can be performed in either
environment. However, it is important to ensure that all leaf-level goals are supported by one or more services, and so
traceability information is critical. One way to present the model for review is to represent it in a tabular form, as
shown in Table 1, which clearly identifies any goal unsupported by services.
Table 1. Present services support of goal
Goal or sub-goal
|
KPIs
|
Metrics
|
Services
|
1. <Goal>
|
<KPI>
|
<Metric>
|
<Service>
|
1.1 <Sub-Goal>
|
<KPI>
|
<Metric>
|
<Service>
|
1.2 <Sub-Goal>
|
<KPI>
|
<Metric>
|
<Service>
|
2. <Goal>
|
<KPI>
|
<Metric>
|
<Service>
|
2.1 <Sub-Goal>
|
<KPI>
|
<Metric>
|
<Service>
|
|