Upload
lamnhi
View
225
Download
0
Embed Size (px)
Citation preview
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 1 / 32
Comparing Modeling Approach Workshop – 2012
CAR CRASH MANAGEMENT SYSTEM Selected Approach: Intentional Requirements Engineering
Authors: Antonio de Padua Albuquerque Oliveira 1, Julio Cesar Sampaio do Prado Leite 2,
Luiz Marcio Cysneiros 3, Vera Maria Bejamim Werneck 1
1 Universidade do Estado do Rio de Janeiro – UERJ 2 Pontificia Universidade Catolica do Rio de Janeiro – PUC-Rio
3 York University - YorkU, Toronto
Contents:
INTRODUCTION - Selection of Modeling Approach …….……… 2
INTENTIONAL REQUIREMENTS ENGINEERING ………………… 5
1. Eliciting Actors’ Goals ………………………..…………… 5
Lexicon and Goals
Refined actors’ goals table
2. Identifying SDsituations ……………….…..……………… 10
SDsituations Diagram
3. Modeling Actors’ Goals …………..………………………… 12
SA Model
IP Diagrams
4. Modeling Actors’ Goals Rationale …………….…………… 18
SIGs - NFR Framework
SD Models and SR Models
CONCLUSION ……………………………………………….…...…… 31
BIBLIOGRAPHY ……….………………………………..………..…… 32
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 2 / 32
INTRODUCTION - Selection of Modeling Approach
The Intentional Requirements Engineering method [Oliveira 12] is presented as an extension of the i*
Framework [Yu 95]. The method provides the requirements engineering team a set of useful procedures
and tools to guide the construction of i-Star models. The approach uses Leite’s [Leite 93] viewpoint on
Requirements Engineering (RE), which consider the following main RE activities: elicitation, modeling and
analysis. Elicitation means understanding the contextual knowledge surrounding the desired system and
discovering the software requirements. Modeling means describing requirements and contextual
knowledge using representation languages to build models. Analysis means verifying and validating these
models. In Figure 1 we described every of the Intentional Requirements Engineering steps.
Figure 1 - Intentional Requirements Engineering overview process.
The first step “Elicit Actors’ Goals” needs that the RE team captures goals {concrete (hard) and
flexible (soft) goals}. This step is composed of three stages: identifies goals, separates them by actors,
and organizes goals as a list in “chronological order”.
The Intentional Requirements Engineering [Oliveira 08c] [Oliveira 12] sharply pushes the elicitation
towards intentionality. The method selected the Language Extended Lexicon (LEL) [Leite 00] as an
anchor since LEL facilitates the comprehension of contextual terminology.
Departing from Yu´s observation [Yu 95]: “A goal is a condition or state of affairs in the world that
an actor would like to achieve”, our idea is: “ACTIONS CHANGE STATES AND STATES ARE GOALS”. This
elicitation strategy is used in Actors’ Goals from Lexicon – AGFL [Oliveira 07], AGFL considers all kinds of
actions revealed by LEL and performed inside the selected context.
As softgoals are usually viewed as NFRs - non-functional requirements - [Chung 00] [Cysneiros 03],
our method adopted the term “flexible goal” (as a synonym of softgoal but, here, considered, as in
[Mylopoulos 92], as a more abstract concept) to represent actors’ intentionality regarding quality. As such
we understand that softgoals are more abstract than NFRs. Softgoals were introduced in [Mylopoulos 92]
as a primitive concept for modeling non-functional requirements. Knowing that requirements are not
goals, there has been a misunderstanding about the meaning of softgoal by some authors and also a
1) ElicitActors' Goals
2) IdentifySDsituations
5) SpecifySDsituations
6) Analyse SD and SRModels
Requirementsartifacts
3) Model Actors'Goals
4) Model Actors'Goals Rationale
BASELINE
UofD - Sources ofInformation
(people & documents)
ELICITATION - MODELLING - ANALYSIS ELICITATION - MODELLING - ANALYSISELICITATION - MODELLING - ANALYSIS
ELICITATION - MODELLING - ANALYSIS ELICITATION - MODELLING - ANALYSISELICITATION - MODELLING - ANALYSIS
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 3 / 32
misuse of the term by a lot of engineers in practice. Softgoals should always be specifically used for
qualifying topics and how they are related to other softgoals [Chung 00]. Softgoal is a kind of goal that is
satisficed1 to denote the lack of precision in the perception of satisfaction. NFRs, strictly speaking, are
sentences used for designating a quality or constraint that software must have. Goals belong to actors’
intentionality, while functional requirements (FR) and non-functional requirements (NFR) are related to
software. NFRs and softgoals represent quality attributes or constraints. Both kinds of goals will be
operationalized by functional requirements into the software system.
In the second step “Identify SDsituations” the RE team identifies goals arrangements that are
interconnected in order to implement situations of dependency called SDsituations – Strategic
Dependency Situations [Oliveira 06b] [Oliveira 12]. This step works to detect how goals should be
composed to set context dependency situations. SDsituations work to maintain the problem complexity
under control, it is a modularization strategy to develop SD and SR models, which can also be used to re-
organize existing i* models into simpler models. On the other hand, SDsituations also help the RE team
to elicit more actors´ specializations: agents, roles, and positions [Leite 07].
In the third step “Model Actors’ Goals” the RE team builds diagrams, similar to Statecharts that
consider actors/agents in order to represent chains of goals (concrete and flexible). The diagram is
named “Intentionality Panel” (IP) [Oliveira 07] [Oliveira 12], is a SR model reduction. As benefits of
Intentionality Panels are: (i) engineers can realize how one flexible goal (softgoals) attribute can qualify
concrete goals and (ii) how one specific concrete goal can be a condition of achievement of other
concrete goal either from the same actor or among different actors in the beginning of modeling activity.
Figure 2 – Goals relations represented through IP diagrams.
Figure 2 shows the three types of links represented in IP diagrams: (a) on the left hand side, the three
kinds of correlations between goals, (b) in the central part, the dependency link between goals from
different actors, and (c) on the right hand side, the contribution link between softgoals. On the left hand
side of Figure 3, we represent the correspondences between i* SR model and the IP diagram. On the
right hand side we represented the means-ends alternatives. While goal A and goal B together are
correlated to the main goal to be achieved, goal C (with “ID=s”) has an alternative correlation to the main
goal to be achieved. IP Diagrams provides a side benefit which is related to uncovering the need for
intermediary goals in order to facilitate the SDsituation main goal achievement. It makes it easier to
elaborate on the rationale for distinct alternatives.
1
Term coined by Hebert Simon [Simon 69].
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 4 / 32
Figure 3 – i* SR model reduction into one IP diagram.
In the fourth step “Model Actors’ Goals Rationale” the RE team refines softgoals using Softgoal
Interdependency Graphs (SIG) models [Chung 00] and builds SD and SR models. IP Diagrams show
goals and softgoals without decisions about how they will be achieved. In order to detail softgoals we
refine them in SIGs, and to build SD models, the engineer must define strategic dependencies among
actors and build SR models for every SDsituation based on IP diagrams. The idea is to define strategic
dependencies using the same criteria of i* Framework [Yu 95]. For each SDsituation the requirements
engineer has to examine dependency relationships which were assigned in IP Diagram and for every one
choose a dependency type among the four options: goal, softgoal, resource, and task, the one that gives
more advantage to the “depender”. To build SR models, the engineer must identify the rationale inside
actors’ frontier.
In the fifth step “Specify SDsituations” the RE team describes SDsituations applying a Scenarios based
strategy. The step uses the Scenarios Language defined by Leite et al [Leite 00] and emphasizes MAS
concepts (agency properties like autonomy, pro-activeness, sociability, adaptation, and interaction as well
as collaboration, learning, and mobility [Garcia 04] [Oliveira 06a]). This step is supported by the C&L tool
software [C&L]2, which is a management tool for Lexicons and Scenarios.
In the sixth step “Analyse SD and SR Models” RE team and stakeholders analyse the models
supported by a diagnoses process and creates a report matching discovered problems with impacted
goals. The i* Diagnoses [Oliveira 08b] [Oliveira 12] examine every one of the models in each SDsituation
in order to bring questions that challenge the model consistency and completeness. The main idea is to
focus on parts of an i* model and from these parts conduct an inquiry into the given construct.
We have applied the first four steps of the method to model the BCMS, using the “BCMS –
REQUIREMENTS DEFINITION DOCUMENT”, as the information source. We consider following steps 5 and 6
out of scope for the proposed modeling exercise. Following we will present as Sections the steps of the
method and the results we have achieved.
2 C&L is an open source developed by the Requirements Engineering Group at PUC-Rio being available at http://pes.inf.puc-rio.br/cel/.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 5 / 32
In order to give a more abstract view of the method, we present a static view of its context using an
UML class diagram. Classes in yellow color are i* elements, classes in blue are Intentional RE’s, the class
in white is one interpretation over the Universe of Discourse, and classes in green are elements of other
representation languages (Scenarios, Lexicon, and NFR Framework). The classes are associated by
relations, providing traceability links among Intentional RE’s main concepts.
1. The method begins by building LEL symbols from the Universe of Discourse (Organizational Problem) language.
2. LEL symbols (subjects, objects, verbs, and states) have Behavioral Responses (BR), and based on them, goals (concrete and softgoal) can be discovered.
3. LEL symbols of the subject kind are actors.
4. Actors are mapped by one SA model and they are defined as agents, positions, or roles and two or more actors participate of one or more SDsituation.
5. Goals table indicates SDsituations, which links two or more actors using goals.
6. Goals populate IP diagrams and each one is a type of one SDsituation view.
7. Others views of one single SDsituation are represented by one i* SD model and by one or more i* SR model.
8. One or more i* SR models must detail the actor’s rationale inside one i* SD model in one SDsituation.
9. SDsituations are grouped in one SDsituation diagram and all SDsituations achieve one goal and each one is described by one Scenario.
10. All i* SR models are composed by one or more SRconstructs.
11. One SRconstruct attains one concrete goal and one NFR SIG operationalizes one or more softgoals.
12. i* diagnoses analyses SDsituations and also i* diagnoses examines SRconstructs.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 6 / 32
INTENTIONAL REQUIREMENTS ENGINEERING
1. Eliciting Actors’ Goals
Objective: “Elicitation of refined goals”.
This step is composed of three stages: A) Build LEL - Lexicon Extended Language, B) Define AGFL -
Actors’ Goals from Lexicon, and C) Refine actors’ goals.
The motivation for using the LEL is to have a solid anchor (the application language), which covers the
language used in the Universe of Discourse (the context) being considered. This language driven
approach has been shown to deal well with different information sources in a given Universe of
Discourse. Using a method for eliciting usual vocabulary leads to the construction of a LEL model, which
focus on concepts that are native to the context where the future software or the evolved software will
operate. In the specific case at hand the information source was the description provided as a case study
and a general NFR (Non Functional Requirements) catalogue.
LEL (Lexicon Extended Language) [Leite 00] is a technique that aims to capture from documents and
people the application vocabulary elements (called symbols), which must be classified as: subject
(someone who does the action), object (something that receives the action), verb (the action), and state
(the result of an action). In the LEL behavioral responses (BRs) mention actions which happen in the UofD
and two kinds of actions can be observed: concrete actions and flexible actions. A concrete action
changes one state, it changes one state to another one, and a flexible action adds a quality attribute to
one state. If there is one action it will be either concrete or flexible [Oliveira 08a] [Oliveira 12].
A concrete action has to bring any concrete result looking at it from a requirements engineer point of
view. ERi*c Method [Oliveira 08a] also introduced the term flexible action as complement of concrete
action. This way, ERi*c Method qualified the term flexible in the flexible action with the same meaning or
interpretation as used in “softgoals”. Flexible actions lacks precision, its result cannot be identified a priori,
and the execution of the action may depend on interpretation (analyze, evaluate, check, control, verify,
and validate are examples of flexible actions [Oliveira 08a]).
Below we show how the Lexicon is used for identifying goals. The identification is based on heuristics
approach applied to the lexicon terms of type subject, which usually identify the actors in the given
context. Since every LEL entry is defined by notion and Behavioral Response (BR), the heuristics use the
actions mentioned in each symbol BR. These BRs can express two possibilities for actor’s motivation: (i)
a state that one actor desires and does not depend on another actor or (ii) a state that one actor desires
and depends on another actor. This dependency may define, if the action demands, the depender and
the dependee of each goal.
We will exemplify how the lexicon was built for the BCMS example.
Since actions change states, identifying the motivation (why?) behind every action is the key point:
� When one concrete action is used � the action will define a concrete goal.
• Concrete actions will be marked by a solid ball.
� When one flexible action is used � the action will define a flexible goal.
o Flexible actions will be marked by an empty ball.
Every verb that means some kind of action will be written in underline format.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 7 / 32
Lexicon and Goals from Requirements Definition Document (bCMS)
The answer to the “why” question applied to every BR finds as response at least one concrete goal.
Also the response can indicates flexible goals when either the action of BR is considered flexible or there
is in the sentence one or more desirable quality attributes. For illustration, the second BR “get resources
to the crisis location in the shortest amount of time” uses a concrete action (to get) and consequently the
response is “Because FSC wants crisis details BE detected by coordinators with fast [crisis location].
-----------------------------------------------------------------------------------------------------------------------------------------
LEL´s behavioral responses BR: responsibilities, in order to achieve objectives.
(WHY?) Concrete Goal (should/must BE achieved) / Flexible goal (quality attribute) -----------------------------------------------------------------------------------------------------------------------------------------
Fire Station Coordinator (FSC) - A FSC maintains control over a crisis situation by communicating with the police station coordinator (PSC) as well as firemen.
o minimize loss or injury to people and property, (maintains control over a crisis = to handle a crisis)
BECAUSE less [resources] � crisis BE resolved BY coordinators
BECAUSE less loss [people and property] � crisis BE resolved BY coordinators
• get resources to the crisis location in the shortest amount of time BECAUSE resources BE deployed BY coordinators.
BECAUSE fast [crisis location] � crisis details BE detected BY coordinators
BECAUSE crisis details BE declared BY staff
• have accurate estimation of resource needs and time of arrivals for resources BECAUSE resources BE estimated BY coordinators
BECAUSE accurate [resources plan] � crisis plan BE proposed BY coordinators
BECAUSE accurate [time plan] � crisis plan BE proposed BY coordinators
o have effective negotiation skills (e.g., with other coordinators)
BECAUSE effective [plan negotiation] � crisis plan BE accepted BY coordinators
• have dependable communication with involved stakeholders BECAUSE communication BE established BY stakeholders
BECAUSE dependable [communication] � communication BE established BY stakeholders
o maintain a feeling of control over the crisis (e.g., minimize stress level by providing and receiving crisis information to and from other coordinators in a timely fashion)
BECAUSE low [crisis stress] � crisis BE coordinated BY coordinators
BECAUSE timely [crisis information] � crisis BE handled BY staff
• provide clear, executable instructions to appropriate staff BECAUSE instructions BE provided BY coordinators
BECAUSE clear [instructions] � instructions BE provided BY coordinators
BECAUSE executable [instructions] � instructions BE provided BY coordinators
BECAUSE appropriate [instructions] � instructions BE provided BY coordinators
• determine where, when, and how many fire trucks to send
BECAUSE effective [plan] � resources BE deployed BY coordinators.
• communicate with the PSC to introduce herself BECAUSE communication BE established BY coordinators
• keep PSC up to date regarding the nature of the crisis and the deployed resources
BECAUSE low [crisis stress] � crisis BE coordinated BY coordinators
• propose a strategy for handling the crisis BECAUSE crisis plan BE accepted BY coordinators
• reach an agreement with the PSC on how to proceed
BECAUSE effective [instructions] � crisis BE coordinated BY coordinators
• receive updates regarding the crisis from individual firemen BECAUSE crisis BE coordinated BY coordinators
BECAUSE less loss [people and property] � crisis BE handled BY staff
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 8 / 32
• collate and distribute updated information and instructions back to the firemen BECAUSE crisis BE coordinated BY coordinators
BECAUSE effective [instructions] � instructions BE provided BY coordinators BECAUSE crisis BE handled BY staff
Fireman - A fireman acts on orders received from the FSC and reports crisis-related information back to the FSC. Furthermore, a fireman communicates with other firemen, victims, and witnesses at the crisis location.
• acts on orders received
BECAUSE � crisis BE resolved BY staff
• reports crisis-related information
BECAUSE � crisis BE resolved BY staff
o minimize injury
BECAUSE less loss [people and property] � crisis BE resolved BY staff
• save and support the victim
BECAUSE less loss [people and property] � crisis BE resolved BY staff
o minimize damage to property
BECAUSE less loss [people and property] � crisis BE resolved BY staff
• work well in a team BECAUSE crisis BE handled BY staff
o have confidence in the coordinator and follow instructions well
BECAUSE clear [instructions] � instructions BE provided BY coordinators
BECAUSE executable [instructions] � instructions BE provided BY coordinators
BECAUSE appropriate [instructions] � instructions BE provided BY coordinators
• keep up to date regarding the crisis situation
BECAUSE timely [crisis information] � information BE updated BY staff
BECAUSE dependable [communication] � communication BE established BY stakeholders
• receive requests to go to/return from the crisis location BECAUSE crisis BE handled BY staff
• report location status to FSC
BECAUSE less [resources] � crisis BE handled BY staff
• report conditions of the crisis to FSC and all firemen BECAUSE crisis BE handled BY staff
o communicate with the victim and the witness at the crisis location
BECAUSE low [crisis stress] � crisis BE coordinated BY coordinators
Police Station Coordinator (PSC) - A PSC maintains control over a crisis situation by communicating with the fire station coordinator (FSC) as well as policemen. Behavioral responses: In order to achieve objectives, the responsibilities of a PSC are the same as the FSC. The description in Fire Station Coordinator (FSC) hence applies except that fire trucks are replaced with police cars, PSC with FSC, and firemen with policemen.
Police Officer - A police officer acts on orders received from the PSC and reports crisis-related information back to the PSC. Furthermore, a police officer communicates with other policemen, victims, and witnesses at the crisis location. Behavioral responses: In order to achieve objectives, the responsibilities of a police officer are the same as the fireman in terms of communicating with his coordinator. In addition, a police officer wants to re-establish order disturbed by a crisis (e.g., manage traffic and people). Hence, the description in Section Fireman applies except that FSC is replaced with PSC.
Victim - A victim has been adversely affected by the crisis and may communicate with policemen and firemen. Behavioral responses:
• be rescued in the shortest amount of time BECAUSE crisis BE resolved BY coordinators
• recover from injuries and/or loss in the shortest amount of time
BECAUSE less loss [people and property] � crisis BE resolved BY staff
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 9 / 32
o minimize stress caused by the crisis
BECAUSE low [crisis stress] � crisis BE handled BY coordinators
• be informed of crisis status as it impacts the victim BECAUSE communication BE established BY stakeholders
o know what to do at different stages of the crisis
BECAUSE dependable [communication] � communication BE established BY stakeholders
• provide crisis-related information (including information about their location, identity, and medical history) to firemen and policemen
BECAUSE dependable [communication] � communication BE established BY stakeholders
BECAUSE crisis details BE detected BY stakeholders
o follow instructions from firemen and policemen
BECAUSE less loss [people and property] � crisis BE handled BY staff
Witness (at the crisis location) - A witness has observed the crisis and communicates with policemen and firemen. Behavioral responses:
• provide accurate information about the crisis to the police and fire personnel BECAUSE crisis BE handled BY staff BECAUSE crisis details BE detected BY stakeholders
o know what to do
BECAUSE dependable [communication] � communication BE established BY stakeholders
• provide information to firemen and policemen
BECAUSE dependable [communication] � communication BE established BY stakeholders
o follow instructions from firemen and policemen
BECAUSE less loss [people and property] � crisis BE handled BY staff
Government Agencies - Government agencies provide funding for the system and expect improvements of the communities’ living standard from the deployment of the system. Behavioral responses:
o keep the community safe
BECAUSE less loss [people and property] � community BE protected BY coordinators
BECAUSE less loss [people and property] � crisis BE resolved BY coordinators
o ensure effective response times with minimal costs BECAUSE less [cost] � fire departments BE prepared BECAUSE less [cost] � police departments BE prepared
• provide funding for fire and police departments BECAUSE fire departments BE equipped BECAUSE police departments BE equipped
• establish policies for both groups (e.g., security, response time expectations) BECAUSE less loss [people and property] � fire departments BE prepared BECAUSE less loss [people and property] � police departments BE prepared
Communication Compromiser - A communication compromiser wants to achieve personal gain, whether it is monetary or otherwise, by accessing confidential information and disrupting the handling of the crisis situation. Behavioral responses:
• disrupt the response to the crisis for some personal gain BECAUSE crisis BE disrupted BECAUSE fine [profit] � personal gain BE achieved
• gain access to confidential information BECAUSE malicious [access] � confidential information BE accessed
• change confidential information BECAUSE malicious [access] � confidential information BE changed BECAUSE fine [profit] � personal gain BE achieved
• disrupt communications BECAUSE malicious [access] � confidential information BE disrupted
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 10 / 32
Refined actors’ goals table In order to refine the actor’s goals, the method proposes two stages: merge goals (concrete and
flexible) by DEPENDER and set them in a chronological order. Chronological order means: long term goals first (the most abstract before and the less abstract after).
DEPENDER DEPENDEE
Coordinators (SDsituation)
less [resources] less loss [people & property]
(5) crisis BE resolved by FSC / PSC
low [crisis stress] (4) crisis BE coordinated by FSC / PSC
less loss [people & property] less [resources]
(4) crisis BE handled by staff
timely [crisis information] (4) information BE updated by staff
effective [instructions] (4) instructions BE provided
dependable [communication] (4) communication BE established by staff (4) resources BE deployed by FSC / PSC
effective [plan negotiation] (3) crisis plan BE accepted by FSC / PSC
effective [plan] (3) crisis plan BE proposed by FSC / PSC
dependable [communication] (3) communication BE established by FSC / PSC (3) resources BE estimated by FSC / PSC (2) crisis details BE declared by staff
dependable [communication] (2) communication BE established by stakeholders
fast [crisis location] (2) crisis details BE detected by stakeholders
less [cost] (1) departments BE prepared by government
less [cost] (1) departments BE equipped by government
Staff
less [resources] less loss [people & property]
(5) crisis BE resolved by coordinators
low [crisis stress] (4) crisis BE coordinated by coordinators
less loss [people & property] less [resources]
(4) crisis BE handled
timely [crisis information] (4) information updated
effective [instructions] (4) instructions BE provided by coordinators
dependable [communication] (4) communication BE established
effective [plan] (4) resources BE deployed by coordinators (2) crisis details BE declared
dependable [communication] (2) communication BE established by stakeholders
fast [crisis location] (2) crisis details BE detected by stakeholders
Witness
less loss [people&property] (4) crisis BE handled by staff
dependable [communication] (2) (4) communication BE established (2) crisis details BE detected
Government Agencies
availability [system] performance [system]
(1) community BE protected by coordinators
less loss [people & property] (1) crisis BE resolved by coordinators
less [cost] (1) departments BE prepared
less [cost] (1) departments BE equipped
Communication Compromiser
fine [profit] (6) personal gain BE achieved
malicious [access] (6) crisis BE disrupted
malicious [access] (6) crisis information BE disrupted by Attacker
malicious [access] (6) confidential inf. BE changed by Attacker
malicious [access] (6) confidential inf. BE disrupted by Attacker
malicious [access] (6) confidential inf. BE accessed
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 11 / 32
2. Identifying SDsituations
Objective: “Elicitation of goals (and softgoals) arrangements that are connected in order to
implement situations of dependency called SDsituations – Strategic Dependency Situations [Oliveira
06b]”.
This step is composed of three stages: A) Distinguish SDsituations, B) Recognize SDsituations
interdependencies, and C) Build SDsituations diagram.
The motivation for using the concept of SDsituation is to split the “dependencies” among actors in
focused situations, but keeping the same Strategic Dependency semantics as in i* [Yu 95]. The partition
criterion is based on intentionality [Oliveira 07]; and provides the Requirement Engineer with a technique
for the control of model complexity avoiding the usual problem of i* models [Pastor 06].
Definition: An SDsituation is a dependency construct with one situational intentionality (one common
goal) which is temporarily shared by some actors therefore; it is compiled from actors and their mutual
strategic dependencies [Oliveira 08a]. Actors participate in situations of collaboration through their own
goals.
Situations of dependency occur in the environment and the central idea of SDsituations is: “every
dependency link (goal, softgoal, task or resource) that involves actors is not isolated”; it is part of one well
defined situation of collaboration called one “strategic dependency situation” or one SDsituation [Oliveira
06b]. One SDsituation is composed by one or more dependency elements, and any SDsituation can be
identified separately from another SDsituations forming a chain of interdependencies. Interdependencies
among SDsituations may be physical, logical or temporal and can be represented in a specific diagram
[Oliveira 06b]. In the Refined actors’ goals table the SDsituation was identified by a number in red round
brackets.
For the “Car Crash Crisis Management System” six SDsituations (Figure 4) were distinguished, they
are intentional and sequentially related.
1. Departments preparation
2. Crisis identification
3. Crisis deployment plan
4. Crisis development
5. Crisis conclusion
6. Attack situation
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 12 / 32
SDsituations Diagram
The motivation for building the SDsituations diagram is to explicit, in only one figure, the relationship
among the chain of SDsituations. The SDsituations diagram was inspired in the UML activity diagram, but
with a different semantics, since SDsituations do not represent activities.
Figure 4 – SDsituations diagram
In the Figure 4, the first SDsituation is 1. DEPARTMENTS PREPARATION. Although this SDsituation is limited to
the beginning of the diagram it can occurs during all time. The meaning of that position is to give
emphasis that every department staff must be prepared (equipped and trained) before the crisis.
Another point is the interval time of SDsituations. In some cases the time is significant, for instance T2
and T3 that represent the duration of 2. CRISIS IDENTIFICATION and 3. CRISIS DEPLOYMENT PLAN must be the smallest
because they have important influence over the crisis. For complementation, crisis details and route plan
shall be available with the exception of 30 minutes for every 48 hours when no crisis is active.
Another point is the representation of the SDsituation 6. ATTACK SITUATION. This representation means that
attack problem may occur in any time and it demands special stakeholders’ attention.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 13 / 32
3. Modeling Actors’ Goals
This step is composed of two stages: A) Identifying agents, positions, and roles and; B) Creating
intentionality panels – IP Diagrams.
Base on LEL the RE team can identify the actors (LEL subjects) classifying them as agents, positions,
and roles and so represent all kind of actors in the Strategic Actors Model - SA Model [Leite 07].
The BCMS demanded two Strategic Actors Models because in one special SDsituation new actors
must be identified. Figure 5 shows actors as agents, positions, and roles in the main SA Model and
Figure 5a shows the SA Model from SDsituation 6 - Attack situation which applied attacker analysis [Liu
02] [Cunha 08] to identify potential system abusers and malicious intents from Communication
Compromisers.
SA Models The motivation for creating the Strategic Actors Model is to recognize separately the different actors’
groups which work in the organization context. By mapping actors’ groups and the relationship among
them the RE team can build simple and coherent SD and SR models without confusing the kinds of
actors and not representing useless elements. For example: using staff as an actor, the RE team should
represent neither Fireman nor Police Officer.
Figure 5 – Agents, positions, and roles: SA Model
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 14 / 32
Figure 5 shows in the SA main model Stakeholders as agents. Agents can occupy positions. So they can occupy
Coordinators, Stakeholders, and Government positions. The position of Coordinators is divided in two positions:
PSC – Police Station Coordinator and FSC – Fire Station Coordinator. FSC – Fire Station Coordinator covers the role
of Fireman and PSC – Police Station Coordinator covers the role of Police Officer. Both Fireman and Police Officer
are part of Staff role. The position of Stakeholders covers four different roles: Staff, Witness, Victim and
Government Agencies. The position of Government can also cover the role of Government Agencies. The SA Model
also said that as agent Stakeholders can play roles of Staff, Witness, Victim and Government Agencies.
Attacker analysis [Liu 02] recommends the basic premise that all the actors are assumed “guilty until
proven innocent”. This premise was used for elaborating the Strategic Actors Model (Figure 5a)
considering any one of the actors as a potential attacker.
Figure 5a shows, in the SA Model, Attacker as agent. The agent Attacker may be of two kinds: INTERNAL
Attacker or EXTERNAL Attacker. One EXTERNAL Attacker can be agents as VIRUS, HACKER, or CKACKER. The agent
INTERNAL Attacker can occupy the position of Attacker. The position of Attacker can cover four different roles:
Staff, Witness, Victim and Government Agencies. And also the position of Attacker can be an instance of the
position of Coordinators.
Figure 5a – Attackers: SA Model
We will apply Liu’s attacker analysis together the IP diagram for the SDsituation 6 - Attack situation.
Consequently, SDsituation 6 models (Figure 13, 13a and 13b) use Liu´s strategy without changing the
steps of ERi*c strategy. So, threats from potential attackers were anticipated and actions were studied to
provide counter measures for possible attacks.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 15 / 32
IP Diagrams Figures 7a, 7b, 7c, 7d, 7e, and 7f on the next pages show IP Diagrams guided by SDsituations. The
first and main motivation for creating IP Diagrams is to allow intentionality to be represented in a single
homogeneous diagram [Oliveira 07], consequently the intentionality can be realized at a glance by the
engineer. The second motivation is to represent intentionality considering goals sequence in
chronological order and therefore one can use this sequence in the SR Model.
The IP Diagram can be considered a SR Model reduction. In IP Diagrams only goals and the
relationships among goals are shown. One kind of relationships is the dependency. Each dependency in
one IP Diagrams shows that one actor´s goal depends on other actor to be achieved. In i* each
dependency may be one element (a resource, a task, a softgoal, or one goal) but in the IP Diagram one
dependency can represent more than one element in the correspondent i* SD model. IP Diagrams do not
show tasks and resources that appear in SR Models. IP Diagrams are loosely inspired on State Charts.
The line below the actor (time line) gives a notion of time, in the sense that there is an ordering among
goals. As in State Charts in order to change or to finish one goal (state) that goal (state) must be
achieved, but this ordering may be impacted by different types of relationships: correlation, contribution,
and dependency, as described on the Figure below. Also, using dependencies shown in IP Diagrams, the
RE team can decide in the second stage “Building SD Models” of the next step “Modeling Actors’ Goals
Rationale”, which are the best elements to be represented as strategic dependencies in SD Models.
Figure 6a – SDsituation 1 - Departments preparation: IP Diagram
The SDsituation 1 - Departments preparation (Figure 6a), shows that GOVERNMENT has as the main goal
communityBEprotected, this goal depends on all: performance [system] and availability [system] be “satisficed”,
and crisisBEresolved be achieved by COORDINATORS. Also communityBEprotected is correlated to goals:
departmentsBEprepared and departmentsBEequipped be achieved, and these goals have as attribute the softgoal
less [cost]. The COORDINATORS’ goal crisisBEresolved depends on GOVERNMENT for goals
departmentsBEprepared and departmentsBEequipped be achieved. These GOVERNMENT’s goals receive
correlation of two attributes: less loss[people] and less loss[property].
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 16 / 32
Figure 6b – SDsituation 2. Crisis identification: IP Diagram
Figure 6c – SDsituation 3 – Crisis deployment plan: IP Diagram
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 17 / 32
Figure 6d – SDsituation 4 – Crisis Development: IP Diagram
Figure 6e – SDsituation 5 – Crisis Conclusion: IP Diagram
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 18 / 32
Figure 6f – SDsituation 6 – Attack situation: IP Diagram
In this SDsituation, we will show how a methodological framework for analyzing security requirements
called “Attacker analysis” [Liu 02] [Cunha 08] based on the concept of strategic social actors can be
attached to our method in a natural way without changing the sequence of steps and stages. Each of the
security related analysis steps will be discussed in detail in the following subsections.
Liu’s framework has five steps. The first step ➊ Attacker Identification was covered by SA Diagram
(see Figure 5a – Attackers: SA Model). The second, ➋ Malicious Intent Identification, was covered by IP
Diagram (see Figure 6f – SDsituation 6 – Attack situation: IP Diagram). The third, ➌ Vulnerability
Analysis, was covered by SIG – Softgoal Interdependency Graphs of NFR decomposition of “dependable
[communication]” (see Figure 7b – NFR decomposition of “dependable [communication]”). And steps four
and five, ➍ Attacking Measure Identification, ➎ Countermeasure Identification, were covered by SD
Model and SR Models of SDsituation 6 (see Figure 13a – SDsituation 6 – Attacking Measure
Identification, and Figure 13b – SDsituation 6 – Countermeasure Identification).
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 19 / 32
4. Modeling Actors’ Goals Rationale
The fourth step is composed of three stages: A) Refining Flexible Goals, B) Building SD Models, and
C) Building SR Models.
The idea is to adopt one adequate artifact (SIG – Softgoal Interdependency Graph [Chung 00]
[Cysneiros 03]) to investigate flexible goals: refining them in the softgoals decomposition and finally
identifying ways for having their operationalization.
SIG – Softgoal Interdependency Graphs
Figure 7a – NFR decomposition of “effective [statements]”
SIG - NFR Framework
Operationalization
Type decomposition
Topic decomposition
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 20 / 32
Figure 7b – NFR decomposition of “effective [plan]”
In this step we included both softgoal refinements on topic and on type based on the NFR Framework
methods [Chung 00]. In an NFR type decomposition method, a parent is refined on its type by offsprings,
each with a subtype of the parent type. Note that (Figures 7a, 7b, and 7c), in topic decomposition the
type of the parent is copied down to the offsprings.
SIG - NFR Framework
Operationalization
Type decomposition
Topic decomposition
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 21 / 32
Figure 7c – NFR decomposition of “dependable [communication]”
In order to implement “dependable [communication]”, the SIG recommends breaking the “access
authorization” down into three components: “identification”, “authentication”, and “access rule validation”;
use “cameras” to improve the communication, and implement “encrypted communications”. The NFR
Integrity of the communication can be considered covered by the softgoal “dependable [communication]”.
The softgoal “access authorization” will be analyzed in detail inside the SDsituation 6 - Attack situation.
SD Models and SR Models
The result of stages B and C are shown below. Figures 8, 9, 10, 11, 12 and 13 show SD Models and
Figures 8a, 9a, 10a, 11a, 11b, 11c, 12a, 13a and 13b show SR Models.
Topic decomposition
SIG - NFR Framework
Type decomposition
Operationalization
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 22 / 32
For improving readers’ comprehension we described one SD Model and one SR Model of the
SDsituation 2.
Models of the SDsituation 2 - Crisis identification were described in detail because that SDsituation
models are good examples of all kind of dependency elements and all kind of relationships among actors.
Figure 8 – SDsituation 1 – Departments preparation – SD Model
Figure 8a – SDsituation 1 – Departments preparation – SR Model
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 23 / 32
Figure 9 – SDsituation 2 – Crisis identification – SD Model
Figure 9 shows the SD Model of the SDsituation named “Crisis identification”. This SD Model is a good example
of all kinds of dependencies. It represents that the actor STAFF depends on STAKEHOLDERS provide the resource “crisis
details”, and depends on STAKEHOLDERS in order to “Establish communication”. Also it represents that the STAFF
depends on COORDINATORS to have “crisis BE declared”. The COORDINATORS depend on STAFF to have “fast [crisis
location]” and depends on STAKEHOLDERS provide the resource “crisis details”.
Figure 9a – SDsituation 2 – Crisis identification – SR Model
Figure 9a shows STAKEHOLDERS, STAFF, and COORDINATORS working for the achievement of the SDsituation goal:
“crisis BE declared”. The detail of SR Model from SDsituation 2 – Crisis identification is described below.
STAKEHOLDERS in order to achieve the goal (end) “crisis details BE declared” either perform the task (mean) “Give
crisis details by phone” or “Give crisis details by site”. The task “Give crisis details by phone” has four elements in
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 24 / 32
its decomposition: a goal “communication BE established” has to be achieved, a communication has to be
dependable as modeled by the softgoal “dependability [communication]”, the communication has to work as by
the task “Establish communication”, and details of crisis has to be provided, as modeled by the resource “crisis
details”. The task “Give crisis details by site” also has four elements in the decomposition: a goal “communication
BE established” has to be achieved, a communication has to be dependable as modeled by the softgoal
“dependability [communication]”, the communication has to work as by the task “Establish communication”, and
details must be provided by the resource “crisis details”.
STAFF in order to achieve the goal (end) “crisis details BE declared” needs a task (mean) “Receive crisis
declaration”. This task has five elements in its decomposition meaning that: the STAFF depends on the STAKEHOLDERS
“Establish communication”, hopes that the goal “communication BE established” be achieved, has the softgoal
“dependability [communication]”, a task “Detect crisis location”, and finally hopes the goal “crisis BE declared”
that depends on COORDINATORS. In order to perform the task “Detect crisis location”, the STAFF depends on
STAKEHOLDERS provide “crisis details” and hopes the softgoal “fast [crisis location]”.
COORDINATORS in order to achieve the goal (end) “crisis details BE declared” a task (mean) “Declare crisis” is
represented. This task has four elements in the decomposition meaning that: the COORDINATORS hopes the goal
“crisis BE declared”, has the softgoal “dependable [communication]”, a task “Obtain crisis details”, and finally
hopes that “communication BE established”. In order to perform the task “Obtain crisis details”, COORDINATORS
depend on STAKEHOLDERS provide “crisis details” and depend on STAFF provides the softgoal “fast [crisis location]”.
Figure 10 – SDsituation 3 – Crisis deployment plan – SD Model
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 25 / 32
Figure 10a – SDsituation 3 – Crisis deployment plan – SR Model
Figure 11 – SDsituation 4 – Crisis Development – SD Model
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 26 / 32
Figure 11a – SDsituation 4 – Crisis Development – PSC & FSC – SR Model
Figure 11b – SDsituation 4 – Crisis Development – FSC & Fireman – SR Model
The other SR Model, about – PSC & Police Oficer SDsituation 4 – Crisis Development, has been
omitted because it is almost equal to the Figure 11b.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 27 / 32
Figure 11c – SDsituation 4 – Crisis Development – Fireman & Stakeholders – SR Model
The other SR Model, about – Stakeholders & Police Oficer - SDsituation 4 – Crisis Development, has
been omitted because it is almost equal to the Figure 11c.
Figure 12 – SDsituation 5 – Crisis Conclusion – SD Model
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 28 / 32
Figure 12a – SDsituation 5 – Crisis Conclusion – SR Model
Figure 13 – SDsituation 6 – Attack situation - SD model
Figure 13 shows that Communication Compromiser depends on Stakeholders Attackers and
Coordinators Attackers to achieve goals: crisis information BE disrupted, confidential inf. BE changed, and
confidential inf. BE disrupted.
Considering attacker analysis characteristics inside the SDsituation it is relevant the definition of
“Attacking Measure Identification” and “Countermeasure Identification” be represented in SR models.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 29 / 32
Figure 13a – SDsituation 6 – Attacking Measure Identification - SR model
On the left hand side of Figure 13a internal attackers are represented and on the right hand side
external attackers are represented. By simplifying the model only the Coordinator Attacker had the
rationale represented, every attacker has the same goal as Coordinator Attacker. Both Stakeholder
Attacker and Staff Attacker have the same goal and rationale as Coordinator Attacker.
Inside the SDsituation, continuing the attacker analysis characteristics process, we should map
the step of countermeasure Identification considering the others five SDsituations with correspondent SR
Models. Because this analysis is repetitive for all of SDsituations we choose the most complicated one.
The SDsituation 4 - Crisis Development – FSC & Fireman were considered as sufficient for exemplifying
those operationalizations possibilities.
Figure 13b – SDsituation 6 – Countermeasure Identification - SR model, shows the additional
rationale recommended by the study of Countermeasure Identification. Using the NFRs
operationalizations which appears in the SIG graph of Figure 7b – NFR decomposition of “dependable
[communication]” we elaborated i* means-end structures (goal-task) in order to “BREAK” both “legitimate
coordinator BE discredited” and “legitimate fireman BE discredited” and “MAKE” “dependable [communication]”.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 30 / 32
Figure 13b – SDsituation 6 – Countermeasure Identification - SR model
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 31 / 32
CONCLUSION
The method Intentional Requirements Engineering aims to fill a method gap in the i* Framework
by providing a group of engineering driven systematic towards the elaboration of modular i* models. The
method is supported by new models that explore topics to: organize intentionality3 capture, address
scalability, give temporality to models, and improve traceability to elicitation and modeling activities. For
improving and organizing intentionality (concrete goals and flexible goals) capture, the method uses LEL,
a lexicon technique that aims to capture the UofD (Universe of Discourse) vocabulary. For addressing
scalability the method divide the modeling problem in intentional linked sub-problems (SDsituations –
Strategic Dependency Situations) with the purpose of dealing, into each SDsituation, with one strategic
situation separated from others issues, which belong to others SDsituations. The sense of temporality is
mapped by IP (Intentionality Panels) diagrams and SDsituations relationship. In order to improve
traceability to elicitation and modeling the process of goals elicitation is strongly attached to LEL
definitions, which maps the application vocabulary.
It is important to say that we want to prepare the implementation of Multi-Agent System, a system
which will have software agents representing the organization actors. For this conduction of purpose the
resulting system will not work centrally.
In modeling the bCMS case study 25 non redundant (orthogonal) diagrams were built: two
Strategic Actors (SA); two SIGs - Softgoals Interdependency Graphs; six IP (Intentionality Panels); six SD
models; and nine SR models.
Variations like Police and Fire Station Multiplicity are typical and compatible with i* modeling and
as Crisis Multiplicity they can be delegated to a multiplicity of agent organizations of Multi-Agent Systems.
Vehicles management restrictions about communication of messages among agents (e.g.: who can
receive and send messages with others) should be defined in the system specification.
The Intentional Requirements Engineering method is evolving based on our experience in
education, as well as in modeling real cases in industry. Feedback from industry has been positive and
students keep helping for the fine tuning of modeling instructions. Progress on tool support has been
slow, but we continue to drive efforts in building a tool to help the first steps of the method.
3 Note: intentionality, expressed by goals, populates the world beyond the prison wall of actors’ actions (LEL’s behavioral responses). For
having success in the task of capturing intentionality requirements engineer should have common sense, experience, and mainly knowledge of
the organization area. Capture intentionality is a key point and the differential from traditional methodologies.
Comparing Modeling Approach Workshop – 2012 - Intentional Requirements Engineering - 32 / 32
BIBLIOGRAPHY
[Chung 00] Chung, L.; Nixon, B.; Yu, E.; Mylopoulos, J.; Non-Functional Requirements in Software Engineering – Kluwer Academic Publishers 2000 – Massachusetts, USA.
[Cysneiros 03] Cysneiros, L. M., Yu, E., Leite, J. C. S. P.; “Cataloguing Non-Functional Requirements as Softgoals Networks” in Proc. of. Requirements Engineering for Adaptable Architectures @ 11th International Requirements Engineering Conference, 2003 p.13-20.
[Cunha 08] Cunha, H.S., Leite, J.C.S.P.: Modelagem Intencional de Requisitos de Segurança. In CIbSE(2008) 321-326.
[Garcia 04] Garcia, A. F.; Lucena, C. J. P.; Cowan, D. D.; Agents in Object-Oriented Software Engineering; In: Software, Practice & Experience, Elsevier, vol. 34, Issue 5, pp. 489-521, May 2004
[Leite 93] Leite, Julio C.S.P.; Franco, Ana P.M.; A Client Strategy for Conceptual Model Acquisition; Proceedings of the International Symposium on RE, IEEE Computer Society Press, San Diego (1993), pp. 243-246.
[Leite 00] Leite, J.C.S.P., Hadad, G., Doorn, J., Kaplan, G. A Scenario Construction Process - RE Journal: Vol. 5, N. 1, Pags. 38 - 61, (2000), Springer-Verlag London Limited.
[Leite 07] Leite, Julio; Werneck, Vera; Oliveira, A. Padua A.; Capelli, Claudia; Cerqueira, Ana Luiza; Cunha, Herbert; Baixauli, Bruno; “Understanding the Strategic Actor Diagram: An Exercise of Meta Modeling” The X Workshop on Requirements Engineering; Toronto, Canada - May/2007.
[Liu 02] Liu L.; Yu E.; Mylopoulos, J.; Security and Privacy Requirements Analysis within a Social Setting - Proceedings of the International Conference on Requirements Engineering (RE’03) Monterey, California. p. 151-161.
[Mylopoulos92] Mylopoulos, J., Chung, L. and Nixon, B., "Representing and Using Non-Functional Requirements: A Process-Oriented Approach", IEEE Transactions on Software Engineering, June 1992.
[Oliveira 06a] Oliveira, A. Padua A., Cysneiros, L. M., Leite, J. C. do Prado, Figueiredo, E. M., and Lucena, C. J.; “Integrating scenarios, i*, and AspectT in the context of multi-agent systems”. In Proceedings of the CASCON '06 (Toronto, Canada - Oct. /2006). ACM Press, New York, NY, 16.
[Oliveira 06b] Oliveira, A. Padua A.; Cysneiros, L. M.; “Defining Strategic Dependency Situations in Requirements Elicitation”; The IX Workshop on Requirements Engineering; RJ, Brazil - July/2006.
[Oliveira 07] Oliveira, A. Padua A.; Leite, J. C. S. P.; Cysneiros, L. M.; Cappelli, C.; “Eliciting Multi-Agents Systems Intentionality: From Language Extended Lexicon to i* Models”, Proceedings of the XXVI International Conference of the Chilean Computer Science Society. Los Alamitos: IEEE Computer Society Press, 2007. v. 16. p. 40-49.
[Oliveira 08a] Oliveira, Antonio de Padua Albuquerque, (2008) Intentional Requirements Engineering: A Method for Requirements Elicitation, Modeling, and Analysis. 261 p. Doctoral Thesis – Computer Science Department, PUC-Rio.
[Oliveira 08b] Oliveira, A. Padua A.; Leite, Julio C. S. P.; Cysneiros, L. M.; Lucena, C. J.; i* Diagnoses: A Quality Process for Building i* Models - Proceedings of the Forum at the CAiSE'08, Montpellier, France, June 18-20, 2008. CEUR Workshop Proceedings 344 CEUR-WS.org 2008 pp. 9-12
[Oliveira 08c] Oliveira, A. Padua A.; Leite, Julio C. S. P.; Cysneiros, L. M.; “ERi*c Method - Intentional Requirements Engineering”; The XI Workshop on Requirements Engineering; Barcelona, Spain - July/2008.
[Oliveira 10] Oliveira, A. Padua A.; Leite, Julio Cesar S. P.; Cysneiros, L. M.; “Using i* Meta Modeling for Verifying i* Models”. iStar'10 The Fourth International i* Workshop; Hammamet, Tunisia – ( June/2010)
[Oliveira 12] Oliveira, A. Padua A.; Leite, Julio C. S. P.; Cysneiros, L. M.; “ERi*c Method - Intentional Requirements Engineering: A Method for Building i* Models” - RE Journal: (July/2012) submited.
[Pastor 06] Pastor, O; Estrada, H; Martínez, A.; The Strengths and Weaknesses of the i* Framework: An Empirical Evaluation, in Social Modeling for Requirements Engineering - Eric Yu, Paolo Giorgini, Neil Maiden, John Mylopoulos. (eds.) 2006 - MIT Press
[Simon 69] Simon, Herbet. A.; “The Sciences of the Artificial”, 3rd edition MIT Press, 1969.
[Yu 95] Yu, E. Modelling Strategic Relationships for Process Reengineering. PhD Thesis, Graduate Department of Computer Science, University of Toronto, Toronto, Canada, 1995, pp. 124.