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.).
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.
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 SDM 1 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). 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. 3 . Each dependency should 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).
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 .
The risk matrix for MMOG
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 would define what is satisfactory to benefit from the ISP's capabilities. Introducing 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.
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.
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, softgoals to non-functional requirements, etc.).