Comparing Modeling Approach Workshop – 2012 RE... · Comparing Modeling Approach Workshop –...

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


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


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].


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/.


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.


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.


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


• 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


• 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


o minimize damage to property


• 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


• 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


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



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


• provide crisis-related information (including information about their location, identity, and medical history) to firemen and policemen


BECAUSE crisis details BE detected BY stakeholders

o follow instructions from firemen and policemen


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


• provide information to firemen and policemen


o follow instructions from firemen and policemen


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


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


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


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.


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


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.


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].


Figure 6b – SDsituation 2. Crisis identification: IP Diagram

Figure 6c – SDsituation 3 – Crisis deployment plan: IP Diagram


Figure 6d – SDsituation 4 – Crisis Development: IP Diagram

Figure 6e – SDsituation 5 – Crisis Conclusion: IP Diagram


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).


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


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


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


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


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


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


Figure 10a – SDsituation 3 – Crisis deployment plan – SR Model

Figure 11 – SDsituation 4 – Crisis Development – SD Model


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.


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


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.


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]”.


Figure 13b – SDsituation 6 – Countermeasure Identification - SR model


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.


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.

Comparing Modeling Approach Workshop – 2012 RE... · Comparing Modeling Approach Workshop –...

Documents

Transcript of Comparing Modeling Approach Workshop – 2012 RE... · Comparing Modeling Approach Workshop –...