Towards Modelling and Reasoning Support forEarly-Phase Requirements Engineering

Eric S.K. YuFacultyof InformationStudies,Universityof Toronto

Toronto,Ontario,CanadaM5S3G6����������� �����������������������

Abstract

Requirements are usually understood as stating whata system is supposed to do, as opposed to how it shoulddo it. However, understanding the organizational con-text and rationales (the “Whys”) that lead up to systemsrequirements can be just as important for the ongoing suc-cess of the system. Requirements modelling techniquescan be used to help deal with the knowledge and reason-ing needed in this earlier phase of requirements engineer-ing. However, most existing requirements techniques areintended more for the later phase of requirements engi-neering, which focuses on completeness, consistency, andautomated verification of requirements. In contrast, theearly phase aims to model and analyze stakeholder inter-ests and how they might be addressed, or compromised, byvarious system-and-environment alternatives. This paperargues, therefore, that a different kind of modelling andreasoning support is needed for the early phase. An out-line of the

���framework is given as an example of a step

in this direction. Meeting scheduling is used as a domainexample.

1 IntroductionRequirementsengineering(RE) is receiving increasing

attentionas it is generallyacknowledgedthat the earlystagesof the systemdevelopmentlife cycle are crucialto thesuccessfuldevelopmentandsubsequentdeploymentandongoingevolutionof thesystem.Ascomputersystemsplay increasinglyimportantrolesin organizations,it seemsthereis a needto paymoreattentionto theearlystagesofrequirementsengineeringitself (e.g.,[6]).

Much of requirementsengineeringresearchhastakenasstartingpoint theinitial requirementsstatements,whichexpresscustomer’s wishesaboutwhat the systemshoulddo. Initial requirementsareoftenambiguous,incomplete,inconsistent,andusuallyexpressedinformally. Many re-quirementslanguagesandframeworkshavebeenproposedfor helpingmakerequirementsprecise,complete,andcon-sistent(e.g., [4] [19] [13] [15]). Modelling techniques(from boxes-and-arrows diagramsto logical formalisms)with varying degreesof analyticalsupportareoffered toassistrequirementsengineersin thesetasks. The objec-tive, in these“late-phase”requirementsengineeringtasks,is to producea requirementsdocumentto passon (“down-stream”) to the developers,so that the resultingsystem

would beadequatelyspecifiedandconstrained,often in acontractualsetting.

Considerablylessattentionhasbeengiven to support-ing theactivities thatprecede theformulationof theinitialrequirements.These“early-phase”requirementsengineer-ing activities includethosethatconsiderhow theintendedsystemwouldmeetorganizationalgoals,why thesystemisneeded,whatalternativesmightexist,whattheimplicationsof thealternativesarefor variousstakeholders,andhow thestakeholders’interestsand concernsmight be addressed.Theemphasishereis onunderstandingthe“whys” thatun-derliesystemrequirements[37], ratherthanon thepreciseanddetailedspecificationof “what” thesystemshoulddo.

This earlierphaseof the requirementsprocesscan bejust as importantas that of refining initial requirementsto a requirementsspecification,at leastfor the followingreasons:

� Systemdevelopmentinvolvesa greatmany assump-tionsaboutthe embeddingenvironmentandtaskdo-main. As discoveredin empiricalstudies(e.g.,[11]),poorunderstandingof thedomainis a primarycauseof projectfailure. To haveadeepunderstandingabouta domain,oneneedsto understandthe interestsandprioritiesandabilitiesof variousactorsandplayers,inadditiontohavingagoodgraspof thedomainconceptsandfacts.

� Usersneedhelp in coming up with initial require-mentsin thefirst place.As technicalsystemsincreasein diversityandcomplexity, the numberof technicalalternatives and organizationalconfigurationsmadepossibleby themconstitutea vastspaceof options.A systematicframework is neededto helpdevelopersunderstandwhatuserswantandto helpusersunder-standwhat technicalsystemscando. Many systemsthataretechnicallysoundhave failed to addressrealneeds(e.g.,[21]).

� Systemspersonnelareincreasinglyexpectedto con-tribute to businessprocessredesign. Insteadof au-tomatingwell-establishedbusinessprocesses,systemsarenow viewedas“enablers”for innovativebusinesssolutions(e.g.,[22]). More thanever before,require-mentsengineersneedto relatesystemstobusinessandorganizationalobjectives.

� Dealing with changeis one of the major problemsfacing softwareengineeringtoday. Having a repre-sentationof organizationalissuesand rationalesinrequirementsmodelswould allow softwarechangesto be tracedall the way to the originatingsource–theorganizationalchangesthat leadsto requirementschanges[18].

� Having well-organizedbodiesof organizationalandstrategic knowledgewould allow suchknowledgetobesharedacrossdomainsatthishighlevel, deepeningunderstandingabout relationshipsamong domains.This would also facilitate the sharingand reuseofsoftware(andothertypesof knowledge)acrossthesedomains.

� As moreandmoresystemsin organizationsintercon-nectandinteroperate,it is increasinglyimportanttounderstandhow systemscooperate(with eachotherand with humanagents)to contribute to organiza-tional goals. Early phaserequirementsmodelsthatdealwith organizationalgoalsandstakeholderinter-estscut acrossmultiple systemsand can provide aview of thecooperationamongsystemswithin anor-ganizationalcontext.

Support for early-phase RE. Early-phaseRE activitieshave traditionallybeendoneinformally, andwithoutmuchtool support. As the complexity of the problemdomainincreases,it is evident that tool supportwill be neededto leveragethe efforts of the requirementsengineer. Aconsiderablebodyof knowledgewould bebuilt up duringearly-phaseRE. This knowledgewould be usedto sup-portingreasoningaboutorganizationalobjectives,system-and-environmentalternatives, implicationsfor stakehold-ers,etc. It is importantto retainandmaintainthis bodyofknowledgein orderto guidesystemdevelopment,andtodealwith changethroughoutthesystem’s life time.

A numberof frameworkshave beenproposedto repre-sentknowledgeandto supportreasoningin requirementsengineering(e.g.,[19] [13] [27] [17] [12] [5] [35]). How-ever, theseframeworkshave not distinguishedearly-phasefrom late-phaseRE.Thequestionthenis: Are theremod-elling andreasoningsupportneedsthatareespeciallyrel-evant to early-phaseRE?If therearespecificneeds,canthesebemetby adaptingexisting frameworks?

Mostexisting requirementstechniquesandframeworksareintendedmorefor thelaterphaseof requirementsengi-neering,which focuseson completeness,consistency, andautomatedverification of requirements. In contrast,theearly phaseaimsto modelandanalyzestakeholderinter-estsandhow they mightbeaddressed,or compromised,byvarioussystem-and-environmentalternatives.In thispaperit is arguedthat,becauseearly-phaseREactivitieshaveob-jectivesandpresuppositionsthataredifferentfromthoseofthelatephase,it wouldbeappropriateto providedifferentmodellingandreasoningsupportfor thetwo phases.Nev-ertheless,a numberof recentlydevelopedRE techniques,suchasagent-andgoal-orientedtechniques(e.g.,[16] [14][17] [12] [7]) arerelevant,andmaybe adaptedfor early-phaseRE.

Therecentlyproposed� �

framework [39] is usedin thispaperasanexampleto illustratethekindsof modellingfea-turesandreasoningcapabilitiesthat might beappropriatefor early-phaserequirementsengineering.It introducesanontologyandreasoningsupportfeaturesthat aresubstan-tially differentfrom thoseintendedfor late-phaseRE(e.g.,asdevelopedin [15]).

Section2reviewsthe���

frameworkandoutlinessomeofits features,usingmeetingschedulingasadomainexample.Section3discusses,in light of theexperienceof developing� �

, themodellingandsupportrequirementsfor early-phaserequirementsengineering.Section4 reviewsrelatedwork.Section5 drawssomeconclusionsfromthediscussionsandidentifiesfuturework.

2 The i* modelling framework for early-phase requirements engineering

The���

framework � wasdevelopedfor modellingandreasoningaboutorganizationalenvironmentsandtheir in-formationsystems[39]. It consistsof two mainmodellingcomponents.TheStrategicDependency (SD)modelisusedtodescribethedependency relationshipsamongvariousac-tors in anorganizationalcontext. TheStrategic Rationale(SR) model is usedto describestakeholderinterestsandconcerns,and how they might be addressedby variousconfigurationsof systemsandenvironments. The frame-work builds on a knowledgerepresentationapproachtoinformationsystemdevelopment[27]. This sectionoffersanoverview of someof thefeaturesof

���, usingprimarily

a graphicalrepresentation.A moreformal presentationoftheframework appearsin [39]. The

� �framework hasalso

beenappliedto businessprocessmodellingandredesign[41] andto softwareprocessmodelling[38].

The centralconceptin���

is that of the intentionalac-tor [36]. Organizationalactorsareviewed as having in-tentionalpropertiessuch as goals, beliefs, abilities, andcommitments.Actors dependon eachother for goalstobe achieved, tasksto be performed,and resourcesto befurnished. By dependingon others,an actormay beableto achieve goalsthataredifficult or impossibleto achieveon its own. On the otherhand,anactorbecomesvulner-ableif the depended-onactorsdo not deliver. Actors arestrategic in thesensethatthey areconcernedaboutopportu-nitiesandvulnerabilities,andseekrearrangementsof theirenvironmentsthatwouldbetterserve their interests.�2.1 Modelling the embedding of systems in orga-

nizational environments – the Strategic De-pendency model

Considera computer-basedmeetingschedulerfor sup-porting the setting up of meetings� . The requirementsmight state that for eachmeeting request,the meeting�Thenamei* refersto the notion of distributedintentionalitywhich

underliestheframework.�An earlyversionof theframeworkwaspresentedin [36]. The exampleusedin this paperis a simplified versionof the one

providedin [34].

schedulershouldtry to determinea meetingdateandloca-tion so that mostof the intendedparticipantswill partici-pateeffectively. Thesystemwouldfind datesandlocationsthat areasconvenientaspossible. The meetinginitiatorwould askall potentialparticipantsfor informationabouttheiravailability to meetduringadaterange,basedontheirpersonalagendas.This includesan exclusionset– dateson which a participantcannotattendthe meeting,and apreferenceset– datespreferredby the participantfor themeeting.Themeetingschedulercomesupwith aproposeddate.Thedatemustnot beoneof theexclusiondates,andshouldideally belongto as many preferencesetsaspos-sible. Participantswould agreeto a meetingdateonceanacceptabledatehasbeenfound.

Many requirementsengineeringframeworks andtech-niqueshave beendevelopedto help refinethis kind of re-quirementsstatementsto achieve betterprecision,com-pleteness,andconsistency. However, to develop systemsthatwill truly meettherealneedsof anorganization,oneoften needsto have a deeperunderstandingof how thesystemis embeddedin theorganizationalenvironment.

Forexample,therequirementsengineer,beforeproceed-ing to refinethe initial requirements,might do well to in-quire:

� Why is it necessaryto schedulemeetingsaheadoftime?

� Whydoesthemeetinginiti atorneedtoaskparticipantsfor exclusiondatesandpreferreddates?

� Why is a computer-basedmeetingschedulerdesired?And whoseinterestsdoesit serve?

� Is confirmationvia thecomputer-basedschedulersuf-ficient? If not,why not?

� Are importantparticipantstreateddifferently? If so,why?

Most requirementsmodelsareill-equippedto helpan-swer suchquestions. They tend to focus on the “what”rather than the “why”. Having answersto these“why”questionsareimportantnotonly to helpdevelopsuccessfulsystemsin the first instance,but alsoto facilitate the de-velopmentof cooperationwith othersystems(e.g.,projectmanagementsystemsandotherteamcoordination“group-ware” for whichmeetinginformationmayberelevant),aswell astheongoingevolution of thesesystems.

Toprovideadeeperlevelof understandingabouthow theproposedmeetingschedulermight beembeddedin theor-ganizationalenvironment,theStrategicDependency modelfocuseson the intentional relationshipsamongorganiza-tional actors.By notingthedependenciesthatactorshaveon oneanother, onecanobtaina betterunderstandingofthe“whys”.

Considerfirst theorganizationalconfigurationbeforetheproposedsystemis introduced(Figure1). Themeetingini-tiator depends onmeetingparticipants! to attendmeeting" . If someparticipantdoesnot attendthe meeting,themeetinginitiator mayfail to achieve somegoal(not made

D

MeetingInitiator

ExclusionDates(p)

PreferredDates(p)

ProposedDate(m)

Agreement(m,p)

AttendsMeeting(ip,m)

Assured(AttendsMeeting(ip,m))

AttendsMeeting(p,m)

ImportantParticipant

XISA#

D

D

D

D$D

D%

D&

D

D'

DD(D

D

MeetingParticipant

D

D

D

D

D

D

D

D

Depender Dependee

LEGEND

O X)

Open (uncommitted) Critical

Resource Dependency

Task Dependency

Goal Dependency

Softgoal Dependency

Figure 1: Strategic Dependency model for meetingscheduling,without computer-basedscheduler

explicit in the SD model), or at leastnot succeedto thedegreedesired.This is thereasonfor wantingto schedulethemeetingin advance.To schedulemeetings,theinitiatordependsonparticipantsto provide informationabouttheiravailability – in termsof a setof exclusiondatesandpre-ferreddates.(For simplicity, wedonotseparatelyconsidertimeof dayor location.)To arriveatanagreeabledate,par-ticipantsdependon the initiator for dateproposals.Onceproposed,the initiator dependson participantsto indicatewhetherthey agreewith the date. For importantpartici-pants,themeetinginitiatordependscritically (markedwithan“X” in thegraphicalnotation)on their attendance,andthusalsoon theirassurancethatthey will attend.

Dependency typesareusedto differentiateamongthekindsof relationshipsbetweendependeranddependee,in-volving different typesof freedomand constraint. Themeetinginitiator’sdependency onparticipant’sattendanceat themeeting( *,+,+�-/. 021�3�-,-�+�4�.,5768!:9 "<; ) is a goal depen-dency. It is upto theparticipanthow to attainthatgoal.Anagreementon a proposeddate *,5,=>-,- " -/. +76 " 9?! ; is mod-elled asa resource dependency. This meansthat the par-ticipant is expectedonly to give anagreement.If thereisnoagreement,it is theinitiator whohasto find otherdates(do problemsolving). For an importantparticipant,theinitiator critically dependson that participant’s presence.The initiator wants the latter’s attendanceto be assured( *21 1�@,=�-/0BA�*,+,+�-�.,021�3 -,-/+�4�.,5768!:9 "<;�C ). This is modelledasasoftgoal dependency. It is upto thedependerto decidewhatmeasuresareenoughfor himtobeassured,e.g.,atele-phoneconfirmation.Thesetypesof relationshipscannotbeexpressedor distinguishedin non-intentionalmodelsthatareusedin mostexisting requirementsmodellingframe-works.

Figure2 shows an SD modelof the meetingschedul-ing settingwith a computer-basedmeetingscheduler. Themeetinginitiator delegatesmuchof the work of meetingschedulingto the meeting scheduler. The initiator nolongerneedsto bebotheredwith collectingavailability in-formationfrom participants,or to obtainagreementsaboutproposeddatesfrom them. The meetingscheduleralsodetermineswhataretheacceptabledates,giventheavail-

DD

MeetingInitiator Proposed

Date(m)Agreement(m,p)

AttendsMeeting(ip,m)

Assured(AttendsMeeting(ip,m))

AttendsMeeting(p,m)

MeetingBeScheduled(m)

MeetingScheduler

ImportantParticipant

X

ISAE

D

D

DD

D

D

DF

D

DD

DDG

DHDI

D

EnterDateRange (m)

EnterAvailDates (m) Meeting

Participant

D

D

D

D

D

D

D

D

Depender Dependee

LEGEND

O J

XOpen (uncommitted) Critical

Resource Dependency

Task Dependency

Goal Dependency

Softgoal Dependency

Figure 2: Strategic Dependency model for meetingschedulingwith computer-basedscheduler

ability information. The meetinginitiator doesnot carehow the schedulerdoesthis, as longeras the acceptabledatesarefound. Thisis reflectedin thegoal dependency of3�-,-/+K4�.,5,L�- MON�P�-/0 @�Q,-�0 from theinitiator to thescheduler.Theschedulerexpectsthemeetinginitiator toenterthedaterangeby following a specificprocedure.This is modelledvia a task dependency.

Note that it is still the meetinginitiator who dependson participantsto attendthe meeting. It is the meetinginitiator (not the meetingscheduler)who hasa stakeinhaving participantsattendthe meeting. Assurancefromimportantparticipantsthat they will attendthe meetingisthereforenot delegatedto the scheduler, but retainedasadependency frommeetinginitiator to importantparticipant.

TheSDmodelmodelsthemeetingschedulingprocessintermsof intentionalrelationshipsamongagents,insteadoftheflow of entitiesamongactivities. This allows analysisof opportunityandvulnerability. For example,theabilityof acomputer-basedmeetingschedulerto achieve thegoalof 3�-,-�+�4�.,5,L>-,MON�P�-�0,@�Q�-/0 representsanopportunityfor themeetinginitiator not to have to achieve this goalhimself.Ontheotherhand,themeetinginitiatorwouldbecomevul-nerableto thefailureof themeetingschedulerin achievingthisgoal.

2.2 Modelling stakeholder interests and ratio-nales – the Strategic Rationale model

TheStrategic Dependency modelprovidesonelevel ofabstractionfor describingorganizationalenvironmentsandtheir embeddedinformation systems. It shows external(but neverthelessintentional)relationshipsamongactors,while hiding the intentionalconstructswithin eachactor.As illustratedin theprecedingsection,the SD modelcanbeusefulin helpingunderstandorganizationalandsystemsconfigurationsasthey exist, or asproposednew configura-tions.

Duringearly-phaseRE,however, onewouldalsolike tohave moreexplicit representationandreasoningaboutac-tors’ interests,andhow theseinterestsmight beaddressed

or impactedby differentsystem-and-environmentconfigu-rations– existing or proposed.

In the���

framework, theStrategic Rationalemodelpro-videsa moredetailedlevel of modellingby looking “in-side”actorsto modelinternalintentionalrelationships.In-tentionalelements(goals,tasks,resources,andsoftgoals)appearin theSRmodelnotonly asexternaldependencies,butalsoasinternalelementslinkedbymeans-endsrelation-shipsandtask-decompositions(Figure3). TheSRmodelin Figure3 thuselaboratesontherelationshipsbetweenthemeetinginitiator andmeetingparticipantasdepictedin theSDmodelof Figure1.

For example,for themeetinginitiator, an internalgoalis that of 3>-,-/+�4�. 5,L�-,MON�P�-/0,@�Q�-/0 . This goal can be met(representedvia a means-endslink) by schedulingmeet-ings in a certainway, consistingof (representedvia task-decompositionlinks): obtainingavailability datesfrompar-ticipants,findinga suitabledate(andtime) slot,proposinga meetingdate,andobtainingagreementfrom thepartici-pants.

Theseelementsof the M�N�P�-/0,@>Q,-/3�-,-�+�4�.,5 taskarerep-resentedassubgoals,subtasks,or resourcesdependingonthetypeof freedomof choiceastohow to accomplishthem(analogousto theSD model). Thus RK4�.,0�M/@K4�+�S/T�Q -,M,Q,U/+ ,beinga subgoal,indicatesthat it canbe achieved in dif-ferentways. On theotherhand, V/T +�S24�.,* W�S24�QYXOS/+�-O1 andV/T,+�S�4�.,*,5,=>-,- " -/. + refer to specificwaysof accomplish-ing thesetasks. Similarly, 3>-,-/+�4�. 5,L�-,MON�P�-/0,@ Q,-/0 , beingrepresentedasa goal, indicatesthat the meetinginitiatorbelievesthat therecanbemorethanoneway to achieve it(to bediscussedin section2.4,Figure4).

3�-,-/+K4�.,5,L�- MON�P�-/0 @�Q/-�0 is itself an element of thehigher-level taskof organizinga meeting.Othersubgoalsunderthattaskmightincludeequipmentbeordered,or thatremindersbe sent(not shown). This taskhastwo addi-tionalelementswhichspecifythat theorganizingof meet-ings should be donequickly and not involve inordinateamountsof effort. Thesequalitative criteriaaremodelledassoftgoals. Thesewould be usedto evaluate(andalsoto help identify) alternative meansfor achieving ends. Inthis example,we notethat the existing way of schedulingmeetingsis viewedascontributingnegatively towardstheZ @�4/N\[ and ]�U�^,_,`,`�U�=,+ softgoals.

On the side of the meetingparticipants,they are ex-pectedto do their part in arrangingthe meeting,andthento attendthe meeting. For the participant,arrangingthemeetingconsistsprimarily of arriving atanagreeabledate.Thisrequiresthemto supplyavailability informationto themeetinginitiator, andthento agreeto theproposeddates.Participantswantselectedmeetingtimesto beconvenient,and want meetingarrangingactivities not to presenttoomany interruptions.

TheSRmodelthusprovidesa way of modellingstake-holderinterests,andhow they mightbemet,andthestake-holdersevaluationof variousalternativeswith respecttotheir interests.Task-decomposition links provide a hierar-chical descriptionof intentionalelementsthat makeup aroutine. The means-ends links in the SR providesunder-standingaboutwhy anactorwould engagein sometasks,

Agreeable(Meeting,Date)

AgreeTo Date

Convenient(Meeting,Date)

ProposedDate

Agreement

ObtainAgreement

ObtainAvailDates

MergeAvailDates

AttendMeeting

ParticipateInMeeting

ScheduleMeeting

MeetingInitiator

Quality(ProposedDate)

UserFriendly

ArrangeMeeting

MeetingParticipant

AttendsMeeting

DD

Da D

DDb

D Db

+

−

Quick MeetingBe Scheduled

OrganizeMeeting

−−

+

−

++

PreferredDates

ExclusionsDatesD Dc

MinInterruption

LowEffort

LowEffort

FindAgreeableDate

FindSuitable Slot

LEGEND

Goal

Task

Resource

Soft−Goal

Task−Decompo− sition linkMeans−ends link

Contribution to softgoalsActor

Actor Boundary

+−

Figure3: A Strategic Rationalemodelfor meetingscheduling,beforeconsideringcomputer-basedmeetingscheduler

pursueagoal,needaresource,orwantasoftgoal.Fromthesoftgoals,onecantell why onealternative maybechosenover others. For example,availability information in theform of exclusionsetsandpreferredsetsarecollectedsoasto minimizethenumberof roundsandthusto minimizeinterruptionto participants.

2.3 Supporting analysis during early-phase RE

While requirementsanalysistraditionallyaimsto iden-tify andeliminateincompleteness,inconsistencies,andam-biguities in requirementsspecifications,the emphasisinearly-phaseREis insteadonhelpingstakeholdersgainbet-ter understandingof thevariouspossibilitiesfor usingin-formationsystemsin their organization,andof the impli-cationsof differentalternatives. The

���modelsoffer a

numberof levelsof analysis,in termsof ability, workabil-ity, viability andbelievability. Thesearedetailedin [39]andbriefly outlinedhere.

When a meetinginitiator hasa routine to organizeameeting,we saythatheis able to organizea meeting.Anactorwho is ableto organizeonetype of meeting(say, aprojectgroupmeeting)is not necessarilyableto organizeanothertype of meeting(e.g.,the annualgeneralmeetingfor the corporation). One needsto know what subtask,subgoals,resourcesare required,and what softgoalsarepertinent.

Givena routine,onecananalyzeit for workability andviability. Organizingmeetingis workable if there is aworkableroutinefor doing so. To determineworkability,oneneedsto look at theworkability of eachelement– forexample,thatthemeetinginitiator canobtainingavailabil-ity informationfrom participants,canfind agreeabledates,andcanobtainagreementsfrom participants.If thework-

ability of an elementcannotbe judgedprimitively by theactor, thenit needsto be further reduced. If the subgoalR�4�.,0>M/@�4�+�S�T�Q,-,M,Q U/+ is not primitively workable, it willneedtobeelaboratedin termsof aparticularwayfor achiev-ing it. For example,onepossiblemeansfor achieving itis to doanintersectionof theavailability informationfromall participants.If this taskis judgedto beworkable,thenthe RK4�.,0�M/@K4�+�S/T�Q -,M,Q,U/+ goalnodewouldbeworkable.Ataskcanbeworkableby way of externaldependenciesonotheractors.Theworkability of V/T,+�S�4�.,*,W�S�4�QYX�S/+>-O1 andV/T,+�S�4�.,*,5,=>-,- " -/. + areevaluatedin termsof theworkabil-ity of thecommitment of meetingparticipantsto providesavailability informationandagreement.A moredetailedcharacterizationof theseconceptsaregivenin [39].

A routinethatis workableis notnecessarilyviable. Al-thoughcomputingintersectionof timeslotsby handis pos-sible,it is slow anderror-prone.Potentiallygoodslotsmaybemissed. Whensoftgoalsarenot satisficed,the routineis not viable. Notethata routinewhich is not viablefromoneactor’sperspective maybeviablefrom anotheractor’sperspective. For example,the existing way of arrangingfor meetingsmaybeviablefor participants,if theresultingmeetingdatesareconvenient,andthemeetingarrangementeffortsdonot involvetoomuchinterruptionof work.

Theassessmentof workability andviability is basedonmany beliefsandassumptions.Thesecanbeprovidedasjustificationsfor the assessment.The believability of therationalenetworkcanbeanalyzedby checkingthenetworkof justificationsfor thebeliefs.For example,theargumentthat “finding agreeabledatesby merging availabledates”is workablemay be justified with the assertionthat themeetinginitiator hasbeendoingit this way for years,andit works. The belief thatmeetingparticipantswill supplyavailability informationandagreeto meetingdatesmaybe

Agreeable(Meeting,Date)

AgreeTo Date

Convenient(Meeting,Date)

ProposedDate

Agreement

ObtainAgreement

ObtainAvailDates

FindAgreeable Slot

MergeAvailDates

Quick MeetingBe Scheduled

ScheduleMeeting

AttendMeeting

ParticipateInMeeting

LetScedulerScheduleMeeting

ScheduleMeeting

MeetingInitiator

MeetingSchedulerMeetingBe

Scheduled

FindAgreeableDateUsingScheduler

FindAgreeableDateByTalkingToInitiator

Quality(ProposedDate)

UserFriendly

ArrangeMeeting

RicherMedium

EnterAvailDates

OrganizeMeeting

MeetingParticipant

AttendsMeeting

EnterDateRange

D

Dd

D

D

DD

De D

DDf

D

Df

+ −− +

+

−

+

+− +

+

LEGEND

Goal

Task

Resource

Soft−Goal

Task−Decompo− sition linkMeans−ends link

Contribution to softgoalsActor

Actor Boundary

+−

LowEffort

LowEffort

Figure4: Strategic Rationalemodelfor a computer-supportedmeetingschedulingconfiguration

justifiedby thebelief that it is in their own intereststo doso (e.g., programmerswho want their codeto passa re-view). Theevaluationof thesegoalgraphs(or justificationnetworks)is supportedby graphpropagationalgorithmsfollowing a qualitativereasoningframework [8] [42].

2.4 Supporting design during early-phase RE

During early-phaseRE, the requirementsengineeras-sistsstakeholdersin identifying system-and-environmentconfigurationsthatmeettheir needs.This is a processofdesignon a higher level than the designof the technicalsystemperse. In analysis,alternativesareevaluatedwithrespectto goals. In design,goalscanbeusedto helpgen-eratepotentialsolutionssystematically.

In���

, theSRmodelallowsusto raise ability, workabil-ity, andviability asissues thatneedto beaddressed.Usingmeans-endsreasoning,theseissuescanbe addressed sys-tematically, resultingin new configurationsthatarethentobeevaluatedandcompared.Means-endsrulesthatencodeknowhow in thedomaincanbeusedto suggestpossibleal-ternatives.Issuesandstakeholdersthatarecross-impactedmay be discoveredduring this process,andcanbe raisedso that trade-offs can be made. Issuesare settled whenthey aredeemedto adequatelyaddressedby stakeholders.Oncesettled,one can then proceedfrom the descriptivemodel of the

���framework to a prescriptive model that

would serve astherequirementsspecificationfor systemsdevelopment.g Believability canalsoberaisedasanissue,sothatassumptionswouldbejustified.

In analyzing the SR model of Figure 3, it isfound that the meeting initiator is dissatisfiedwith thehOneapproachto this is describedin [40].

amount of effort neededto schedulea meeting, andhow quickly a meeting can be scheduled. Theseareraised as the issues

Z @�4/N�[iAj3�-,-/+�4\.,5�MON�P>-/0,@ Q24�.,5 C and]�U/^,_ `,`�U/=,+BA�3�-,-/+K4�.,5 MON�P�-�0,@�Q24\./5 C .

Sincethemeetinginiti ator’sexistingroutinefor schedul-ing meetingsis deemedunviable,onewould needto lookfor new routines.This is donebyraisingthemeetinginitia-tor’sability to schedulemeetingsasanissue. To addressthis issue,onecouldtry to comeupwith solutionswithoutspecialassistance,or onecouldlook up rules (in a knowl-edgebase)thatmaybeapplicable.Supposea rule is foundwhosepurpose is 3�-,-/+K4�.,5,L�- MON�P�-/0 @�Q,-�0 andwhosehowattributeis ]>-/+�MON�P>-/0,@�Q,-�=�MON�P�-�0,@�Q -/3,- -/+�4�.�5 .

k�l ��m�m k ��� n�����o���p ��q�� l ����o���pY��q�� l ��r��\�����s��tvu�wyx�� l �{z,u�|�}~�����~ ��m��

� m�� r��������?��t�����o���p ��q�� l ��qp ���

m�m�����n�����o���p ��q�� l ����o���p ��q�� l ��r������,�?��t��~�~ l ��������� l ���� k ����q

~ l ��������������}���m���~�~�����~������������ l ����������������������~ l ��������������m���p ��q�� l �����

� w��

This representsknowledgethat the initiator hasaboutsoftwareschedulersystems,their abilities, andtheir plat-formrequirements. Therulehelpsdiscoverthatthemeet-ing initiatorcandelegatethesubgoalof meetingschedulingto the (computer-based)meetingscheduler. This consti-tutesaroutinefor themeetinginitiator.

Using a meetingscheduler, however, requirespartici-

pantsto enteravailability information in a particularfor-mat. This is modelledasa task dependency onparticipants(anSD link). A routinethatprovidesfor this is soughtinthe participant. Again, rulesmaybeusedto assistin thissearch.

Whennew configurationsareproposed,they maybringin additionalissues. The new alternatives may have as-sociatedsoftgoals. The discovery of thesesoftgoalscanalsobeassistedwith means-endsrules. For example,us-ing computer-basedmeetingschedulingmay be discov-eredto benegative in termsof mediumrichnessanduser-friendliness.Thesein turn have implicationsfor theeffortinvolvedfor theparticipant,andthequalityof theproposeddates.Thesenewly raisedissuesalsoneedto beaddressed.Oncenew routineshave beenidentified,they areanalyzedfor workability andviability. Furtherroutinesaresearchedfor until workableandviableonesarefound.

3 The modelling and reasoning supportneeds of early-phase RE

In theprecedingsection,the���

framework wasoutlinedin orderto illustrate the kind of modellingandreasoningsupportthatwould beusefulduringtheearlyphaseof re-quirementsengineering.This sectionsummarizesanddis-cussesthesemodellingandsupportneedsin moregeneralterms,drawing from theexperienceof the

� �framework.

Knowledge representation and reasoning. Althoughthe example in the precedingsectionrelies primarily oninformal graphicalnotations,it is clearthata realistically-sizedapplicationdomainwould involve large numbersofconceptsandrelationships.A moreformalknowledgerep-resentationschemewouldbeneededto supportmodelling,analysis,anddesignactivities. Maintaininga knowledgebaseof the knowledgecollectedand usedduring early-phaseRE is alsocrucial in orderto reapbenefitsfor sup-portingongoingevolution (e.g.,[8]), andfor reuseacrossrelateddomains.

Many of theknowledge-basedtechniquesdevelopedforother phasesof softwareengineeringare also applicablehere. For example, knowledge structuringmechanismssuchasclassification,generalization,aggregation,andtime[20] areequallyrelevantin early-phaseasin late-phaseRE.On the otherhand,early-phaseRE hascertainneedsthatarequitedistinctfrom late-phaseRE.

Degree of formality. While representingknowledgefor-mally hastheadvantageof amenabilityto computer-basedtool support,the natureof the early-phasesuggeststhatformality shouldbeusedjudiciously. Theearly-phaseREprocessis likely to be a highly interactive one, with thestakeholdersas the sourceof information as well as thedecisionmaker. Therequirementsengineeractsprimarilyin a supportingrole. The degreeof formality for a sup-port framework thereforeneedsto reflectthis relationship.Useof knowledgerepresentationcanfacilitateknowledgemanagementandreasoning.However, oneshouldnot tryto over formalize, as one may compromisethe style ofreasoningneeded.

Oneapproachis to introduceweakerconstructs,suchassoftgoals,which requiresjudgementalinputsfrom timeto time in the reasoningprocess,but which canbe struc-turedandmanagednonethelesswithin the overall knowl-edgebase[7] [39]. The notion of softgoaldraws on theconceptof satisficing[33], which refersto finding solu-tionsthatare“goodenough”.

Incorporating intentionality. One of the key needsindealingwith thesubjectmatterin theearlyphaseseemstobetheincorporationof theconceptof theintentionalactorinto the ontology. Without intentionalconceptssuchasgoals,onecannoteasilydealwith the“why” dimensioninrequirements.

A numberof requirementsengineeringframeworkshaveintroduced goal-orientedand agent-orientedtechniques(e.g.,[16] [14] [17] [12] [7]). In adaptingthesetechniquesfor early-phaseRE, oneneedsto recognizethat the focusduringtheearlyphaseis onmodelling (i.e.,describing)theintentionality of the stakeholdersandplayersin the orga-nizationalenvironment. Whennew alternativesarebeingsought(the “design” componentin early phaseRE), it isthe intentionalityof the stakeholdersthat arebeingexer-cised. Therequirementsengineeris helpingstakeholdersfind solutionsto their problems.Thedecisionsrestswiththestakeholders.

In mostgoal-orientedframeworksin RE, theintention-ality is assumedto beunderthecontrolof therequirementsengineer. Therequirementsengineermanipulatesthegoals,andmakesdecisionsonappropriatesolutionsto thesegoals.This maybeappropriatefor late-phaseRE,but not for theearlyphase.

By the endof the early-phase,the stakeholderswouldhave madethe major decisionsthat affect their strategicinterests.Requirementsengineersanddeveloperscanthenbegiventheresponsibilityto fill in thedetailsandto realizethesystem.

Oneconsequenceof the early/latephasedistinction isthat intentionalityis harderto extractandincorporateintoa model in the early phasethanin the late phase.Stake-holderinterestsandconcernsaretypically not readilyac-cessible.The approachadoptedin

���is to introducethe

notionof intentionaldependenciesto providea level of ab-stractionthat hidesthe internal intentionalcontentsof anactor. TheStrategic Dependency modelprovidesa usefulcharacterizationof therelationshipsamongactorsthatis atanintentionallevel (asopposedtonon-intentionalactivitiesandflows), without requiringthe modellerto know muchabout the actors’ internal intentionaldispositions. Onlywhenoneneedsto reasonaboutalternative configurationswould oneneedto makeexplicit thegoalsandcriteria forsuchdeliberations(in theStrategic Rationalemodel).Evenhere,the model of internal intentionality is not assumedto be complete. The modeltypically containsonly thoseconcernsthat arevoicedby the stakeholdersin order forthemto achieve thechangesthey desire.

Multi-lateral intentional relationships. In modellingtheembeddingof asystemin organizationalenvironments,it is necessaryto describedependenciesthat the systemhason its environment(humanagentsandpossiblyother

systems),aswell asthe latter’s dependencieson the sys-tem. Whenthesystemdoesnot liveup to theexpectationsof agentsin its environment,thelattermayfail to achievecertaingoals.Thereversecanalsohappen.During early-phaseRE, one needsto reasonabout opportunities andvulnerabilitiesfrom both perspectives. Both the systemand its environmentareusually opento redesign,withinlimits. Whenopportunitiesor vulnerabilitiesarediscov-ered,further changescanbe introducedon eitherside totake advantageof them or to mitigate againstthem. Amodellingframework for theearly-phasethusneedsto beableto expressmulti-lateralintentionalrelationshipsandtosupportreasoningabouttheir consequences.

In most requirementsframeworks, the requirementsmodelsare interpretedprescriptively. They statewhat asystemis supposedtodo. This is appropriatefor late-phaseRE. Requirementsdocumentsare often usedin contrac-tualsettings– developersareobligedto designthesystemsin orderto meetthe specifications.Oncethe early-phasedecisionshave settled,a conversionfrom themulti-lateraldependency modelto aunilateralprescriptivemodelfor thelate-phasecanbemade.

Distributed intentionality. Another distinctive featureof the early-phasesubjectmatteris that the multiple ac-tors in the domainall have their own intentionality. Ac-torsexerciseintentionality(e.g.,they pursuegoals)in thecourseof their daily routines.Actorshave multiple,some-timesconflicting, sometimescomplementarygoals. Theintroductionof acomputersystemmaymakecertaingoalseasierto achieve and othersharderto achieve, thus per-turbing the network of strategic dependencies. Dif fer-ent system-and-environmentconfigurationscan thereforebe seenasdifferentwaysof re-distributing the patternofintentionality� . Theboundariesmayshift (theresponsibil-ity for achieving certaingoalsmaybedelegatedfrom someagentsto other agents,someof which may be computersystems),but the actorsremainintentional. The processof system-and-environmentredesigndoesnotsolve all theproblems(i.e.,doesnot(completely)reduceintentionalel-ements,suchasgoals,to non-intentionalelements,suchasactions).It merelyrearrangestheterrainin whichproblemsappearandneedto beaddressed.

In contrast,in late-phaseRE andin the restof systemdevelopment,one doesattemptto fully reducegoals toimplementableactions.

Means-ends reasoning. In order to modeland supportreasoningabout“why”, andto helpcomeup with alterna-tive solutions,someform of means-endsreasoningwouldappearnecessary. However, a relatively weakerform ofreasoningthan customarilyusedin goal-orientedframe-works is needed.This is becauseof the higherdegreeofincompletenessin earlyphaseRE.Theemphasisisonmod-elling stakeholders’rationales.Alternative solutionsmaybeput forth assuggestions,but it is thestakeholderswhodecide. The modellingmay proceedboth “upwards”and“downwards”(from meansto endsor vice versa).Thereisnodefinitive“top” (sincetheremayalwaysbesomehighergoal)nor “bottom” (sincethereis no attemptto purgein-�Hencethenamei*.

tentionality entirely). It is the stakeholders’decisionasto when the issueshave beenadequatelyexplored and asufficiently satisfactorysolutionfound.

Thetypeof reasoningsupportdesiredis thereforecloserto thosedevelopedin issue-basedinformationsystems,ar-gumentationframeworks,anddesignrationales(e.g.,[10][30] [26] [25]). The

���approachis an adaptationof a

framework developedfor dealingwith non-functionalre-quirements[7], whichdraws ontheseearlierframeworks.

Organizational actors. In modellingorganizationalen-vironments,a richer notion of actoris needed.

���differ-

entiatesactorsinto agents,roles, and positions[39]. Inlate-phaserequirementsengineering,wherethefocusis onspecifyingbehavioursratherthanintentionalrelationships,suchdistinctionsmay not be as significant. Viewpointshasbeenrecognizedasanimportanttopic in requirementsengineering(e.g., [29]). In the early phase,the needtotreatmultiple viewpointsinvolving complex relationshipsamongvarioustypesof actorsis evenmoreimportant.

4 Related work

In the requirementsmodellingarea,theneedto modelthe environmentis well recognized(e.g., [4] [19] [23] ).Organizationandenterprisemodelshave beendevelopedin the areasof organizationalcomputing(e.g., [1]) andenterpriseintegration (e.g., [9]). However, few of thesemodelshave consideredthe intentional,strategic aspectsof actors. Their focus has primarily beenon activitiesandentitiesratherthanongoalsandrationales(the“what”ratherthanthe“why”).

A numberof requirementsengineeringframeworkshaveintroducedconceptsof agentsor actors,andemploygoal-orientedtechniques.The framework of [5] usesmultiplemodelsto modelactors,objectives,subjectconceptsandrequirementsseparately, and is close in spirit to the

���framework in many ways. TheWinWin framework of [2]identifiesstakeholderinterestsandlinks themto qualityre-quirements.Thenotionof inquiry cycle in [31] is closelyrelatedto theearly-phaseRE notion,but takesa scenariosapproach. The KAOS framework [12] [35] for require-mentsacquisitionemploysthenotionsof goalsandagents,and provides a methodologyfor obtaining requirementsspecificationsfrom globalorganizationalgoals.

However, theseframeworksdo not distinguishbetweentheneedsof early-phasevs. late-phaseRE. For example,mostof themassumea globalperspective ongoals,whicharereduced,by requirementsengineers,in aprimarily top-down fashion,fully to actions. Thesemay be contrastedwith the notion of distributedintentionality in

���, where

agentsareassumedto bestrategic,whoseintentionalityareonly partially revealed,who are concernedaboutoppor-tunities and vulnerabilities,and who seekto advanceorprotecttheir strategic interestsby restructuringintentionalrelationships.

5 ConclusionsUnderstanding“why” hasbeenconsideredanimportant

partof requirementsengineeringsinceits earlydays[32].Frameworksandtechniquesto explicitly supportthemod-elling of andreasoningaboutagents’goalsandrationaleshave recentlybeendevelopedin RE. In this paper, it wasarguedthatmakinga distinctionbetweenearly-phaseandlate-phaseRE could help clarify the waysin which theseconceptsandtechniquescouldbe appliedto differentREactivities.

The���

framework wasgiven asan examplein whichagent- and goal-orientedconceptsand techniqueswereadaptedtoaddresssomeof thespecialneedsof early-phaseRE.

The proposalto use a modelling framework tailoredspecificallytoearly-phaseREandaseparateframework forlate-phaseREimpliesthatalinkagebetweenthetwo kindsof framework is needed[40]. As with otherphasesin thesoftwaredevelopmentlife cycle, therelationshipbetweenearly and late phaseRE is not strictly sequentialor eventemporal.Eachphasegeneratesanddraw onacertainkindof knowledge,which needsto be maintainedthroughoutthelife cycle for maximumbenefit[24] [20] [28]. Theap-plicationof knowledge-basedtechniquestoearly-phaseREcouldpotentiallybring abouta moresystematicapproachto this oftenad hoc, under-supportedphaseof systemde-velopment.

Preliminaryassessmentsof the usefulnessof���

mod-elling in a real settinghave beenpositive [3]. Supportingtools andusagemethodologiesarebeingdevelopedin anon-goingproject[42].

Acknowledgments

The authorgratefully acknowledgesthe many helpfulsuggestionsfrom anonymousreferees,Eric Dubois,BrianNixon, and LawrenceChung,as well as on-goingguid-ancefrom JohnMylopoulos, and financial supportfromthe InformationTechnologyResearchCentreof Ontario,andtheNaturalSciencesandEngineeringResearchCoun-cil of Canada.

References[1] A. J. C. Blythe, J. Chudge,J.E.DobsonandM.R. Strens,

ORDIT: anew methodologytoassistin theprocessof elicit-ing andmodellingorganizationalrequirements.Proc. Con-ference on Organizational Computing Systems, MilpitasCA, 1993.pp.216–227.

[2] B. BoehmandH. In, Aids for IdentifyingConflictsAmongQualityRequirements,IEEE Software, March1996.

[3] L. Briand,W. Melo, C. SeamanandV. Basili, Character-izing andAssessinga Large-ScaleSoftwareMaintenanceOrganization,Proc. 17th Int. Conf. Software Engineering.Seattle,WA. 1995.

[4] J. A. Bubenko,Information Modeling in the Context ofSystemDevelopment,Proc. IFIP, 1980,pp.395-411.

[5] J. A. Bubenko,ExtendingtheScopeof InformationMod-eling, Proc. 4th Int. Workshop on the Deductive Approachto Information Systems and Databases, Lloret-CostaBrava,Catalonia,Sept.20-22,1993,pp.73-98.

[6] J. A. Bubenko,Challengesin RequirementsEngineering,Proc. 2nd IEEE Int. Symposium on Requirements Engineer-ing, York, England,March1995,pp.160-162.

[7] K. L. Chung, Representing and Using Non-FunctionalRequirements for Information System Development: AProcess-Oriented Approach, Ph.D.Thesis,alsoTech.Rpt.DKBS-TR-93-1,Dept. of Comp. Sci., Univ. of Toronto,June1993.

[8] L. Chung,B. Nixon andE. Yu, UsingNon-FunctionalRe-quirementsto SystematicallySupportChange,2nd IEEEInt. Symp. on Requirements Engineering (RE’95), York,England,March1995.

[9] CIMOSA – Open Systems Architecture for CIM, ESPRITConsortiumAMICE, Springer-Verlag1993.

[10] J. Conklin andM. L. Begeman,gIBIS: A Hypertext Toolfor ExplanatoryPolicy Discussions,ACM Transactions onOffice Information Systems, 6(4),1988,pp.303-331.

[11] B. Curtis, H. KrasnerandN. Iscoe,A Field Studyof theSoftwareDesignProcessfor Large Systems,Communica-tions of the ACM, 31(11),1988,pp.1268-1287.

[12] A. Dardenne,A. van Lamsweerdeand S. Fickas, Goal-DirectedRequirementsAcquisition, Science of ComputerProgramming, 20,1993,pp.3-50.

[13] E. Dubois,J.Hagelstein,E. Lahou,F. PonsaertandA. Ri-faut, A KnowledgeRepresentationLanguagefor Require-mentsEngineering,Proc. IEEE, 74 (10), Oct. 1986, pp.1431–1444.

[14] E.Dubois,A Logic of Action for SupportingGoal-OrientedElaborationsof Requirements,Proc. 5th InternationalWorkshop on Software Specification and Design,Pittsburgh,PA, 1989,pp.160-168.

[15] Ph.Du Bois,The Albert II Language – On the Design andthe Use of a Formal Specification Language for Require-ments Analysis, Ph.D. Thesis,Departmentof ComputerScience,Universityof Namur, 1995.

[16] M. S.Feather, LanguageSupportfor theSpecificationandDevelopmentof CompositeSystems,ACM Trans. Prog.Lang. and Sys. 9, 2, April 1987,pp.198-234.

[17] S.FickasandR.Helm,KnowledgeRepresentationandRea-soningin the Designof CompositeSystems,IEEE Trans.Soft. Eng., 18,6, June1992,pp.470-482.

[18] O.C.Z.Gotel andA.C.W. Finkelstein,An Analysisof theRequirementsTraceabilityProblem,Proc. IEEE Int. Conf.on Requirements Engineering, Colorado Springs, April1994,pp.94-101.

[19] S.J.Greenspan,J.Mylopoulos,andA. Borgida,CapturingMoreWorld Knowledgein theRequirementsSpecification,Proc. Int. Conf. on Software Eng., Tokyo,1982.

[20] S. J. Greenspan,J. Mylopoulos andA. Borgida, On For-mal RequirementsModeling Languages:RML Revisited,(invited plenarytalk), Proc. 16th Int. Conf. Software Engi-neering, May 16-211994,Sorrento,Italy, pp.135-147.

[21] J.Grudin,Why CSCWApplicationsFail: Problemsin theDesignandEvalnof OrganizationalInterfaces,Proc. Con-ference on Computer-Supported Cooperative Work 1988,pp.85-93.

[22] M. HammerandJ. Champy, Reengineering the Corpora-tion: A Manifesto for Business Revolution, HarperBusiness,1993.

[23] M. Jackson,System Development, Prentice-Hall,1983.

[24] M. Jarke,J. Mylopoulos,J. W. SchmidtandY. Vassiliou,DAIDA: An Environmentfor Evolving Information Sys-tems,ACM Trans. Information Systems, vol. 10, no.1, Jan1992,pp.1-50.

[25] J. Lee, A Decision Rationale Management System: Cap-turing, Reusing, and Managing the Reasons for Decisions,Ph.D.thesis,MIT, 1992.

[26] A. MacLean,R.Young,V.BellottiandT.Moran,Questions,Options,andCriteria: Elementsof DesignSpaceAnalysis,Human-Computer Interaction, vol. 6, 1991,pp.201-250.

[27] J.Mylopoulos,A. Borgida,M. JarkeandM. Koubarakis,Te-los: RepresentingKnowledgeaboutInformationSystems,ACM Trans. Info. Sys., 8 (4), 1991.

[28] J. Mylopoulos,A. Borgida andE. Yu, RepresentingSoft-wareEngineeringKnowledge,Automated Software Engi-neering, to appear.

[29] B. Nuseibeh,J.KramerandA. Finkelstein,ExpressingtheRelationshipsBetweenMultiples Views in RequirementsSpecification,Proc. 15th Int. Conf. on Software Engineer-ing, Baltimore,1993,pp.187-196.

[30] C. PottsandG. Bruns,Recordingthe Reasonsfor DesignDecisions,Proc. 10th Int. Conf. on Software Engineering ,1988,pp.418-427.

[31] C. Potts,K. Takahashiand A. Anton, Inquiry-BasedRe-quirementsAnalysis,IEEE Software, March1994,pp.21-32.

[32] D. T. RossandK. E. Shoman,StructuredAnalysisfor Re-quirementsDefinition, IEEE Trans. Soft. Eng., Vol. SE-3,No. 1, Jan.1977.

[33] H. A. Simon,The Sciences of the Artificial, 2nded.,Cam-bridge,MA: TheMIT Press,1981.

[34] A. Van Lamsweerde,R. Darimont and Ph. Massonet,The MeetingSchedulerProblem: PreliminaryDefinition.Copies may be obtained from Prof. Van Lamsweerde,UniversiteCatholiquede Louvain, Unite d’Informatique,PlaceSainte-Barbe,2,B-1348Louvain-la-Neuve,Belgium.(avl@info.ucl.ac.be)

[35] A. VanLamsweerde,R. DarimontandPh.Massonet,Goal-DirectedElaborationof Requirementsfor aMeetingSched-uler: Problemsand LessonsLearnt, Proceedings of 2ndIEEE Int. Symposium on Requirements Engineering, York,England,March1995,pp.194-203.

[36] E. Yu, Modelling Organizationsfor InformationSystemsRequirementsEngineering,Proceedings of First IEEE Sym-posium on Requirements Engineering, SanDiego, Calif.,January1993,pp.34-41.

[37] E. Yu andJ.Mylopoulos,UnderstandingWhy in Require-mentsEngineering–with anExample,Workshop on SystemRequirements: Analysis, Management, and Exploitation,SchloßDagstuhl,Saarland,Germany, October4–7,1994.

[38] E.YuandJ.Mylopoulos,Understanding‘Why’ in SoftwareProcessModelling, Analysis,andDesign,Proc. 16th Int.Conf. on Software Engineering, Sorrento,Italy, May 1994,pp.159-168.

[39] E. Yu, Modelling Strategic Relationships for ProcessReengineering, Ph.D.thesis,alsoTech.ReportDKBS-TR-94-6, Dept. of ComputerScience,University of Toronto,1995.

[40] E. Yu, P. Du Bois, E. Dubois and J. Mylopoulos, FromOrganizationModelsto SystemRequirements– A ‘Coop-eratingAgents’ Approach,Proc. 3rd Int. Conf. on Coop-erative Information Systems (CoopIS-95), Vienna,Austria,May 1995,pp.194-204.

[41] E. Yu andJ.Mylopoulos,FromE-R to ‘A-R’ – ModellingStrategic Actor Relationshipsfor BusinessProcessReengi-neering,Int. Journal of Intelligent and Cooperative Infor-mation Systems, vol. 4, no.2 & 3, 1995,pp.125-144.

[42] E. Yu, J. Mylopoulos and Y. Lesperance,AI Models forBusinessProcessReengineering,IEEE Expert, August1996,pp.16-23.