Goal-Oriented Requirements Engineering

8/22/2019 Goal-Oriented Requirements Engineering

1/73

GoalGoal--OrientedOriented RequirementsRequirements

EngineeringEngineering::TheThe TROPOS CaseTROPOS Case

Jaelson Castro

Universidade Federal de PernambucoCentro de Informtica

Brasilwww.cin.ufpe.br/~jbc

[email protected]


2/73

2@2007 Jaelson Castro

AbstractAbstract

The last decade has seen the rise of a new phase in softwaredevelopment which is concerned with the acquisition, modellingand analysis of stakeholder purposes ("goals") in order to derive

functional and non- functional requirements. In this talk we revisitthe topic and sketch on-going research on a number of fronts.Specifically, we discuss an agent-oriented software developmentmethodology -- called TROPOS that is founded on the conceptsof goal, actor as well as inter-actor dependencies. We review key

research results and milestones for the TROPOS project. Wealso present some on-going research that applies TROPOSresearch

The research reported in this presentation was conducted with

colleagues atthe Universities of Recife (Brasil), Toronto (Canada)and Trento (Italy).


3/73


AgendaAgenda

Motivation

Goal Oriented Requirements Engineering

Introduction to TROPOS

Some results and on-going work Conclusions


4/73


AgendaAgenda

Motivation





5/73


Caos !

16% 53% 31%

27% 33% 40%

26% 46% 28%

28% 49% 23%

0% 50% 100%

1994

1996

1998

2000

Succeeded Challenged Failed

Project success ratesare rising. This chartdepicts the resolution ofthe 30,000 applicationprojects in large,medium and smallcross-industry U.S.companies tested by

The Standish Group

since 1994.

Despite this progress,The Standish Groupcautions that challengedand failed projects

remain the norm.

- Jim Johnson, Software

Magazine, 2001

Project success ratesare rising. This chartdepicts the resolution of

the 30,000 applicationprojects in large,medium and smallcross-industry U.S.companies tested by

The Standish Group

since 1994.

Despite this progress,The Standish Groupcautions that challengedand failed projects

remain the norm.

- Jim Johnson, Software

Magazine, 2001

The project is

completed and

operational, but over

budget, late, and with

fewer features and

functions than initially

specified.

The project is

completed on time

and on budget, with

all features and

functions originally

specified.

The project is

canceled before

completion, or

never

implemented.


6/73


Causes for Project Failure

- A Standish Group Research Note Copyright 2000

Involvement/

OwnershipRequirements

Management

SupportPlanning Staff

CHAOS 10

Formal methodologyProper planningProper planningOwnership

Clear business objectivesExperienced project managerFirm basic requirementsProper planning

Firm basic requirementsCompetent staffExperienced project managerCompetent staff

Reliable estimatesOwnershipOwnershipClear vision and objectives

OtherOtherOtherHard-working, focused staff

Standard software infrastructureFirm basic requirementsSmall project milestonesSmall project milestones

Minimized scopeSmall project milestonesCompetent staffRealistic expectations

Experienced project managerClear statement of requirementsClear statement of requirementsClear statement of requirements

User involvementExecutive management supportExecutive management supportExecutive management support

Executive management supportUser involvementUser involvementUser involvement

2000199919961994


7/73


- Gause, Donald and Gerald Weinberg. Exploring Requirements: Quality Before Design

1 1015-40

30-70

40-1000

0

100

200

300

400

500

600

700

800

900

1000

Requirements Design Coding Developmenttesting

Acceptancetesting

Operation

Phase in which found

UnitC

ost

3-6

Relative CostRelative CostAvoidAvoid vs. Fixvs. Fix

80% of a typical products development time is spentcorrecting errors not discovered in the beginning of the product.

debugging

redeveloping

- Software Project Survival Guide, Steve McConnell, 1998

Hidden FactoryHidden Factory

Corrections$$

ReasonsReasonsfor Reworkfor Rework

Inadequate

Requirements

27%

Imprecise

Terminology

16%

Logic error

3%

Undocumented

Assumptions

30%

Traceability/

inconsistency

24%

- Experiences using Formal Methods for Requirements Modeling. Easterbrook, et al.

80%80% of a typical productof a typical products developments development

time is spent intime is spent in correcting errorscorrecting errors

MostMost rework is related torework is related to inadequate,inadequate,

inconsistent, impreciseinconsistent, imprecise requirementsrequirements

Fixing a defect late in the developmentFixing a defect late in the development

life cycle canlife cycle can cost 30cost 30--1000 times more1000 times more


8/73



9/73



10/73



11/73



12/73


AgendaAgenda

Motivation





13/73


RequirementsRequirements--Driven ISDriven IS Information System Engineering (IS) is concerned with concepts,

tools and methods for building information systems.

Traditionally, IS Engineering has been implementation-driven.

This means that the programming paradigm of the day dictated thedesign and requirements paradigms.

So, structured programming led to structured design and(requirements) analysis, while object-oriented programming led toobject-oriented design and analysis, etc

Aligning the paradigms used for requirements, design andimplementation makes perfect sense. But why start withimplementation?

What wouldWhat would requirementsrequirements--drivendriven

IS Engineering look like??IS Engineering look like??


14/73


Why RequirementsWhy Requirements--Driven?Driven?

Requirements analysis is arguably the most important phase ofinformation system development; thats where the most and thecostliest errors are introduced in software systems.

The importance of detailed design and implementation will wear offover time, thanks to software reuse, COTS, MDA and the like;requirements analysis will always be there and will always beimportant.

Requirements analysis is the phase where technology meets thereal world, where technical considerations have to be balancedagainst personal, organizational and social ones; this calls forspecial skills on the part of the requirements engineer, and makesthe phase particularly challenging.


15/73


Requirements AnalysisRequirements Analysis

This activity traditionally boils down to three tasks:

Context analysis -- the reasons whywhy the system is to becreated and why certain technical operational and economicfeasibilities are the criteria that form boundary conditions forthe system

Functional requirementsFunctional requirements -- whatwhat will the system is to do

NonNon--functional (quality) requirementsfunctional (quality) requirements -- globalconstraints on howhow the system is to be constructed andfunction


16/73


TheThe needneed forforGOREGORE

GORE = Goal-Oriented Requirements Engineering

Axel van Lamsweerde & John Mylopoulos delivered

keynote talks with this ti tle at RE'04 in Kyoto and

RE06 in Minneapolis.

Their talks made an elegant case for GORE as an

important edition to SE practice.

In this presentation, I review some of the researchresults and on-going work of the Tropos project.


17/73


GoalGoal OrientedOriented RequirementsRequirements EngineeringEngineering (~1993)(~1993)

Goal-oriented analysis focuses on early requirementsphases, when alternatives are being explored andevaluated.

During goal-oriented analysis, we start with initial goalssuch as Higher profits, Faster time-to-market,Schedule meeting, Easily maintainable system,Good performance etc. and keep decomposing them

until we have reduced them to alternative collections ofdesign decisions each of which can satisfy the initialgoals.

Initial goals may be organization - or system-oriented;

they may also be contradictory, so the analysis mustfacilitate the discovery of tradeoffs and the search of thefull space of alternatives, rather than a subset.

GORE

Tropo

s

Resu

lts

On-go

ing

Wor

k

Conc

lusio

ns


18/73


GoalGoal--Oriented Analysis is not New!Oriented Analysis is not New!

Many other researchers worked with goals a decade ormore ago including

Specification of composite systems -- [Feather87]

Goal-oriented elaboration of requirements -- ALBERT[Dubois94]

Goal-oriented requirements acquisition -- KAOS[Dardenne93]

Knowledge representation and reasoning in the designof composite systems -- Critter [Fickas92]

Goal-oriented requirements analysis -- Potts, Anton

I* and Non-Functional Requirements framework -- Yu,Chung

NATURE -- [J arke93]

F3 -- [Bubenko93], etc


19/73


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 resolvingconflicts that arise from multiple viewpoints [Dardenne93].

Example goal:

SystemGoalAchieve[BookRequestSatisfied]

InstanceOfSatisfactionGoalConcerns Borrower, Book, Borrowing,...

Definition (bor: Borrower, b: Book, lib: Library)


20/73


GoalGoalAnalysisAnalysis leadsleads totoAlternativesAlternatives


21/73


Alternatives Lead to Designs/Plans


22/73


SoftgoalsSoftgoals

Functional goals, such as Schedule meeting arewell defined in the sense that they admit a formal

definition.

Not all goals are functional. Non-functional goals, such higher profits , higher

customer satisfaction or easily maintainable

system specify qualities a socio-technical system

should adhere to.

Such qualities are represented as softgoals.


23/73


SoftgoalsSoftgoals

Such qualities usually admit no generally agreedupon definition, are inter-related and often

contradictory.

How well the system accomplishes its functions Softgoals can be thought as fuzzy goals with no

clear-cut criteria for satisfaction; hence softgoals

are satisficed, rather than satisfied (NFR

framework, [Mylopoulos92], [Chung93]).


24/73


SoftgoalsSoftgoals forforRepresentingRepresenting NonNon--

FunctionalFunctional RequirementsRequirements


25/73


EvaluatingEvaluatingAlternativesAlternatives withwith SoftgoalsSoftgoals


26/73


ii*: an Organizational Modeling Framework*: an Organizational Modeling Framework

Understanding the problem by studying an existingorganizational setting;

Output : Organizational model with relevant actors andrespective goals.

i* [Yu95]


27/73


i*: An Actor Dependency Modeli*: An Actor Dependency Model

GoalGoal

TaskTask

ResourceResource

SoftgoalSoftgoal

Media

Shop


28/73


i*: An Actor Rationale Modeli*: An Actor Rationale Model

Dependencies are intentional: One actor wantssomething, another is willing and able to deliver


29/73


GoalsGoals in Softwarein Software DesignDesign

KAOS, the NFR proposal, as well as i* advocate the useof goals in designing software

KAOS uses goals to go fromorganizational objectives

to functional requirements. NFR uses themto represent and analyze non-functional

requirements. Non-functional requirements lead to

criteria for evaluate functional alternatives ( ANDfunctional requirements).

i* relates goals to the actors who want themand keepstrack of delegations.


30/73


Benefits of GOREBenefits of GOREvanvan LamsweerdeLamsweerde (ICSE 2000)(ICSE 2000)

Systematic derivation of requirements from goals

Goals provide rationales for requirements

Goal refinement structure provides acomprehensible structure for the requirementsdocument

Alternative goal refinements and agent

assignments allow alternative system proposals tobe explored

Goal formalization allows refinements to be provedcorrect and complete.


31/73


GoalsGoals,, IntentionsIntentions andand TasksTasks

Goals are desired states of affairs, e.g., "I want to attendIDEAS 08 in Recife " ( )

Intention = goal + commitment

Actions are things agents can performto change thestate of affairs.

Task = action + intention

We use "intention" and "goal" synonymously; likewisefor "task" and "plan".


32/73


ExpressivenessExpressiveness ofofGoalGoal ModelsModels

Different researchers use different notations anddifferent primitive goal relationships.

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)


33/73


AgendaAgenda

Motivation

Goal Oriented Requirements Engineering Introduction to TROPOS


Mi t h d R i tMi t h d R i t D iD i


34/73


Operational environment in terms of stakeholders,qualities, responsibilities, objectives, and resources,

roles, needs... Versus information systems as a collection of

(software) modules, data structures and interfaces.

Impedance Mismatch

Poor quality, Failure Why not requirements-driven to avoid that mismatch?

Organizational concepts not only for Early Requirements

but the Entire Development Life Cycle

TROPOS

Mismatch and RequirementsMismatch and Requirements--DrivenDriven

DevelopmentDevelopment


35/73


Tropos Project (Tropos Project (launchedlaunched ininAprilApril 2000)2000)

Participating teams includes: Recife (Brasil): J aelson Castro, Fernanda Alencar,

Carla Silva, Rosa Candida, Marcia Lucena, RicardoRamos, etc,

Toronto (Canada): J ohn Mylopoulos, Eric Yu, AlexeiLapouchnian, Sotirios Liaskos, Yijun Yu, YiqiaoWang, etc

Trento (Italy): Anna Perini, Angelo Susi, LorisPenserini, P. Bresciani, P. Giorgini, P. Traverso etc,

Elsewhere: Manuel Kolp (Belgium), Matthias J arke

(Germany), Lin Liu (China), etc

httphttp://://www.troposproject.orgwww.troposproject.org


36/73


Software Agent

Implemented with/in software technologies

Environment : humans, machines, other

softwareagents, platforms.

MultiMulti--agent systemagent system : organization of: organization ofindividuals to achieve particular,individuals to achieve particular,

possible common goals.possible common goals.

AOSEAOSE

Agent :: Individual who can act Autonomous, pro- active, adaptative with/in its

environment


37/73


The Tropos Methodology

Proposes a setof primitive concepts adopted fromi*(actor, goal, actor dependency,) and a process forbuilding agent oriented 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 systemactors are added and

are assigned responsibilities;

Detailed design complete the specification of system

actors. Implementation -- system implementation carried out

consistently with detailed design


38/73


TroposTropos

Late Requirements

Architectural Design

Detailed Design

Implementation

Early Requirements


39/73


Where Do We Want to Go?Where Do We Want to Go?

Early

Ea

rly

requir

ements

requir

ements La

teLa

te

re

quire

ments

requir

ements

Archite

ctural

Archite

ctural

desig

n

desig

nDe

tailed

Detai

led

desig

n

desig

n

Imple

menta

tion

Imple

menta

tion

KAOSKAOS

UML, Catalysis & Co.UML, Catalysis & Co.

AUMLAUML

TROPOSTROPOS

GAIAGAIA

!! The GAP !!!! The GAP !!

i*i*

AgentAgent--orientedoriented

programmingprogramming


40/73


An exampleAn example

Media taxonomy on-line catalog DBMS

E-Shopping Cart Check In Buying Check Out

Search Engine catalog browser Keywords full-text

Secure $ transactions orders

Multimedia description samples

Securit

y,A

vaila

bility,

Adaptabili

ty,

Securit

y,A

vaila

bility,

Adaptabili

ty,


41/73


1. Early Requirements Analysis with1. Early Requirements Analysis with

TROPOSTROPOS Understanding the problem by studying an existing organizational setting;

Output : Organizational modelOrganizational model with relevant actors and respective goals.

i* [Yu95]

MeansMeans--Ends Analysis & FunctionalEnds Analysis & Functional


42/73


AlternativesAlternatives

2 Late Requirements2 Late Requirements


43/73


2. Late Requirements2. Late Requirements

OrganizationalOrganizational

MapMap

Late RequirementsLate Requirements


44/73


Late RequirementsLate Requirements

Medi@

Rationale MapRationale Map

3 Architectural Design3 Architectural Design


45/73


3. Architectural Design3. Architectural Design

Global architecture in terms of interconnectedsubsystems.

3 Steps

Macro level : Organizational Styles (OrganizationTheory)

Vertical Integration, Pyramid, J oint Venture,

Structure in 5, Bidding, Hierarchical Contracting,Co-optation, Takeover

Micro level : Patterns (Agent Community)

Broker, Matchmaker, Contract-Net, Mediator,Monitor, Embassy, Wrapper, Master-Slave, ...

Assigning Actors to Agents, Positions, Roles

(O i ti l) A hit t l St l(O i ti l) A hit t l St l


46/73


(Organizational) Architectural Style(Organizational) Architectural Style

J oint VentureJ oint Venture

Organizational Architectures CatalogOrganizational Architectures Catalog


47/73


Correlation Catalog Predict. Secur. Adapt. Cooperat. Compet. Availab. Failabil. Modul. Aggreg.

Flat Structure BREAK BREAK MAKE HELP HELP MAKE HURT

Structure-in-5 HELP HELP HELP HURT HELP MAKE MAKE

Pyramid MAKE MAKE HELP MAKE BREAK HELP BREAK HURT

Join Venture HELP HELP MAKE HELP HURT MAKE HELP MAKE

Bidding BREAK BREAK MAKE HURT MAKE HURT BREAK MAKE

Takeover MAKE MAKE HURT MAKE BREAK HELP HELP HELP

Arms-Length HURT BREAK HELP HURT MAKE BREAK MAKE HELP

Hierarch. Cont. HELP HELP HELP HELP HELP HELP

Vert. Integ. HELP HELP HURT HELP HURT HELP BREAK BREAK BREAK

Co-optation HURT HURT MAKE MAKE HELP HURT HELP

Organizational Architectures CatalogOrganizational Architectures Catalog

Predictabil ity, Security, Adaptabil ity, Cooperativity,

Competit ivity, Availabil ity, Failabili ty, Modularity,

Aggregability,

Selecting System ArchitectureSelecting System Architecture


48/73


Selecting System ArchitectureSelecting System Architecture

[Chung00][Chung00]

A JointA Joint--Venture EVenture E--commercecommerce

A hit tA hit t


49/73


ArchitectureArchitecture

EE--BusinessBusinessOrganizationalOrganizational

MapMap

4 Detailed Design4 Detailed Design


50/73


4. Detailed Design4. Detailed Design

Workflow for the Detailed Design ProcessWorkflow for the Detailed Design Process


51/73


gg

5.5. ImplementationImplementation


52/73


Fromdetailed design to J ACK

Fromdetailed design to J ADE

See CAiSE 0& 6 an ASE 06

Partial JACK Implementation for checkingPartial JACK Implementation for checking


53/73


outout

ToolTool SupportSupport


54/73


Tool Supportpp

Tool for Agent Oriented Modeling (4 eclipse) - TAOM4e

AgendaAgenda


55/73


gg

Motivation



RequirementsRequirements ElicitationElicitation


56/73


qq

Where do the goals, tasks and resources come from?

Part of PhD thesis by Gensio Cruz Neto (Recife)

CRUZ NETO, Gensio , GOMES, Alex Sandro, CASTRO,

J aelsonMapping Activity Theory Diagrams into i* OrganizationalModels. J ournal of Computer Science and Technology. ,v.5, p.57 - 63, 2005.

DealingDealing withwith RequirementsRequirements ComplexityComplexity


57/73


gg qq p yp y

Combining different techiques (i*, Problem Frames, Viewpoints,etc)

Structuring and Visualization of complex requirements

May AOSD principles help?

Simplifying i* ModelsAOIS 07- 17th International Workshop on Agent-OrientedInformation Systems (in press)

Towards Aspectual Problem Frames

Expert Systems The J ournal of Knowledge Engineering, (inpress)

Fernanda Alencar (Recife)

Maria Lencastre (Recife)

RequirementsRequirements XX ArchitectureArchitecture


58/73


q

From requirements to multi-agent architecture usingorganisational concepts.

Dealing with non-functional requirements (concerns).

Aspectual Architecture? PhD thesis by Lucia Bastos (Recife)

PhD thesis by Marcia Lucena (Recife)

RequirementsRequirements QualityQuality


59/73


Evaluating the quality of requirements documents

PhD thesis by Ricardo Ramos (Recife)

RequirementsRequirements TraceabilityTraceability


60/73


Requirements Traceability in Agent Oriented SoftwareEngineering

PhD thesis by Rosa Candida (Recife)

Designing Social Patterns using AdvancedDesigning Social Patterns using Advanced

Separation of ConcernsSeparation of ConcernsWork


61/73


Separation of ConcernsSeparation of Concerns

Agency metamodel

MAS modeling notation

Detailed design process

Standard technique to describe social patterns more detailed description

promotes advanced separation of patterns concerns

guidelines to implement social patterns integration of J ADE and AspectJ

PhD thesis by Carla Taciana Silva (Recife)

Mo

tiva

tion

Proposa

l

Case

Study

Contr

ibu

tions

Contr

ibu

tions

Future

W

Social Analysis


62/73


Given a set of actors, each with associated rootgoals, and a goal graph for each root goal, find an

actor dependency network that fulfi lls all root goals

Well-Formed Dependency Networks


63/73


Some dependency graphs dont make sense...

What is a good dependency network, assuming that we

are interested in:

minimizing dependence;

distributing work;

network stability PhD thesis by Volha Bryl (Trento).

Designing for High Variability


64/73


Instead of choosing one solution for the fulfillmentof a top-level goal, we could choose to support

them all.

This leads to software solutions that can becustomized in many different ways, depending on

stakeholder preferences and environmental

parameters.

DesigningDesigning forforHighHigh VariabilityVariability :: applicationsapplications


65/73


Enterprise Resource Planning (ERP) software isgeneric and can be customized in (very) many

different ways.

But we don't have yet systematic ways of generating

such designs.

Business process design (Alexei Lapouchnian,

Toronto).

Home care software for the elderly (Sotiris Liaskos,Toronto).

SecuritySecurity


66/73


Extended version of Tropos to support concepts of

ownership, permission and trust;

this leads to models where you can check whether

every actor has the permissions it needs to carry outits obligations

PhD thesis by Nicola Zannone (Trento)

RiskRisk ManagementManagement


67/73


Extending the a risk management framework[Feather05] to allow hierarchical goal/requirement

and risk decompositions

PhD thesis by Yudis Asnar (Trento)

NormsNorms


68/73


Engineering Normative Requirements

PhD thesis by Albertro Siena Asnar (Trento)

AgendaAgenda


69/73


Motivation



ConclusionsConclusions


70/73


GORE introduces new concepts in softwaredevelopment processes

We have argued that GORE shows a path towards

defining and analzing design spaces for software We also sketched an application of GORE Concepts

Designing agent-oriented software

The Tropos project J information Systems 02 &J AAMAS04

The Final PictureThe Final Picture


71/73


Software Engineering in 2025 =Software Engineering in 2025 =

Requirements EngineeringRequirements Engineering +SoftwareSoftware GeriatryGeriatry + ?+ ?

[van Lamsweerde 00]

Enterprise Information Systems should reflect theEnterprise Information Systems should reflect theorganizational environmentorganizational environment

Modeled and Driven in terms oforganizationorganizationconcepts and models to avoid mismatch andconsidercorporate assetscorporate assets

TROPOSTROPOS

Engineered within an organizationalorganizational paradigm

AgentsAgents

TheThe FinalFinal FinalFinal PicturePicture


72/73


Muchas Gracias!!!Muchas Gracias!!!


73/73


Muito Obrigado!!! Thanks a lot!!!

Grazie Mille!!!

J aelson Castro

[email protected]

www.cin.ufpe.br/~jbc

www.troposproject.org

www.cin.ufpe.br/~ler

Documents

Goal-Oriented Requirements Engineering