=Paper=
{{Paper
|id=None
|storemode=property
|title=None
|pdfUrl=https://ceur-ws.org/Vol-586/iStar10-paper20.pdf
|volume=Vol-586
}}
==None==
https://ceur-ws.org/Vol-586/iStar10-paper20.pdf
Exploring Risk-Awareness in i* Models
Constantinos Giannoulis, Jelena Zdravkovic,
Department of Computer and Systems Sciences
Stockholm University
Forum 100, SE-164 40 Kista, Sweden
{cgia, jelenaz}@dsv.su.se
Abstract. The i* modeling technique focuses on an early-phase of requirements
engineering aiming at understanding how a system would meet organizational
goals, how it would fit within the organizational context, why would it be
needed and why should it be preferred among other possible alternatives.
Analysts are able to understand early the organizational context that bridges
system requirements to organizational goals. However, it is not clear how
uncertainty, potential threats and opportunities are taken into account both
when developing a strategic dependency model and a strategic rationale model,
to facilitate a continuous risk management. This paper proposes a set of
guidelines for refining i* models based on risk.
Keywords: i*, risk, goal, dependency, vulnerability, requirements.
1 Introduction
During an early-phase of requirements engineering activities, i* models are used to
capture the intentional aspects of a system. What do stakeholders intend to do using
the system, how would the system add value to the stakeholders, how would the
system support the stakeholders achieve their goals. The objective is to build the
context for the system by linking it to the operational and business environment, the
organizational structure, to fit stakeholders’ expectations and intentions to their goals.
According to [2] echoed by [1], the aim of the early-phase is understand the
“whys” of the system requirements, whereas the later-phase is focused on “what” to
conclude with requirements specification. Capturing the “whys” provides insights on
satisfying the stakeholder’s interests, their viability and uncertainty involved.
However, as acknowledged by [3], risks considered early along with stakeholders’
goals, can prevent from costs arising from their late discovery (e.g. during or post
development) and can contribute good criteria for the analyst to choose among
different alternatives when defining requirements. According to [4], risk refers to “...
exposure to a proposition of which one is uncertain.”, where [4] refers to perceived
risk. This definition, from one hand stresses the operational nature of risk relating it to
stakeholder’s intentions and perception of the organizational environment, while on
the other hand, it fits any risk management approach ([5], [6], etc.).
103
Proceedings of the 4th International i* Workshop - iStar10
2 Objectives of the Research
In order to capture uncertainty, threats and opportunities during the early-phase of
requirements engineering activities we aim at:
Embedding risks into the development of i* models,
Linking the early-phase requirements engineering activities and goals set to risk
management.
3 Scientific Contributions
Capturing stakeholder interests, as well as how they could be addressed relies on the
interaction between analysts, stakeholders and decision makers [1] expressed by the
SDM1 and the SRM2. We propose a set of guidelines for refining i* models
considering risk through NASA’s risk matrix [6], which provides a qualitative
understanding of risks, without adding complexity.
To illustrate our guidelines, each step is accompanied with an example coming
from a Massively Multiplayer Online Game (MMOG) scenario. There are four actors
identified, a game provider (GP), an internet service provider (ISP), a shipping agency
and a customer. The GP is the principal actor, creating game content, selling and
distributing the game on CDs to customers. The GP obtains the services from an ISP
for selling and providing the game. The ISP receives payment as compensation for
their service. The GP’s game software delivery service takes place through a shipping
agency. Customers access the game servers in order to play and pay the GP.
The first step focuses on populating a detailed list of dependencies considering
both the SDM and the SRM, focusing on the actor of interest. In step 2 dependencies
are analyzed for relevant risks to be identified. Step 3 assesses the identified risks
based on their impact and likelihood, resulting into a classification through the risk
matrix. Step 4 covers possible influences on the SRM and the SDM coming from
different mitigation strategies.
Step 1: Identify detailed dependencies.
The SDM is built where strategic relationships are captured through dependencies.
Focus is put on the actor of interest whose dependencies are listed. The analyst builds
the SRM for the actor of interest enriching each dependency with intentional
relationships. The impact of a dependency within an actor becomes visible, as well as
the rationale of the dependency itself. The outcome is a detailed list of dependencies.
In our example, from the SDM, we list the dependencies of the GP. The GP
depends on customers for the goal “Game Sales” and the task “Pay for Games”, on
the ISP for the resource “Hosting Service” and on the shipping agency for the
resource “Shipping Service” (figure 1).
1 The strategic dependency model (SDM) captures the dependency relationships among actors
[7].
2 The strategic rationale model (SRM) captures the rationale behind dependencies and reveals
actors’ intentions [7].
104
Exploring Risk-Awareness in i* Models
Figure 1: The SDM for the MMOG scenario
The list of dependencies of the GP is enriched with intentional relationships in the
SRM (figure 2). The GP depends on:
Customers for achieving the goal “Game Sales”; this goal can be met by
coordinating game provisioning (means-end link), which in our example consists
of (decomposition link) the resource Game and the tasks Deliver CDs and Sell
Online Gaming,
Customers for carrying out the task “Pay for games”, as the coordinate game
provisioning task requires this task be performed,
The ISP provider for the resource “Hosting service”, as the sell online gaming task
makes use of it,
The shipping agency for the resource “Shipping Service”, as the Distribute CDs
task makes use of it.
Figure 2: The SRM for the MMOG scenario
Step 2: Identify risks
For each elaborated dependency the analyst aims at discovering, interactively with
stakeholders, what could go wrong and what would be the consequences if things
105
Proceedings of the 4th International i* Workshop - iStar10
went wrong3. Each dependency should be examined to identify whether undesired
events could happen, how and when, thus capturing exposure and uncertainty, ergo
list risks.
In our example, the GP is running the risk of customers not buying the game (A),
or not paying for the game (B), the risk of the ISP provider failing to provide adequate
hosting service (C) and the risk of the Shipping agency providing bad service (D).
Step 3: Assess risks
The analyst should assess the impact and likelihood of occurrence for the risks
identified. The dependency classification of i* according to vulnerability (open,
committed and critical [7]) reflects on impact, whereas for likelihood, probability
scales are adequate. The two scales become the two axes of the risk matrix [6] and
provide a risk classification.
For our example, considering impact due to vulnerability (1-3), bad shipping
service (D) belongs to open (marked with 1), inadequate hosting service (C) belongs
to committed (marked with 2) and both not buying (A) and not paying (B) belong to
critical (marked with 3). Regarding likelihood, we use a five score scale of occurrence
with 0%-20%, 20%-40%, etc. of vulnerabilities being compromised. According to
table 1, highest risk lies on (A) and (C)4.
Table 1: The risk matrix for MMOG
5
Likelihood
4 D C
3 A
2
1 B
1 2 3
Impact
Step 4: Mitigate Risks
The analyst revisits the SRM and considering the matrix starts addressing risks.
Mitigating risks should involve stakeholders to help address what if questions relevant
to the vulnerabilities. This could include modifying existing intentional relationships
within actors, introducing additional to minimize likelihood or make vulnerabilities
explicit for the requirement specification or even introducing new dependencies.
Changes in the SRM may not necessarily reflect on the SDM (e.g. introducing soft
goal decomposition). However, on the later-phase of requirement engineering
activities when producing the requirement specification, such changes will appear as
additional constraints.
For our example, regarding Hosting service (C), a new soft goal dependency could
be introduced between the two actors for Good Online Service. This means the GP
3 It is not within the scope of this paper to elaborate on the identification of vulnerabilities like
[8] and analysis of risks, like [6].
4 Probabilities identified rely on empirical information coming from stakeholders.
106
Exploring Risk-Awareness in i* Models
would define what is satisfactory to benefit from the ISP’s capabilities. Introducing
such a new dependency would result into the modification of the SDM.
An alternative mitigation strategy could be to introduce a soft goal like “Good ISP”
for the Sell online gaming task through decomposition. That would serve as a quality
goal for the task, and would restrict the selection among alternatives, but would not
appear on the SDM as no new dependency is introduced. Ergo, appear as a constraint
in the requirement specification for selecting an ISP minimizing exposure, uncertainty
or both.
4 Conclusions and Future Work
The proposed guidelines lead to refined i* models, embedding risks qualitatively
(exposure and uncertainty). Applied iteratively, the guidelines enhance the use of i*
by allowing stakeholders to assess risks related to their goals, elaborate on available
possibilities for using information systems and provide risk assessment on using the
system to achieve these goals.
5 Ongoing and future work
This paper has presented our effort to embed risks into i* models and provide a link
between an early-phase of requirements engineering and risk management. Future
work includes examining multi-actor risks and relating i* constructs to risk
classifications (e.g. associate critical dependencies to functional requirements, soft-
goals to non-functional requirements, etc.).
6 References
1. Yu E.: Towards Modeling and reasoning Support for Early-Phase Requirements
Engineering. In: 3rd IEEE International Symposium on Requirements Engineering
(RE'97), pp. 226--235. IEEE Press, Washington D.C. (1997)
2. Yu E., Mylopoulos J.: Understanding Why in Requirements Engineering-with an
Example. In: Workshop on System Requirements: Analysis, Management, and
Exploitation, Schloss Dagstuhl, Saarland, Germany (1994)
3. Asnar Y., Giorgini P., Mylopoulos J.: Risk Modeling and Reasoning in Goal Models.
Technical report, DIT-06-008 (2006)
4. Holton G.A.: Defining Risk. J. Financial Analysts, Vol. 60, 6, 19--25 (2004)
5. van Lamsweerde A.: Requirements Engineering: From System Goals to UML Models to
Software Specifications. Wiley, West Sussex (2009)
6. NASA IV&V Management System, Guidelines for Risk Management, S3001,
http://www.nasa.gov/centers/ivv/pdf/209213main_S3001.pdf
7. i* Quick Guide, http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide
8. van Lamsweerde A., Letier E.: Handling Obstacles in Goal-Oriented Requirements
Engineering. J. IEEE Transactions on Software Engineering (TSE), Vol 26, 10, 978—
1005 (2000)
107