SEKE 2012 Proceedings - Knowledge Systems Institute

should be verified for the possibility of deriving a new
use case;
o Guideline 12.1: A new use case will be generated
if a step represents an activity that requires several
steps to be concluded;
o
o
Guideline 12.2: If the new use case was derived
from a mandatory step, then it must be related to
the original use case through the “include”
relationship;
Guideline 12.3: If the new use case was derived
from an optional step, then it must be related to the
original use case through the “extend”
relationship.
Applying Step 3 to the MobileMedia example, we obtained
the description for the “Add Photo” use case (Table II).
TABLE II.
Use Case 1: Add Photo
CHARACTERISTIC INFORMATION
Primary Actor: User
Feature: Add Photo
Scope: MobileMedia
Pre-condition: -
Success Condition: Photo added to album
PRIMARY SCENARIO
“ADD PHOTO” USE CASE DESCRIPTION
ID User Action System Response
1 Select “Add Photo” option [Add
Photo]
2 Select album [Album]
3 Provide path of photo [Path]
4 Select photo to be added [Photo]
5 - Photo is automatically
saved
[Save
Automatically]
5 Choose for photo [Name] [Save by
User]
Photo is saved with the
chosen name
6 - List of photos is updated
SECONDARY SCENARIOS
RELATED INFORMATION
Non-functional requirements: Integrity [Photo], Accuracy [Path], Quickness
[Storage]
G. Use Case Scenarios Refinement
As it can be observed in Table II, the use case description
generated by the guidelines proposed in the previous activity is
not complete. The system response for some actions is missing,
as well as the secondary scenarios (exceptional and alternative
scenarios). This occurs because i* models are not meant for
modeling behavior or exceptions. Therefore, this activity is
required to complement the use case description.
The scenarios obtained on the previous activity may be
succinct or written on a very high level; it will depend on the
level of refinement achieved in the SR model. Hence, it is
suggested to refine scenario descriptions until they reach the
desired detail level. Due to the lack of space, the refined use
case description for our running example will not be presented.
At the end of this activity, the requirements phase of the
Domain Engineering process is concluded.
H. Product Configuration
This activity is a ctually a su b-process of the Application
Engineering process. It will be executed every time a new
product of the SPL has to be derived. This sub-process is an
adaptation of Lima’s Application Engineering process [11] and
its three activities are described as follows:
1) Choice of Specific Configuration
In this activity, the client chooses the goals to be satisfied
by the new product. There are two heuristics to guide the
configuration:
H1: All intentional elements with [1..1] cardinality
must be present in the product configuration model, if
their parent elements have been selected. Elements
with [0..1] cardinality might be present depending on
the stakeholders choices;
H2: Sub-elements of means-end relationships will be
present in the configuration model depending on the
stakeholders choices, but obeying the relationship
cardinality (if it exists);
Depending on the choices made by the client, there may be
more than one possible product configuration, called
alternatives. The SR model of each alternative will be analyzed
in the next activity. In our running example, there are two
alternatives: one with “Save Automatically” task (A1) and
another with “Save by User” task (A2).
2) Prioritization of Variants
In this activity, the alternatives previously obtained are
ranked based on the priority the client gave to the softgoals
present in the SR model. The priority given to a softgoal must
in the interval [0,10]. For each alternative, we have to take into
account the number of positive and negative contributions from
the elements of the SR model to the softgoals, considering also
the degree (e.g.: help, hurt) of each contribution. The formula
to calculate the priority of each variant will not be presented in
this paper due to the lack of space.
The alternative with the highest priority value represents the
most suitable configuration for the client’s desires. For our
example, if the softgoal “Quickness [Storage]” receives the
highest priority, the priority value for A1 will be 7,5 and for A2
will be -7,5. Therefore, the alternative with “Save
Automatically” feature is the most suitable for the client.
3) Product Artifacts Configuration
The purpose of this activity is the derivation of the artifacts
for a specific product of the SPL. First, the configuration model
is generated by eliminating, from the FM, all features that are
not related to elements in the SR model of the chosen
alternative. Then, all cardinality indications must be removed
from the SR model, thus the i* model of the product is
obtained. Finally, only use cases that are related to selected
features will be present on the product’s artifacts. The scenario
655