Goal-Oriented Requirements Engineering -...

Goal-Oriented Requirements EngineeringLanguages and Applications

Paolo Giorgini

OIS

Outline• Why Goal-Oriented Requirements Engineering

(GORE)?▫ Example Projects

• GORE Frameworks • i* Syntax and Examples• i* Modeling Practice • What can you do with goal models?• i* Resources• Conclusions• References

Paja, Horkoff, and Mylopoulos -- OIS 2014-15

2

Why Goal-Oriented Requirements Engineering (GORE)?• Most systems today are socio-technical, e.g., ▫ E-business; E-learning; E-health; E-government ▫ Energy, environment, transportation

• Complex relationships among stakeholders▫ Know what they want

� E.g., security, privacy, trust, profitability, market positioning, strategic alliances, intellectual property, …

▫ Help them achieve what they want▫ Understanding “why”, not just “what”

• Strategic actors. Each one asks:▫ What do I want?▫ How can I achieve what I want?▫ Who do I depend on to achieve what I want?


3

Example Project: Strategic Requirements Analysis for Kids Help Phone• Kids Help Phone (KHP) is a not-for-

profit organization which provides counseling for Canadian children and youth.

¨ Traditionally, KHP has provided counseling via phone¨ As new technology is introduced, KHP wanted to go where

the kids are: the web¨ How can counseling services be effectively provided on-

line?¨ How can the organization continue to ensure:

¨ Anonymity? Confidentiality? Quality of Service?Paja, Horkoff, and Mylopoulos -- OIS 2014-15

4

Example Project: Security Requirements of a WiFi-based Navigation System

Location estimation Security issues: WiFi access

points may be switched off

• In a WiFi-based navigation system, users navigate inside buildings using WiFi access points• The system could use existing WiFi access points or could install new access points• Using existing access points saves money


5

Example Project: Case Study: “Greening” of ICSE Conference

• ICSE’09 wants to “go green”, cutting down it’s ecofootprint• The conference must balance this goal with other factors

affecting overall conference success, including:▫ Quality program, satisfied attendees, quality venue, good

keynotes, positive relationship with sponsors, financial success, quality workshops, involvement of industry,…

• How can we reason over and make tradeoffs between sustainability and other goals?


6

How would you apply RE techniques to these cases?

• Kids Help Phone

• WiFi-based Navigation System

• “Greening” of ICSE Conference


7

Goal-Oriented Requirements Engineering • GORE aims to capture both social and technical

aspects of computer systems. • In GORE, we want to capture: ▫ Agents (actual concrete participants)▫ Goals of agents (their objectives)▫ Dependencies between agents ▫ Relationships between agents ▫ Alternative solutions▫ Relationships between goals ▫ Goal satisfaction

• We typically capture these aspects using graphical models.


8

GORE for Early RE

• GORE is typically used for Early RE. • What do you need to be concerned about?▫ Solving the wrong problem▫ Socio-technical system failure, disuse▫ Changing needs▫ Changing regulations▫ Globalization, internationalization


9

Verification vs. Validation (SE Viewpoint)


A problem within the

world

Requirement Specification

A System

Describes

Elicitation

Verification

Validation

GORE Helps here:Fitness for a purpose

10

How does this fit into OIS? EA?


Enterprise (Complex Organization)

Sub-organization

People

Information Systems

Processes

Traditionally, GORE asks:Why? How? For systems as part of Software Engineering

But GORE can also be used for analysis at a higher level, business & enterprise analysis

11

GORE Frameworks

• There are several different approaches to GORE modeling: ▫ NFR (Non-Functional Requirement) Framework▫ i* Framework (Distributed Intentionality)▫ GRL (Goal-Oriented Requirements Language) ▫ Tropos▫ KAOS (Knowledge Acquisition in autOmated

Specification of software systems)

• Examples in this presentation will use i*.


12

i* background

• Developed in the early 90’s (PhD thesis by Eric Yu)▫ provides a framework for asking ‘why’ questions▫ models the organisational context▫ based on the notion of an “intentional actor”

• Two parts of the model▫ Actor Diagrams (AD): model social relationships

between actors▫ Rationale Diagrams (RD): model goals and

subgoals of actors


13

The i* approach

• AD model shows dependencies between actors:▫ goal/softgoal dependency - actor depends on another

to attain a goal▫ resource dependency - actor needs a resource from

another▫ task dependency - actor needs a task to be done by

another• RD model shows interactions between goals

within each actor▫ Shows goal/task decompositions▫ Shows means-ends links between tasks and goals


14

GORE Approach: Model Social Relationships for Analysis and Design

• Strategic actors

▫What do I want?

▫ How can I achieve what I want?

▫Who do I depend on to achieve what I want?


15

i*: Strategic Dependency (SD) Relationship


Actor A

I want …

Actor B

I can and I will…

D DCar Be Repaired

16

Strategic actors• Have goals, beliefs, abilities, commitments• Are strategic in the sense that they act in ways that

help them achieve their goals• Are semi-autonomous ▫ freedom of action, constrained by relationships with

others▫ not fully knowable or controllable▫ have knowledge to guide action, but only partially

explicit• Depend on each other▫ for goals to be achieved, tasks to be performed,

resources to be furnished


17

i* Strategic Dependency Diagram (1)

• Actors: General type▫ Agent: software or social agent:

� E.g. Counseling System, ICSE, Web Service, KHP▫ Role: collection of responsibilities

� E.g. Client, Kid, Counselor, PC Chair▫ Position: collection of roles

� E.g. Counseling Manager

• Actor Associations:▫ Plays, is-a, occupies, ins, is part-of

• These concepts can be used to draw actor association diagrams


Actor

Position

18

Dependency types• Goal Dependency: for an assertion to be brought

about, depender does not care how the assertion is achieved

• Task Dependency: for an activity to be performed, the dependency stipulates what has to be done

• Resource Dependency: for an entity to be transferred (provided): the depender needs that resource

• Softgoal Dependency: a softgoal is a goal having a non-sharp satisfaction criteria – the depender requires a good enough strategy to be carried out


19

SD Example: “Greening” of ICSE Conference


20

Example: WiFi-based Navigation System Requirement Analysis • How to analyze the threats that actors cause for each

other?▫ Who provides what information and for whom?▫ Who trusts who and what for?


21

i* Strategic Rationale Diagrams

• Actor boundaries• Goals, Softgoals, Tasks, Resources• Dependencies (as before)• Decomposition (AND), Means-Ends (OR)

• Contribution: Make, Help, Hurt, Break, Unknown


22

Goals and softgoals

• What are (Hard) Goals?▫ Describe desired states of affairs▫ Are “binary”, they can be satisfied or not satisfied▫ Examples: Raise Profit by 10% in the next year

• What are Softgoals?▫ Are not really “binary”, no strict criteria for

satisfaction and denial, judged to be sufficiently satisfied▫ Examples: happy customers, high profitability,

compatibility, usability, affordability, maintainability, etc.; but also low cost, reduce costs, increase profits, etc.


23

Relationships between goals • Decomposition: From a (soft)goal to a (soft)goal▫ AND: All “children” of (soft)goal must be satisfied for

it to be satisfied▫ OR: One or more “children” of soft(goal) need be

satisfied for it to be satisfied.▫ Between homogeneous goal types!!

• Full contribution: From a (soft)goal to a (soft)goal▫ ++ A goal makes (satisfies) another▫ -- A goal breaks (denies) another

• Partial contribution: From a (soft)goal to a softgoal▫ + A goal helps (partially satisfies) another▫ - A goal hurts (partially denies) another


24

SR Example: Kids Help Phone• What are the goals of KHP?• What are the relationships

between the goals?• What are the alternatives?• How can these goals be

satisfied? • What are the negative

consequences?• Who do we depend on?• For what?• How?


25

SR Example: Wifi (high-level overview)


26

i*: modeling primitives


27

i* Modeling Practice The ICSE Conference Program Committee (PC) Chair

needs to select full papers for the conference. He/she can either have an online meeting of the committee or have a meeting in person. The General chair depends on the PC Chair to have a high quality program. The Sustainability chair depends on the PC Chair to reduce pollution. Having an in-person meeting would require the committee members to take many flights, but having an online meeting may make it difficult for the Program Committee to make good decisions. How can we show this in an i* model?


28




Actors?

29


30




Goals? Tasks?

31




Goals? Tasks?

32


33




Softgoals?

34




Softgoals?

35


36




Relationships?

37




Relationships?

38


39

Example: “Greening” of ICSE ConferenceRequirements Analysis

• From the perspective of the General Chair• Model presented using views


40

SD View


41

General View


42

Publications and Program


43

Finance, Sponsorship, Advertising


44

Sustainability & Local Org


45

Everything


46

SR Example: ICSE Greening


47

Many More Motivating Examples…• Air Traffic Control▫ Lockerbie (City University London), Bush (NATS, UK), Maiden (City University

London), Blom, Everdij (National Aerospace Laboratory (NLR), The Netherlands)▫ Paja, Dalpiaz, Giorgini (University of Trento, Italy), Paul (Thales Research and

Technology, France), Meland (SINTEF, Norway)

• Agile Adoption in Telecommunications▫ Chiniforooshan, Yu (University of Toronto), Annosi (Ericsson Research Italy)

• Civil Construction▫ Alencar (Dep. Eletrônica e Sistemas), Castro (Centro de Informática), Menezes

(Dep. Engenharia Civil, Universidade Federal de Pernambuco, Brazil), Silva, Santos (Centro de Informática)

• Adverse Event Management in Healthcare▫ Ahmadi Behnam and Daniel Amyot (University of Ottawa), Forster (The Ottawa

Hospital)

• … From the iStar Showcase’11: http://www.cs.toronto.edu/km/istar/iStarShowcase_Proceedings.pdf


48

Benefits of Goal Modeling

• Elicit stakeholder needs• Facilitating cognitive understanding of stakeholder

needs, dependencies, etc.• Communication between and among stakeholders and

analysts• Shared understanding• Making explicit what was implicit (goals, softgoals,

dependencies)• Capturing alternative requirements and solutions• Selecting alternative solutions, trade off analysis• …


49

What you can do with goal models?

▫ Requirements Elicitation and documentation ▫ Communication▫ Model Analysis▫ Design Rationale ▫ Trade-off Analysis ▫ Security Analysis


50

Requirements Elicitation and Documentation

Derive

Goal Model

Requirements


51

Communication• Use a goal model along with textual

documentation to describe a situation or issue


What do Counselors want to achieve?

52

Model Analysis• Several approaches to analysis in GORE• Example approach: Use labels to represent degree of

satisfaction

• Use algorithms to propagate labels throughout the model using propagation rules

• Use human judgment to resolve conflicts


53

Application Attract Users

Implement Password System

Restrict Structure of Password

Ask for Secret

Question

Security Usability

Help

Hurt

Mak

e

Help Help

Example: Forward Evaluation of i* Models• Demonstrate the procedure through an example• Evaluation based on an analysis question:▫ If the Application implements Restrict Structure of Password,

but not Ask for Secret Question, what effect will this have on Attract Users?

• Place Initial Labels reflecting Analysis Question

Paja, Horkoff, and Mylopoulos -- OIS 2014-15 54

Example: Forward Evaluation of i* Models• Propagate labels• Resolve labels• Iterate on the above steps until all labels have been propagated





Ask for Secret

Question

Security Usability

Help

Hurt

Mak

e

Help HelpHuman Intervention

Attract Users Receives the following Labels:

Partially denied from Usability

Partially satisfied from Security

Select Label…

Select partially denied

Human Intervention

Usability Receives the following Labels:

Partially denied from Restrict Structure of Password

Partially denied from Ask for Secret Question

Select Label…

Select denied

55

Interactive Evaluation of i* Models• Analyze result▫ If the Application implements Restrict Structure of Password, but

not Ask for Secret Question, Attract Users is partially denied, as Usability, considered important by the evaluator, is denied.▫ This is not a viable design alternative.

• Next Steps: ▫ Repeat with new

analysis question…





Ask for Secret

Question

Security Usability

Help

Hurt

Mak

e

Help Help

56


?

!?!?!?!?!?

57

Design Rationale• Explicit listing of decisions made during a design process ▫ Why decisions were made

• Using i* notation, design rationale can be recorded as different contributions of alternative design choices


58

Trade-off Analysis

S1 S2

G

T1T2

Help

HelpHurt Hu

rt

S1 and S2 are in trade-off that is caused by T1

and T2 alternatives

S4 S5

G

T1T2

Help Hu

rt

S1

S3 S6

S2

Help Help

Make

Make

Help

Make Help

Break

T3 T4

Alternatives S1 S2 S3 S4DependingonWiFi Signals

DependingonRFIDPaja, Horkoff, and Mylopoulos -- OIS 2014-15

59

Resources for More Information

• iStar Workshop Series▫ iStar’14 co-located with CAiSE’14, June in Greece

• i* Wiki: ▫ http://istar.rwth-aachen.de/tiki-index.php

• Incomplete i*-related publication list:▫ http://istar.rwth-aachen.de/tiki-index.php?page_ref_id=4

• i* Linked-in group:▫ http://www.linkedin.com/groups/istar-modeling

• i* Citeulike:▫ http://www.citeulike.org/groupfunc/14571/home


60

i* Guide (Quick and Full)


61

i* related Tools• See http://istar.rwth-aachen.de/tiki-

index.php?page=i%2A+Tools for a list of available i*-related tools, for example:▫ OME, OpenOME, GR-Tool, ST-Tool, jUCMNav, Adoxx-istar,

IStar Tool, the RE-Tools, STS-Tool, CSRML Tool, BIM-Tool, TAGOOn Tool, …

• Tool fair as part of iStar’11 and iStar’13• OpenOME (i*)▫ http://sourceforge.net/projects/openome/

• jUCMNav (GRL)▫ http://marketplace.eclipse.org/content/jucmnav#.Uxmbafl

dXck• STS-Tool (STS) – focus on security▫ http://www.sts-tool.eu/


62

Tool Support: OpenOME


Project Explorer

Alternatives Tab

Canvas

Palette

Tree View

Outline View

Analysis Buttons

Judgments Tab

Horkoff, Yu, iStar Tool Fair’11

63

Tool Support: jUCMNav


Modeling elements

Evaluated GRL model, with quantitative contributions

and satisfaction levels, color highlight and trends

Group of 3

strategies

64

Amyot, Mussbacher, Ghanavati, Khealey, iStar’11http://ceur-ws.org/Vol-766/paper29.pdf

GORE: Conclusions

• Goal-oriented requirements engineering emphasizes the social and intentional aspects of system development▫ Explicitly address users goals▫ Who? How? Why?

• Several approaches/frameworks to goal modeling• Approaches for goal analysis (more lectures and tutorials

to come)• Many extensions/applications (STS, BIM, etc… more to

come)• Active community• Several challenges and open issues▫ More work to be done!


65

References (1)• E. Yu: Strategic Business Modeling with i* . Presented at CASCON

Workshop on Requirements-Driven Business Process Modelling and Performance Management. Markham, Ontario, Canada, October 29, 2008

• E. Yu: Social Modeling and i* - Themes and Variations. Seminar presented at Tilburg University, The Netherlands, June 9, 2009

• E. Yu, J. Castro, A. Perini: Strategic Actors Modeling with i*. RE 2008 – Tutorial.


66

References (2)• S. Easterbrook (PI), E. Yu (PI), J. Aranda, J. Horkoff, M. Strohmaier, Y.

Fan, M. Leica, and R. Abdul Qadir:▫ Strategic Requirements Analysis for Kids Help Phone. U of T DCS Undergraduate

Open House.▫ Kids Help Phone: Understanding the Counselling Service

through Requirements Modelling. Presented to KHP, Nov. 2004.• J. Cabot, S. Easterbrook, J. Horkoff, J. N. Mazon, L. Lessard, S. Liaskos:

Integrating Sustainability in Decision-Making Processes: A ModellingStrategy. ICSE 2009 New Ideas and Emerging Results (NIER’09).

• J. Horkoff, J. Aranda: Requirements Specification for the “Ask a Counsellor” Project for Kids Help Phone. Version 1.1 – Oct. 25, 2005.

• J. Horkoff, E. Yu: Qualitative, Interactive, Backward Analysis of i* Models. i* Workshop, 2007.

• J. Horkoff, E. Yu: A Qualitative, Interactive Evaluation Procedure for Goal-and Agent-Oriented Models. The 21st International Conference on Advanced Information Systems (CAiSE’09) Forum. Short Paper.


67

Acknowledge

Original slides from Elda Paja, Jennifer Horkoff and Golnaz Elahi


68

Goal-Oriented Requirements Engineering -...

Documents

Transcript of Goal-Oriented Requirements Engineering -...