1999 john mylopoulos requirements-driven is engineering -- 1 requirements-driven information system...

1999 John Mylopoulos Requirements-Driven IS Engineering -- 1

Requirements-DrivenRequirements-DrivenInformation System EngineeringInformation System Engineering

John MylopoulosJohn MylopoulosUniversity of TorontoUniversity of Toronto

Workshop on Agent-Based Information SystemsWorkshop on Agent-Based Information SystemsConference on Advanced Information Systems Engineering (CAiSE’99)Conference on Advanced Information Systems Engineering (CAiSE’99)

Heidelberg, June 14-15 1999Heidelberg, June 14-15 1999


AbstractAbstractInformation Systems Engineering has traditionally been implementation-driven

in the sense that the programming paradigm of the day (structured programming, object-oriented programming) dictated the design and requirements analysis techniques widely used (structured analysis and design, object-oriented analysis and design).

We speculate on what an information systems engineering methodology might look like if it was founded on early requirements analysis techniques. For our purposes, we adopt i* as modeling framework. i* supports concepts such as those of actor, agent, position and role, also resource, task and goal dependencies among actors. The presentation suggests elements of late requirements analysis, architectural and detailed design through examples, and notes a number of areas where such a methodology might break new ground with respect to traditional information systems engineering, as well as agent-oriented programming.


Information System EngineeringInformation System Engineering Information System (hereafter IS) Engineering 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 the

design and requirements paradigms. So, structured programming led to structured design and

(requirements) analysis, while object-oriented programming led to object-oriented design and analysis.

Aligning the paradigms used for requirements, design and implementation makes perfect sense. But why start with implementation?

What would What would requirementsrequirements-driven-driven

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


Why Requirements-Driven?Why Requirements-Driven? Requirements analysis is arguably the most important phase of

information system development; that’s where the most and the costliest errors are introduced in software systems.

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

Requirements analysis is the phase where technology meets the real world, where technical considerations have to be balanced against personal, organizational and social ones; this calls for special skills on the part of the requirements engineer, and makes the phase particularly challenging.


Requirements AnalysisRequirements Analysis

“...Requirements EngineeringRequirements Engineering is the branch of systems engineering concerned with real-world goals for, services provided by, and constraints on software systems. Requirements Engineering is also concerned with the relationship of these factors to precise specifications of system behaviour and to their evolution over time and across system families...” [Zave94]

This activity traditionally boils down to three tasks:• Context analysis Context analysis -- the reasons whywhy the system is to be created

and why certain technical operational and economic feasibilities are the criteria that form boundary conditions for the system

• Functional requirements Functional requirements -- whatwhat will the system is to do• Non-functional (quality) requirements Non-functional (quality) requirements -- global constraints on

howhow the system is to be constructed and function


Early vs Late RequirementsEarly vs Late Requirements

We need to distinguish between early phases of requirements analysis, when the analyst is trying to understand an organizational setting, from late phases when the analyst formulates a solution

OrganizationOrganization

SystemSystem

Organizational model

Contractual requirements

RequirementsRequirements


Early vs Late RequirementsEarly vs Late Requirements Early requirements amount to the definition of a search space

(“scoping”) and a search among alternatives within that space. Late requirements amount to refining, disambiguating and

completing the description of the chosen alternative. StructuredStructured and object-oriented analysesobject-oriented analyses are OK for late

requirements. Goal-oriented analysisGoal-oriented analysis is more appropriate for early requirements

analysis because it focuses on the definition and exploration of a space of alternatives


Goal-Oriented AnalysisGoal-Oriented Analysis Goal-oriented analysis focuses on early requirements phases, when

alternatives are being explored and evaluated. During goal-oriented analysis, we start with initial goals such 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 of design decisions each of which can satisfy the initial goals.

Initial goals may be organization- or system-oriented; they may also be contradictory, so the analysis must facilitate the discovery of tradeoffs and the search of the full space of alternatives, rather than a subset.


Goal-Oriented Analysis is not New!Goal-Oriented Analysis is not New! Specification of composite systems -- [Feather87] Goal-oriented elaboration of requirements -- ALBERT [Dubois94] Goal-oriented requirements acquisition -- KAOS [Dardenne93] Knowledge representation and reasoning in the design of

composite systems -- Critter [Fickas92] Goal-oriented requirements analysis -- Potts, Anton I* and Non-Functional Requirements framework -- Yu, Chung NATURE -- [Jarke93] F3 -- [Bubenko93]

...and many others...


The i* FrameworkThe i* Framework

Customer InsuranceCompany

Carrepaired

Customerhappy

Settleclaim

Maximizeprofits

Goals are relative, fulfillment is collaborativeGoals are relative, fulfillment is collaborative


Means-Ends AnalysisMeans-Ends Analysis

Settleclaim

Verifypolicy

ClaimsClaimsHandlingHandlingClaimsClaims

HandlingHandling

Handleclaim

Settlementcost?

Prepareoffer

Whosefault?

Get accidentinfo

Determinefault

Police

Witness

DoctorAppraiser

Determinecost to settle

Accidentinfo

Sufficienttreatment Injury

infoAppraisedamage

Minimalrepairs

DDD D

D

ActorActorboundaryboundary


Strategic Dependency ModelsStrategic Dependency Models

BodyShop

Owner

Appraiser

InsuranceCompany

Carrepaired

Pay repairs

Maximizeestimate

Continuebusiness

D D

D DD D

DDD D

D

D

D

D

D

D

D

DClaimspayout

Premiumpayment

D DCustomerhappy

Repairscovered

D

D

Appraisedamages Minimize

repairs

Secureemployment

Fair repairappraisal

GoalGoal

TaskTask

ResourceResource

SoftgoalSoftgoal


Where Are We??Where Are We??

Early

Early

requirements

requirements Late

Late

requirements

requirements

Architectural

Architectural

design

design Detaile

d

Detailed

design

design

Implementatio

n

Implementatio

n

i*i*

KAOSKAOS

ZZ

UMLUML

Agent-oriented Agent-oriented programmingprogramming


Where Do We Want To Be??Where Do We Want To Be??

Early

Early

requirements

requirements Late

Late

requirements

requirements

Architectural

Architectural

design

design Detaile

d

Detailed

design

design

Implementatio

n

Implementatio

n

i*i*Agent-oriented Agent-oriented programmingprogramming

Guiding Principle: Push concepts as far down as Guiding Principle: Push concepts as far down as possible (…and see what happens!)possible (…and see what happens!)


Late Requirements with i*Late Requirements with i* The system is now represented as one or more actors which

participate in a strategic dependency model. Resource, task and softgoal dependencies correspond naturally to

functional and non-functional requirements. Leaving (some) goal dependencies between software system actors

and other actors is a novelty. Traditionally, functional goals are “operationalized” during late requirements, and quality softgoals are either operationalized or “metricized”.

Leaving goal dependencies with system actors as dependees makes sense whenever there is a foreseeable need for flexibility in the performance of a task on the part of the system.


Insurancecompany

Trackingactor

Claimsmanager

Reportingactor

System

DD

D

Information

DInformation

The System as a Cluster of ActorsThe System as a Cluster of ActorsTroubleshooting

done DD


Goals Mean FlexibilityGoals Mean Flexibility Consider a goal laid out during early requirements “communicate(x,y)”. Conventionally, such goals are “operationalized” during late

requirements into “constraints” for the system-to-be, such as having a user interface, also supporting a dialogue during which information x is communicated to person y.

Such “operationalizations” lead to fragile systems; …what if y doesn’t engage in dialogue with the system?… y doesn’t understand the message?… the system crashes during the dialogue?… etc.

Leaving the communication goal as part of the late requirements spec, or even the design means that the system-to-be will be designed with several alternative strategies for satisfying the goal, including getting help from outside

Reportingactor

D D

Customer

Communicate(x)


Now we focus on actors that are part of the system. Add actors, in addition to those inherited from requirements to meet

the obligations of existing (system) actors. Decide whether actors will be agents, positions, or roles.

• Actor <-> agent if the fulfillment of its obligations requires unique skills (e.g., troubleshooting).

• Actor <-> position if there are generic agents which have suitable skills; for example, information management might use a DBMS agent, tracking might employ (…) a workflow agent.

• Actor <-> role if another actor (agent, position) within the system has the skills to meet assigned obligation; for example, a DBMS agent holding an information management position can play the role of information provider for a particular project

Architectural Design with i*Architectural Design with i*


Architectural Design with i*Architectural Design with i*

Trackingactor

Claimsmanager

Reportingactor

D

D

D

Information

DInformation

Interfacemanager

D

Clerk

D

D

TransformerDInformationD

DInformation’

D


Participant

Initiator

ContributeToMtg

AttendMtg

UsefulMtg

Scheduler

CalendarInfo

ScheduledMtg

SuitableTime

Sally

MichaelDeptChair

assignedToassignedTo

assignedTo

role

position

agentActor AssignmentsActor Assignments


Detailed DesignDetailed Design The skills of all actors and their input/output data are refined using

some specification technique. Agent infrastructure is defined, including communication and

collaboration protocols. Infrastructure actors are introduced, such as

• Hiring actors, i.e., ones for filling positions; • Headhunters, i.e., actors who look for agents to fill positions at

run time;• Dependency managers who supervise dependencies and

determine whether they remain viable.


Implementation with i*Implementation with i* Agents are implemented. Implement positions and roles, given assigned agents. If there are dangling goal dependencies, build into the responsible

agent skills for meeting these goals.

E.g., a communication goal might be met through repeated email, asking a third party to communicate etc.

If there are dangling softgoal dependencies, build into the responsible agent skills for addressing such softgoals.

E.g., a security agent would have a number of ways of meeting security goals


Forms of AnalysisForms of Analysis Each IS development paradigm encourages different types of

analysis. Structured techniques focused on information transformations, OO ones on types of information and the behaviours of each type.

Actor-oriented techniques encourage answers to the following questions:• Who are the relevant actors and what are their goals?• Who can satisfy/satisfice a goal/softgoal?• How do we establish an obligation for an actor to deliver on a

dependence?• Does this process have the right effects?• …more...


RemarksRemarks There are three mechanisms that are interesting here from a

Information Systems perspective:• Goals stay around until after early requirements and as long as

run-time;• Position and role filling may take place somewhere between

architectural design and run-time;• Dependencies may be created during requirements analysis

and design time, or at run-time, and they need to be managed. None of these is novel to agent programming; what is novel from

that perspective is the idea that these mechanisms may be exploited during early phases of software development to offer a whole new dimension to agent-based system design.


ConclusionsConclusions From an Information Systems perspective, this proposal, however

speculative, has advantages:• Leads to more flexible, robust and open architectures;• Offers a coherent framework which encompasses all phases of

software development, from early requirements to implementation

• Is consistent with the next generation programming paradigm. As well, from an Agent-Based Systems perspective the proposal

• Suggests a comprehensive methodology for building software;• Offers a new dimension along which one decides

flexibility+robustness vs performance tradeoffs.

……BUT,…all this is just a proposal, which needs to be BUT,…all this is just a proposal, which needs to be validated and elaborated by research.validated and elaborated by research.


So…So…

Agent-Oriented Information Agent-Oriented Information Systems Systems

is the solution tois the solution to

Requirements-Driven Requirements-Driven

Information Systems EngineeringInformation Systems Engineering


ReferencesReferences [Yu94] Yu, E., Modelling Strategic Relationships for Process Reengineering, PhD thesis,

Department of Computer Science, University of Toronto, December 1994.

1999 john mylopoulos requirements-driven is engineering -- 1 requirements-driven information system...

Documents