Goal-Oriented Requirements Engineering: Part II Abstract

Goal-Oriented Requirements Engineering: Part II John Mylopoulos University of Toronto/Trento

14th IEEE Requirements Engineering Conference Minneapolis, September 15, 2006

© 2006 John Mylopoulos

RE'06 -- 1

Abstract 



We briefly review the history and key ideas in Goal-Oriented Requirements Engineering research. We then sketch two applications of these ideas. The first involves establishing an Agent-Oriented Software Development method called Tropos which covers not only requirements but also design phases. The second addresses the design of high-variability software for applications such as home care software and business process design. The research reported in this presentation was conducted with colleagues at the Universities of Toronto (Canada) and Trento (Italy).

© 2006 John Mylopoulos

RE'06 -- 2

1

GORE, Parts I & II  









GORE = Goal-Oriented Requirements Engineering Axel van Lamsweerde delivered a keynote talk with this title at RE'04 in Kyoto. His talk reviewed the history and key ideas of GORE and described some of the on-going research and industrial experiences of the KAOS project. The talk made an elegant case important edition to SE practice.

for

GORE

as

an

In this presentation, I review some of the research results and on-going work of the i*/Tropos project. I'll also make the case for GORE as a foundation for a Theory of Software Design.

© 2006 John Mylopoulos

RE'06 -- 3

This Talk    

Goal-Oriented RE -- History and key ideas Moving forward -- Tropos Moving forward -- Designing high-variability software Afterthoughts and conclusions

© 2006 John Mylopoulos

RE'06 -- 4

2

Goal-Oriented Requirements Engineering (~1993) 





Goal-oriented analysis focuses on early requirements, when problems are identified, and alternative solutions are explored and evaluated. During goal-oriented analysis, we start with initial stakeholder goals such as “Fulfill every book request”, or “Schedule meeting” and keep refining them until we have reduced them to alternative collections of functional requirements each of which can satisfy the initial goals. Initial goals may be contradictory, so the analysis must facilitate the discovery of tradeoffs and the search of the full space of alternatives, rather than a subset.

© 2006 John Mylopoulos

RE'06 -- 5

Goal-Oriented Analysis a la KAOS  





(Organizational) goals lead to requirements. Goals justify and explain the presence of requirements which are not necessarily comprehensible by clients. Goals provide basic information for detecting and resolving conflicts that arise from multiple viewpoints [Dardenne93]. Example goal: SystemGoal Achieve[BookRequestSatisfied] InstanceOf SatisfactionGoal Concerns Borrower, Book, Borrowing,... Definition ( ∀bor: Borrower, b: Book, lib: Library) (Requesting(bor, b) ∧ b.subject ∈ lib.coverageArea ⇒ F[(∃bc: BookCopy) (Copy(bc, b) ∧ Borrowing(bor, bc)))]

© 2006 John Mylopoulos

RE'06 -- 6

3

Goal Analysis Leads to Alternatives Schedule meeting

(Functional/hard) Goals AND

AND

Collect timetables OR

Choose schedule OR

By System

By Person

OR

OR

OR

OR

Manually

Collect from users

Collect from agents

AND

Automatically

AND

Send request

Receive request

© 2006 John Mylopoulos

RE'06 -- 7

Alternatives Lead to Designs/Plans Schedule meeting AND

AND

Collect timetables OR

Choose schedule OR

By System

By Person

OR

OR OR

AND

Collect © 2006 John Mylopoulos

Manually

Collect from users

Collect from agents

Tasks

OR

Send request

Automatically

AND

Receive request

Schedule

RE'06 -- 8

4

Softgoals 





Functional goals, such as “Schedule meeting” are well defined in the sense that they admit a formal definition. Non-functional goals, such “higher profits”, “higher customer satisfaction” or “easily maintainable system” specify qualities a socio-technical system should adhere to. Such qualities usually admit no generally agreed definition, are inter-related and often contradictory.



Such qualities are represented as softgoals.



Softgoals can be thought as “fuzzy goals” with

upon

no clear-cut criteria for satisfaction; hence softgoals are satisficed, rather than satisfied (NFR framework, [Mylopoulos92], [Chung93]). © 2006 John Mylopoulos

RE'06 -- 9

Softgoals for Representing NonFunctional Requirements Usability AND Error Avoidance

AND

AND

AND

Information Sharing

Ease of Learning AND User Flexibility

Allow Change of Settings Support Change of Colours

+ + +

Support Change of State Change colour Change state

© 2006 John Mylopoulos

User Tailorability

+

AND

Programmability

+

Modularity Support Change of Language

+ Use Components

+ Allow User-Defined Writing Tool

Change language RE'06 -- 10

5

Good quality schedule

Minimal effort

AND AND AND

AND

Minimal conflicts

Matching effort

Collection effort

Schedule meeting AND AND

+

-

Evaluating Alternatives with Softgoals

Collect timetables OR

-

Choose schedule

+ +

OR

OR

By System OR

Collect from Agents

+

+

OR

By Person

Minimal Disturbances

Good participation

OR

Collect from Users

Manually

Automatically

Accurate Constraints

+

AND

Send Request

AND

Receive Response

© 2006 John Mylopoulos

RE'06 -- 11

Stakeholders and Their Goals 







In KAOS, goals are global objectives for the system-tobe. In i* [Yu93], goals are desired by actors and are delegated to other actors for fulfillment. In this framework then, early requirements involve identifying stakeholders and their goals, analyzing these goals, delegating them to other actors etc. The result of this process consists of actor dependency and actor rationale models.

© 2006 John Mylopoulos

RE'06 -- 12

6

An Actor Dependency Model ContributeToMtg

actor

UsefulMtg

Initiator

ScheduleMtg

CalendarInfo

Participant

Scheduler AttendMtg

resource

task SuitableTime

© 2006 John Mylopoulos

RE'06 -- 13

An Actor Rationale Model By Person

Reception

Schedule Meeting goal tree

Through personal contact By email

Actor dependencies are intentional: One actor something, another is willing and able to deliver.

© 2006 John Mylopoulos

wants

RE'06 -- 14

7

Goals in Software Design 







KAOS, the NFR proposal, as well as i* advocate the use of goals in designing software. KAOS uses goals to go from organizational objectives to functional requirements. NFR uses them to represent and analyze non-functional requirements. Non-functional requirements lead to criteria for evaluate functional alternatives ( … AND functional requirements).

i* relates goals to the actors who want them and keeps track of delegations.

© 2006 John Mylopoulos

RE'06 -- 15

So What? Early Requirements Phase JACK

i*

GAIA

KAOS Z SADT

!! A GAP !!

AUML UML and co.

l ra te rly s u a a t L E nt c ts n en ite esig h me m c e d ir ire Ar qu qu e re r © 2006 John Mylopoulos

ed ail gn t De esi d

ion at t n me e l p Im RE'06 -- 16

8

Credits 

Many other researchers worked with goals a decade or more ago, including:  Martin Feather and Steve Fickas;  Colin Potts and Annie Anton;  Janis Bubenko;  Colette Rolland;  Periklis Loucopoulos and Evangelia Kavakli;

…

© 2006 John Mylopoulos

RE'06 -- 17

Goals, Intentions and Tasks 

 

 

Goals are desired states of affairs, e.g., "I want to be president of the USA" ( … ) Intention = goal + commitment Actions are things agents can perform to change the state of affairs. Task = action + intention We use "intention" and "goal" synonymously; likewise for "task" and "plan".

© 2006 John Mylopoulos

RE'06 -- 18

9

Expressiveness of Goal Models 



Different researchers use different different primitive goal relationships.

notations

and

In our work, we adopted a goal model that includes:  Goal types: (hard)goals, softgoals  Relationship types: AND (n-ary), OR (n-ary), ++ (makes, binary), -- (breaks, binary), + (helps, binary), - (hurts, binary)





This model without +, - is expressively equivalent to Propositional Calculus (PC). The problem of deciding if given root-level goals can be fulfilled can be reduced to the satisfiability problem in PC.

© 2006 John Mylopoulos

RE'06 -- 19

This Talk    

GORE -- History and key ideas Moving forward -- Tropos Moving forward -- Designing software Afterthoughts and conclusions

© 2006 John Mylopoulos

high-variability

RE'06 -- 20

10

…An Idea... (~2000) 





Software Engineering methods have traditionally come about in a “late-to-early” phase (or, “downstream-toupstream”) fashion. In particular, Structured Programming preceded Structured Analysis and Design; likewise, ObjectOriented Programming preceded Object-Oriented Design and Analysis. In both cases, programming concepts were projected upstream to dictate how designs and requirements are conceived.

What would happen if we projected requirements concepts downstream to define software designs and even implementations? © 2006 John Mylopoulos

RE'06 -- 21

The Tropos Methodology 



Proposes a set of primitive concepts adopted from i* (actor, goal, actor dependency,…) and a process for building agentoriented software. Covers four phases of software development:  Early requirements -- identify stakeholders and their goals;  Late requirements -- introduce system-to-be as another actor who can accommodate some of these goals;  Architectural design -- more system actors are added and are assigned responsibilities;  Detailed design -- complete the specification of system actors.

© 2006 John Mylopoulos

RE'06 -- 22

11

Agent-Oriented Software Engineering 

Many researchers working on it.



Research on the topic generally comes in two flavours:  Extend UML to support agent communication, negotiation etc. (e.g., AUML [Bauer99, Odell00]);  Extend current agent programming platforms (e.g., JACK) to support not just programming but also design activities, e.g., GAIA [Jennings00].



All AOSE methods involve to a greater or lesser extend intentional concepts, analysis of alternatives, etc.

© 2006 John Mylopoulos

RE'06 -- 23

Software Development as Multi-Agent Planning 



Initialization: goals;

Identify

stakeholder

actors

and

their

Step: For each new goal, the actor who owns it:  adopts it;  delegates it to another existing actor;  delegates it to a new actor;  decomposes it into new subgoals;  declares the goal “denied”.



Termination condition: All initial goals have been fulfilled (…to an acceptable degree), assuming all actors deliver on their commitments.

© 2006 John Mylopoulos

RE'06 -- 24

12

Analyzing Tropos Models   

Models are used primarily for human communication But, this is not enough! Large models can be hard to understand, or take seriously. We need analysis techniques which offer evidence that a model makes sense:  Simulation through model checking, to explore the properties of goals, entities, etc. over their lifetime [RE'01, RE'03, REJ];  Goal analysis uses a SAT prover to determine whether a goal can be fulfilled [ER'02, JoDS'03, CAiSE'04];  Social analysis uses a planner to explore alternative delegations for a given set of actors and goals.



The tools we have developed use off-the-shelf inference engines (respectively nuSMV, MinWeight solver, LPG-td).

© 2006 John Mylopoulos

RE'06 -- 25

Phases

Palette

Diagram Editor

Model Properties Window

http://sra.itc.it/tools/taom/

© 2006 John Mylopoulos

RE'06 -- 26

13

Social Analysis Given a set of actors, each with associated root goals, and a goal graph for each root goal, find an actor AND dependency network that fulfills all root goals.



A1

A2

A1

G AND

G

AND

G1

A1

G2

G2

A2 G2

G1 © 2006 John Mylopoulos

RE'06 -- 27

Well-Formed Dependency Networks 

Some dependency graphs don’t make sense...

A1

G

A2

G



What is a “good” dependency network, assuming that we are interested in:  minimizing dependence;  distributing work;  network stability



PhD thesis by Volha Bryl (Trento).

© 2006 John Mylopoulos

RE'06 -- 28

14

The Tropos Project 

Project was launched in April 2000.



Participating teams includes:  UToronto (Canada): Eric Yu, Alexei Lapouchnian, Sotirios Liaskos, Yijun Yu, Yiqiao Wang, Neil Ernst;  UTrento/IRST (Italy): Anna Perini, Angelo Susi, Loris Penserini, Paolo Giorgini, Fabio Massacci, Roberto Sebastiani, Nicola Zannone, Yudis Asnar, Volha Bryl, Paolo Traverso,...;  Elsewhere: Jaelson Castro (Brazil), Matthias Jarke (Germany), Manuel Kolp (Belgium), Julio Leite (Brazil), Gerhard Lakemeyer (Germany), Lin Liu (China);



Publications and other information about the project can be found at http://www.troposproject .org. http://www.troposproject.org.

© 2006 John Mylopoulos

RE'06 -- 29

This Talk    

GORE -- History and key ideas Moving forward -- Tropos Moving forward -- Designing software Afterthoughts and conclusions

© 2006 John Mylopoulos

high-variability

RE'06 -- 30

15

Designing for High Variability 



Instead of choosing one solution for the fulfillment of a top-level goal, we could choose to support them all. This leads to software solutions that can be customized in many different ways, depending on stakeholder preferences and environmental parameters.

© 2006 John Mylopoulos

RE'06 -- 31

On-Going Research 





From goals to generic designs: Develop a tool-supported method for generating different design views from a given goal model; in our work we have focus on the generation of a feature model, a statechart model and a software architecture. Characterize variability: Goal models constitute one source of variability in design, but there are also others. These may be dependent on what is the design about (e.g., software, business process, database) [RE'06a, RE'06b]. PhD theses by Sotiris Liaskos, Alexei Lapouchnian, Lei Jiang (Toronto).

© 2006 John Mylopoulos

RE'06 -- 32

16

Good quality schedule

Minimal effort

AND AND AND

AND

Minimal conflicts

Matching effort

Collection effort

Good participation

Schedule meeting AND AND

Collect timetables

+

-

OR

+

-

Choose schedule

+ +

OR

VP1

OR

By Person

VP2

By System OR

VP3

Collect from Agents

+

OR

Collect from Users

Manually

AND

+

-

Minimal Disturbances

Send Request

Accurate Constraints

OR

AND

Receive Response

From a Goal Model to Design Views Automatically

© 2006 John Mylopoulos

RE'06 -- 33

… to a Feature Model Good quality schedule

Minimal effort

AND AND AND

AND

Collection effort

Schedule meeting

Schedule meeting AND AND

Collect timetables

+

-

OR

+

-

+ +

OR

By Person

Choose schedule

OR

OR

By System OR

Collect from Agents

+ Minimal Disturbances

Good participation

Minimal conflicts

Matching effort

OR

Collect from Users

Manually

Accurate Constraints

+

AND

Send Request

AND

Receive Response

Automatically

Collect timetables VP1 By System VP3 Collect from Agents

Choose schedule VP2 Automatically

Request from Users

Send Request

Receive Response

+conflicts [minimal disturbances ] +conflicts [accurate constraints] © 2006 John Mylopoulos

RE'06 -- 34

17

… to a Statechart AND

Good participation

AND AND AND

Minimal conflicts

Matching effort

Collection effort

Schedule meeting AND AND

Collect timetables

+

-

OR

+

-

Choose schedule

+ +

OR

By Person

OR

[VP1 =1 ]/b y_ perso

OR

By System OR

+

n

OR

Collect from Agents

Minimal Disturbances

Schedule meeting

Good quality schedule

Minimal effort

Collect from Users

Manually

Automatically

Choose schedule

AND

+

Accurate Constraints

AND

Send Request

Receive Response

[VP1=2]

[VP2=1]/ma nually [VP2]=2/automa tically

[VP3=1]/collectByAgents [VP3=2] Se nd Req uest

...

rec eiv e re sp onse

© 2006 John Mylopoulos

RE'06 -- 35

IScheduleMeeting

Minimal effort

AND AND AND

AND

Collection effort

Collect timetables

+

AND

+

-

+ +

OR

By Person

Choose schedule

OR

OR

Collect from Agents

+ -

Accurate Constraints

IGetConstraints Constraint Input UI

VP3

ICommunicateReqs

OR

Collect from Users

Manually

+

RequestCnstr

Communication Module

By System OR

Automatic Collection

Find Address

AND

OR

Minimal Disturbances

Schedule meeting

-

-

VP1

IFindUserAddr

Good participation

Minimal conflicts

Matching effort

IPrepare ICollectConstr

Constraint Collection Module Constraint Request Server

Good quality schedule

Scheduling Mgr

Prepare UI

ISelectSlotAuto

… to a Software Architecture

Meeting Scheduler

AND

Send Request

AND

Automatically

Request Mailer

Request Instant Messaging

Receive Response

Slot Calculator

VP4 Priority Based Algorithm

© 2006 John Mylopoulos

TravelCost Minimization Algorithm

Conflicts Minimization Algorithm

RE'06 -- 36

18

Why is this Problem Important? 





Enterprise Resource Planning (ERP) software is generic and can be customized in (very) many different ways. But we don't have yet systematic ways of generating such designs. Envisioned applications for high-variability software:  Business process design (Alexei Lapouchnian);  Home care software for the elderly (Sotiris Liaskos).

© 2006 John Mylopoulos

High-Variability Business Goal Model

RE'06 -- 37

BP Specifications for All the Alternatives

Open OME

WB Modeler

Elicit/Analyze

Simulate/Analyz e

High-Variability BPEL

Business Measures

WID

WB Monitor

From Business Requirements To Adaptive Business Processes

BPEL, WSDL, XSD

WID

CBEs/CEI Integrate

Monitor

Integrate

WPS

[Lapouchnian06] © 2006 John Mylopoulos

Deploy

RE'06 -- 38

19

Autonomic (Application) Software 









(According to IBM) This is software configure, self-repair and self-optimize.

that

can

self-

For us, Autonomicity = High-Variability+Monitoring+Diagnosis+Adaptivity Our goal-oriented framework may not be appropriate for autonomic system software (e.g., an OS) or middleware (e.g., a DBMS); But it certainly is for application software! Different mechanisms required for  Self-repair -- real-time reconfiguration and recovery  Self-configuring and self-optimization -- off-line reconfiguration, no recovery PhD thesis by Yiqiao Wang (Toronto) is looking at the problem of designing monitoring and diagnostic mechanisms for autonomic software.

© 2006 John Mylopoulos

RE'06 -- 39

Other Threads 



[Security] Extend Tropos to support concepts of ownership, permission and trust; this leads to models where you can check whether every actor has the permissions she needs to carry out her obligations [RE'05]; PhD thesis by Nicola Zannone (Trento). [Risk Management] Extend the DDP risk management framework [Feather05] to allow hierarchical goal/requirement and risk decompositions; PhD thesis by Yudis Asnar (Trento).

© 2006 John Mylopoulos

RE'06 -- 40

20

This Talk    

GORE -- History and key ideas Moving forward -- Tropos Moving forward -- Designing software Afterthoughts and conclusions

high-variability

© 2006 John Mylopoulos

RE'06 -- 41

Research on Modelling 





Much research in RE involves building and analyzing models. Not surprisingly, the quality of such research depends critically on (a) the modelling language used, (b) the reasoning facilities provided. Two pitfalls to avoid:  Treating variations contributions;

of

modelling

languages

as

 Proposing new modelling languages, instead of building on what already exists. 

There is a very rich theory of (formal) models and reasoning support to be found in Knowledge Representation research.

© 2006 John Mylopoulos

RE'06 -- 42

21

Formal vs Informal 





Many of the modelling language we (in the RE community) use are formal. There are great (and known) pitfalls in using informal ones. Most of the models we built are semi-formal; this means that the models capture and formalize some aspects of the domain, but not all. This is the nature of the SE enterprise … For example,

Good quality schedule

Minimal effort

AND AND AND

AND

Collection effort

Schedule meeting AND AND

Collect timetables

+

-

OR

+

-

+ +

OR

By Person

Choose schedule

OR

OR

By System OR

Collect from Agents

+ Minimal Disturbances

Good participation

Minimal conflicts

Matching effort

OR

Collect from Users

Manually

Automatically

Accurate Constraints

+

AND

Send Request

AND

Receive Response

© 2006 John Mylopoulos

RE'06 -- 43

The Big Picture … 







We are working on characterizations of design spaces for software, business processes, databases, …. These spaces are partly defined by variations in goal fulfillment and actor delegation strategies, but also on other dimensions. We are also working on a theory for evaluating design alternatives with respect to a set of criteria consisting of stakeholder needs and preferences. These together can form the basis for a theory of design, along the lines of Herbert Simon's vision for a Science of Design [Simon69].

© 2006 John Mylopoulos

RE'06 -- 44

22

What is Missing? 









The (qualitative) models we built may be formalizable, BUT they are subjective. We need theories of measurement for cognitive/social phenomena. Our models are often under-constrained, include too many variables [Menzies99]. To have autonomic/adaptive systems, models and their implementations will need to evolve at run-time. … For sure, other things as well …

© 2006 John Mylopoulos

RE'06 -- 45

Conclusions 





GORE introduces new concepts in software development processes. We have argued that GORE shows a path towards defining and analyzing design spaces for software. We also sketched two applications of GORE concepts:  Designing agent-oriented software -- the Tropos project [JAAMAS04, JInformationSystems03];  Designing high-variability software [RE'03, RE'06a, RE'06b].

© 2006 John Mylopoulos

RE'06 -- 46

23

References  

  





[Bauer99] Bauer, B., Extending UML for the Specification of Agent Interaction Protocols. OMG document ad/99-12-03. [Castro02] Castro, J., Kolp, M., Mylopoulos, J., “Towards Requirements-Driven Software Development Methodology: The Tropos Project,” Information Systems 27(2), Pergamon Press, June 2002, 365-389. [Chung00] Chung, L., Nixon, B., Yu, E., Mylopoulos, J., Non-Functional Requirements in Software Engineering, Kluwer Publishing, 2000. [Dardenne93] Dardenne, A., van Lamsweerde, A. and Fickas, S., “Goal–directed Requirements Acquisition”, Science of Computer Programming, 20, 1993. [Fuxman01a] .Fuxman, A., Pistore, M., Mylopoulos, J. and Traverso, P., “Model Checking Early Requirements Specifications in Tropos”, Proceedings Fifth International IEEE Symposium on Requirements Engineering, Toronto, August 2001. [Fuxman01b] Fuxman,A., Giorgini, P., Kolp, M., Mylopoulos, J., “Information Systems as Social Organizations”, Proceedings International Conference on Formal Ontologies for Information Systems, Ogunquit Maine, October 2001. [Iglesias98] Iglesias, C., Garrijo, M. and Gonzalez, J., “A Survey of Agent-Oriented Methodologies”, Proceedings of the 5th International Workshop on Intelligent Agents: Agent Theories, Architectures, and Languages (ATAL-98), Paris, France, July 1998.

© 2006 John Mylopoulos

RE'06 -- 47

...More References…  





 

 

[Jennings00] Jennings, N. “On Agent-Based Software Engineering”, Artificial lntelligence 117, 2000. [Menzies99] Menzies, T., Easterbrook, S., Nuseibeh, B., and S.Waugh. “An Empirical Investigation of Multiple Viewpoint Reasoning in Requirements Engineering”, In RE’99, 1999. Available from http://menzies.us/pdf/99re.pdf. [Mylopoulos92] Mylopoulos, J., Chung, L. and Nixon, B., "Representing and Using NonFunctional Requirements: A Process-Oriented Approach," IEEE Transactions on Software Engineering 18(6), June 1992, 483-497. [Odell00] Odell, J., Van Dyke Parunak, H. and Bernhard, B., “Representing Agent Interaction Protocols in UML”, Proceedings 1st International Workshop on Agent-Oriented Software Engineering (AOSE00), Limerick, June 2000. [Simon69] Simon, H., The Sciences of the Artificial, The MIT Press, 1969 [Wooldridge00] Wooldridge, M., Jennings, N., and Kinny, D., “The Gaia Methodology for Agent-Oriented Analysis and Design,” Journal of Autonomous Agents and Multi-Agent Systems, 3(3), 2000, 285–312. [Yu95] Yu, E., Modelling Strategic Relationships for Process Reengineering, Ph.D. thesis, Department of Computer Science, University of Toronto, 1995. [Zambonelli00] Zambonelli, F., Jennings, N., Omicini, A., and Wooldridge, M., “AgentOriented Software Engineering for Internet Applications,” in Omicini, A., Zambonelli, F., Klusch, M., and Tolks-Dorf R., (editors), Coordination of Internet Agents: Models, Technologies, and Applications, Springer-Verlag LNCS, 2000, 326–346.

© 2006 John Mylopoulos

RE'06 -- 48

24