Deriving use cases from organizational modeling - Requirements ...

Deriving Use Cases from Organizational ModelingVictor F.A. Santander *Jaelson F. B. CastroUniversidade Federal de Pernambuco – Centro de InformáticaCx. Postal 7851, CEP 50732-970, Recife-PE, BRAZILPhone: (+55 81) 3271-8430, Fax: (+55 81) 3271-8438{vfas,jbc}@cin.ufpe.brAbstractUse Cases Diagrams in the Unified LanguageModeling (UML) have been used for capturing systemfunctional requirements. However, the systemdevelopment occurs in a context where organizationalprocesses are well established. Therefore, we need tocapture organizational requirements to define how thesystem fulfils the organization goals, why it is necessary,what are the possible alternatives, etc. Unfortunately,UML is ill equipped for modeling organizationalrequirements. We need other techniques, such as i*, torepresent these aspects. Nevertheless, organizationalrequirements must be related to functional requirementsrepresented as Use Cases. In this paper we present someguidelines to assist requirement engineers in thedevelopment of Use Cases from the i* organizationalmodels.1. IntroductionSystem development occurs in a context whereorganizational processes are well established. However,as discovered in empirical studies, the primary reason forsoftware system failure is the lack of properunderstanding of the organization by the softwaredevelopers. Unfortunately, the dominant object orientedmodeling technique, UML, is ill equipped fororganizational requirement modeling. We need otherstechniques, such as i* [15] to represent these aspects. Weargue that i* framework, is well suited to representorganizational requirements that occur during the earlyphaserequirements capture, since it provides adequaterepresentation of alternatives, and offers primitivemodeling concepts such as softgoal and goal. These earlyactivities would enable an understanding of how and whythe requirements came about.Nevertheless, organizational requirements must berelated to functional requirements represented withtechniques such as Use Cases. However, Use Casedevelopment demands great experience of the requirementengineers. The heuristics presented in the literature todevelop Use Cases are not sufficient to allow a systematicdevelopment. Indeed, they do not consider relevantorganizational aspects such as goals and softgoal.In this work, we propose some guidelines to supportthe integration of i* and Use Case modeling. We describesome heuristics to assist requirement engineers to developUse Cases based on the organizational i* models. Thispaper is organized as follows. Section 2 introduces theconcepts used by i* framework to represent organizationalrequirements and early requirements. In Section 3, wereview Use Case modeling. In Section 4, we present thebenefits of our approach as well as describe the guidelinesto integrate i* organizational models and Use Casesdiagrams. In Section 5, we introduce a brief case study toshow the viability of our proposal. Section 6 discussesrelated works and concludes the paper.2. The i* Modeling FrameworkWhen developing systems, we usually need to have abroad understanding of the organizational environmentand goals. The i* framework [15] provides understandingof the reasons (“Why”) that underlie system requirements.I* offers two models to represent organizationalrequirements: the Strategic Dependency (SD) Model andthe Rationale Dependency (SR) Model.2.1. The Strategic Dependency Model - SDThis model focuses on the intentional relationshipsamong organizational actors. It consists of a set of nodesand links connecting them, where nodes represent actorsand each link represents the dependency between actors.The depending actor is called Depender and the actor whois depended upon is called Dependee. The i* frameworkdefines four types of dependencies among actors: goal,* Partially Supported by CNPq Grant No. 147192/1999-4. On-leave from Universidade Estadual do Oeste do Paraná.Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE

esource, task and softgoal. Figure 1 shows an StrategicDependency (SD) Model of the meeting schedulingsetting with a computer-based meeting scheduler [15].Figure 1. Strategic Dependency Model for the MeetingScheduling Problem.The meeting initiator depends on participant to attendthe meeting. The meeting initiator delegates much of thework of meeting scheduling to the meeting scheduler.The meeting scheduler determines what are the acceptabledates, given the availability information (task dependencyEnterAvailDates(m)). The meeting initiator does not carehow the scheduler does this, as longer as the acceptabledates are found. This is reflected in the goal dependencyMeetingBeScheduled from the initiator to the scheduler.On the other hand, to arrive at an agreeable date,participants depend on the meeting scheduler for dateproposals (resource dependency ProposedDate(m)). Onceproposed, the scheduler depends on participants toindicate whether they agree with the date (resourcedependency Agreement(m,p)). For important participants,the meeting initiator depends critically on theirattendance, and thus also on their assurance that they willattend (softgoal dependencyAssured(AttendsMeeting(ip.m))). The meeting schedulerdepends on the meeting initiator to provide a date range(task dependency EnterDateRange(m)) for the scheduling.2.2. The Strategic Rationale Model - SRThe Strategic Rationale (SR) model allows modelingof the reasons associated with each actor and theirdependencies. Two news links are added to previousnotation:• Means-ends: This link indicates a relationship betweenan end - which can be a goal to be achieved, a task tobe accomplished, a resource to be produced, or asoftgoal to be satisficed - and a means for attaining it.• Task-decomposition: A task is modeled in terms of itsdecomposition into its sub-components. Thesecomponents can be goals, tasks, resources, and/orsofgoals.In Figure 2, we present an example of the StrategicRationale (SR) model. We use the SR notation to detailthe Meeting Scheduler actor. Due to space limitation, wedo not detail the Meeting Initiator and MeetingParticipant actors (see the complete model in [15]). TheMeeting Scheduler actor represents a software system thatpartially performs the meeting scheduling, while theMeeting Initiator and Meeting Participant, are responsiblefor providing or receiving information to the system. TheMeeting Scheduler actor possesses a Schedule Meetingtask which is decomposed into three sub-componentsusing the task-decomposition relationship:FindAgreeableSlot, ObtainAgreemet andObtainAvailDates. These sub-components represent thework that will be accomplished by the meeting schedulersystem.Figure 2. Strategic Rationale (SR) Model to theMeeting Scheduler System.3. Use Cases in UMLScenario-based techniques have been used by thesoftware engineering community to understand, modeland validate users requirements [9] [10] [13] [14]. Amongthese techniques, Use Cases have received a specialattention in the object oriented development community.Use Cases in UML [3] are used to describe the use of asystem by actors. An actor is any external element thatinteracts with the system. A Use Case is a description of aset of sequences of actions, including variants, that aProceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE

system performs that yields an observable result value toan actor. It is desirable to separate main (primaryscenario) versus alternative (secondary scenario) flowsbecause a Use Case describes a set of sequences, not justa single sequence, and it would be impossible to expressall the details of an interesting Use Case in just onesequence.In order to cope with increasing complexity of UseCases description, UML caters for three structuringmechanism: inclusion, extension and generalization. Forfurther information see [3].4. Deriving Use Cases from OrganizationalModeling.In this section we argue how our approach can improvethe Use Case development. In section 4.1 we outline themain benefits accomplished by approach and in section4.2 we describe it in detail.4.1. Benefits of i* and Use Case Integrationi* provides an early understanding of theorganizational relationships in a business domain. As wecontinue the development process, we need to focus onthe functional and non-functional requirements of thesystem-to-be. As a first step in the late requirements phasewe can adopt Use Cases to describe functionalrequirements of the system. We argue that the Use Casedevelopment from organizational modeling using i*allows requirement engineers to establish a relationshipbetween the functional requirements of the intendedsystem and the organizational goals previously defined inthe organization modeling. Besides, through a goalorientedanalysis of the organizational models, we canderive and map goals, intentions and motivations oforganizational actors to main goals of Use Cases. Weassume, that for each Use Case we have associated a maingoal, which represents what the user aims to reach as aresult of the execution of the Use Case. In our proposal,the Use Case scenario description is based onorganizational models, which are well known andunderstood by all stakeholders. Note that our approachcan be used for any type of system.We can mention other important benefits obtainedusing our approach, such as:• Many researchers [1] [6] [8] [14] [16] have consideredgoals in a number of different areas of RequirementsEngineering. Goal-oriented approaches torequirements acquisition may be contrasted withtechniques that treat requirements as consisting only ofprocesses and data, such as traditional systemsanalysis or “objects”, such as the object-orientedmethods, but which do not explicitly capture why andhow relationships in terms of goals.• The relationships between systems and theirenvironments can also be expressed in terms of goalbasedrelationships. This is partly motivated bytoday’s more dynamic business and organizationalenvironments, where systems are increasingly used tofundamentally change businesses process [16].Deriving Use Cases from i* relationships allowstraceability and evaluation of the impact of thesechanges into the functional requirements of theintended system;• Some of the Use Case pitfalls and drawbacksdescribed in [11], can be partially solved using ourapproach. For instance, Use Cases are written from theactor’s (not the system’s) point of view. We deriveUse Cases from actors dependencies defined explicitlyin i*. Another positive aspect is the ability to definethe essential Use Cases for the intended system. Thisavoids defining too many Use Cases and allowsmanaging the appropriate granularity of Use Cases.Finally, the integration between requirementsengineers and customers during the organizationalmodel development also allows customers (actors) tobetter understand the Use Cases originated from thesemodels;• To elicit and specify system requirements observingthe actor’s goal in relation to the system-to-be, is away of clarifying requirements [16]. From i* we canderive these goals, associate them with system actorsand then refine and clarify the requirements into UseCases.4.2. Proposed ApproachTo guide the mapping and integration process of i*organizational models and Use Cases, we have definedsome guidelines which must be applied according to thesteps represented in Figure 3. In this figure, steps 1, 2 and3 represent the discovery of system actors and itsassociated Use Cases diagrams and descriptions. Theinput for the integration process are the StrategicDependency (SD) and Strategic Rationale (SR) modelsdeveloped through i* framework. In steps 1 and 2, theinput is the Strategic Dependence (SD) Model. Thedescription of scenarios for Use Cases (step 3) is derivedfrom elements represented in the Strategic Rationale (SR)Model. The results of the integration processes are UseCase diagrams for the intended system and scenariotextual descriptions for each Use Case.In the sequel we suggest heuristics for the Use Casesdevelopment from organizational modeling with i*.Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE

guideline(s) to be used to analyze each dependency(dependum) (see table 1). For instance, some Use Casescan be associated with the Meeting Participant actorobserving their dependencies presented in i*:Guideline 5.1: goal dependencies - goals in i* can bemapped to Use Case goals; For instance, in Figure 1,the goal dependency AttendsMeeting(p,m) betweenMeeting Initiator (Depender) and Meeting Participant(Dependee) can be mapped to the AttendsMeeting UseCase, which will contain the several steps accomplishedby Meeting Participant to attends to the meeting.Figure 3. Steps of the integration process between i*and Use Cases in UML1º Step: Discovering System Actors.Guideline 1: every actor in i* should be considered as apossible Use Case actor; For example, the MeetingParticipant i* actor in Figure 1 is a possible UML actor.Guideline 2: the actor considered in i* should be externalto the intended software system. For example, theMeeting Participant actor is external to the systembecause it will interact with the intended meetingscheduler system.Guideline 3: if the actor is external to the system, itshould be guaranteed that the i* actor is a candidate actorin the Use Case diagram. For this purpose, the followinganalysis is necessary:Guideline 3.1: the actor dependencies in i* must berelevant from the point of view of the intended system;For instance, the Meeting Participant actor in i* can bemapped to Use Case actor, considering thatdependencies associated with it, characterizes it asimportant in an interaction context with the meetingscheduler system.Guideline 4: actors in i*, related through the IS-Amechanism in the organizational models and mappedindividually for actors in Use Cases (applying guidelines1, 2 and 3), will be related in the Use Case diagramsthrough the relationship. For instance,the IS-A relationship between Meeting Participant andImportant Participant in Figure 1, can be mapped togeneralization relationship between these actors in theUse Case diagram.2º Step: Discovering Use Cases for the Actors.Guideline 5: for each discovered actor of the system (step1), we should observe all its dependencies (dependum) inwhich the actor is a dependee, looking for Use Cases forthe actor; Initially, we recommend to create a tablecontaining the discovered actors and the informationabout the dependencies for the actor from the point ofview of a dependee. Moreover, you can include whichActorDependencyType ofDependencyGuidelineto be usedMeeting Participant AttendsMeeting(p,m) Goal (G5.1)Table 1. Gathered information from SD Models toaid requirement engineers to derive Use Cases.Guideline 5.2: task dependencies - if an actor dependson another actor for the accomplishment of a task, itshould be investigated if this task needs to bedecomposed into other sub-tasks. For example, for thetask dependency EnterDateRange(m) associated withthe Meeting Initiator actor (see Figure 1), we canconsider that the task of supplying a date range for themeeting scheduling can include several aspects (latermapped to Use Case steps) such as to associate rangedates with specific meetings, to establish priorities forspecific meetings, etc. Thus, from the taskEnterDateRange(m) we can generate the Use Casecalled EnterDateRange for the Meeting Initiator actor.Guideline 5.3: resources dependencies - if an actordepends on another actor for obtaining a resource(s),why is it required? If there is a more abstract goal, itwill be the candidate goal of the Use Case for the actor.For instance, for the resource dependencyAgreement(m,p) associated with the MeetingParticipant actor (see Figure 1), we conclude that themain goal of obtaining of Agreement(m,p) resource is ascheduled date agreement from each participant. Wecould consider that in this agreement process, eachparticipant could agree with the proposed meeting datewith certain schedule restrictions or duration time. Still,the agreement could involve an analysis of otherpossible dates. In other words, to obtain the scheduleddate agreement, several interaction steps betweenmeeting scheduler and meeting participant could bedefined in one Use Case called Agreement for theMeeting Participant actor.Guideline 5.4: sofgoal dependencies - typically, thesofgoal dependency in i* is a non-functionalrequirement for the intended system. Hence, a softgoaldoes not represent a Use Case of the system but a nonfunctionalrequirement associated with a Use Case ofProceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE

the system. For instance, the softgoalAssured(AttendsMeeting(ip,m)) between MeetingInitiator and Important Participant actors can bemapped into a non functional requirement associatedwith the Use Case AttendsMeeting. This non-functionalrequirement indicates that it is necessary to assure thatthe Important Participant attends to the meeting.Guideline 6: analyze special situations, where an actordiscovered (following the step 1), possess dependencies inrelation to an actor in i* that represents an intendedsoftware system or part of it. These dependencies usuallygenerate Use Cases. It is important to notice that in thissituation the derived Use Case is associated with thedepender actor in the relationship. This occurs due to thefact that the dependee is a software system and thedepender (Use Case actor) must interact with the systemto achieve the goal associated with the generated UseCase. For instance, the goal dependencyMeetingBeScheduled between Meeting Initiator andMeeting Scheduler system in the Figure 1, points out forthe definition of the Use Case MeetingBeScheduled forthe Meeting Initiator actor, which represents the use of thesystem by the actor, describing the details of the meetingscheduling process.Guideline 7: classify each Use Case according to the typeassociated to its goal (business, summary, user goal orsubfunction). This is based on a classification schemeproposed by Cockburn [7]. A business goal represents ahigh level intention, related to business processes, that theorganization or user possesses in the context of theorganizational environment. An example could be thegoal "organizing a meeting in the possible shortest time".A summary goal represents an alternative for thesatisfaction of a business goal, as in the case of the goal,"meeting scheduling by software system". An user goalresults in the direct discovery of a relevant functionalityand value for the organization actor using a softwaresystem. An example could be the goal, "the meetingparticipant wishes to attend the meeting". Finally,subfunction-level goals are those required to carry outuser goals. An example could be the goal, “enter daterange for meeting scheduling” by the Meeting Initiator.To aid requirement engineers to identify new Use Caseand better understand the discovered Use Cases, werecommended to generate a table containing the actorname, the Use Case goal and the goal classification (seetable 2).Actor Use Case Goal Goal ClassificationMeeting Participant AttendsMeeting User GoalTable 2. Use Case goal classification.3º Step: Discovering and Describing Use Case Scenario.Guideline 8: analyze each actor and its relationships inthe Strategic Rationale (SR) model, to extract informationthat can lead to the description of the Use Cases scenariofor the actor. It is important to remember that SR modelsrepresent the internal reasons associated with the actorgoals. Therefore, we must consider internal elementswhich are used by the actor to achieve goals and sofgoals,to perform tasks or obtain resources. The actor has theresponsibility to satisfy these elements and thedecomposition in SR shows how the actor will beperforming this. Typically, the dependencies associatedwith the actor are satisfied internally through two types ofrelationships used in SR: means-ends and taskdecomposition.These relationships must be observed toderive scenario steps for the Use Cases. For instance,consider the Strategic Rationale (SR) Model in Figure 2.From the Meeting Scheduler actor point of view, we knowthat the Schedule Meeting task is decomposed intoObtainAvailDates, FindAgreeableSlot andObtainAgreement. Since the software system objective isto accomplish meeting scheduling, we could consider thatthese tasks are the necessary high-level steps toaccomplish a meeting schedule (Use CaseMeetingBeScheduled defined for the Meeting Initiatoractor). Thus, this Use Case could contain the steps (theprimary scenario description) regarding the need to obtainfrom each Meeting Participant, the available dates for ameeting (ObtainAvailDates); the need to define the bestmeeting dates that could be scheduled(FindAgreeableSlot); and to obtain the participantsagreement for a proposed meeting date(ObtainAgreement).5. Case StudyIn this section, we follow the steps proposed in Figure3 and apply the appropriate guidelines to the exampledescribed in the previous section (Figure 1 and 2). Recallthat Figure 1 shows a Strategic Dependency (SD) modelfor meeting scheduling while Figure 2 represents theStrategic Rationale (SR) model. Hence, theseorganizational models are used to discover and describeUse Cases in UML for the Meeting Scheduler system. Webegin deriving the Use Case actors from the SD model.We then find the Use Cases for the actors observing theactors dependencies in SD model. Next, the primaryscenario for one derived Use Case is described from theSR model. Last but not least, a version of the Use Casediagram in UML for the Meeting Scheduler system isgenerated.• From Figure 1, we can find candidates actors for theUse Case development. According to the guidelines inthe 1 st step of the proposal, we conclude that one ofthe analyzed actors does not follow guideline 2. TheMeeting Scheduler actor is a system, i.e. the softwareto be developed. Therefore, this i* actor cannot beProceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE

considered as a Use Case actor. The other i* actors areconsidered appropriate because their strategicdependencies refer to relevant aspects for the meetingscheduler system (guideline 3) development. So, thelist of candidates Use Cases actors includes: MeetingInitiator, Meeting Participant and ImportantParticipant. We also note that Important Participant isa type (relationship IS-A) of participant. According toguideline 4 (1 st step), we consider this actor aspecialization of Meeting Participant actor.The next step is to discover and relate Use Cases foreach actor according to the guidelines presented in the 2ºStep (Discovering Use Cases for the Actors).• Initially, following the guideline 5 and observing theSD model presented in Figure 1 we can generate thetable 3.ActorDependencyType ofDependencyGuidelineto be usedMeetingAttendsMeeting(p,m) Goal (G5.1)ParticipantMeetingEnterAvailDates(m) Task (G5.2)ParticipantMeetingAgreement(m,p) Resource (G5.3)ParticipantMeeting Initiator EnterDateRange(m) Task (G5.2)Table 3. Gathered information from SD Models toderive Use Cases for the Meeting Scheduler System.• Thus, for the Meeting Participant actor, observing thisactor as Dependee, we can indicate some Use Casesoriginated from the actor dependency relationships(guideline 5). Initially, we should consider the goaldependency (guideline 5.1) of the actor as Dependee.In table 3, we verify the goal AttendsMeeting(p,m),which represents the need of the meeting participantactor to attend the meeting. This goal originates theUse Case AttendsMeeting. Several steps are necessaryto achieve this goal. Typically, this is a user goal(guideline 7). The fulfillment of the Use Case goalbrings a relevant result for Meeting Participant actor,allowing it to attend to the meeting. Usually, thedescription of the primary scenario (to beaccomplished later) for this Use Case, will presentother user goals that can originate new Use Cases forthe system.The next dependency associated with the MeetingParticipant actor is the task dependencyEnterAvailDates(m). According to guideline 5.2, wecan consider the need of several interaction stepsamong the participants (Meeting Participant actor) andthe meeting scheduler system to enter available dates.Some steps could include participants to supply a listof exclusion dates and preferred dates in a particularformat, to validate these dates by the system, etc.Thus, the task EnterAvailDates(m) generate the UseCase EnterAvailDates for the Meeting ParticipantActor.Continuing our analysis, we can observe associatedwith the Meeting Participant (Dependee) actor theresource dependency Agreement(m,p). Followingguideline 5.3, we conclude that the main goal ofobtaining of Agreement(m,p) resource is an scheduleddate agreement from each participant. We couldconsider that in this agreement process, eachparticipant could agree with the proposed meeting datewith certain schedule restrictions or duration time.Still, the agreement could involve an analysis of otherpossible dates. In other words, the schedule of datesrequires several interaction steps between the systemand the Meeting Participant actor, which defines theAgreement Use Case of the Meeting Participant actor.• To discovery of Use Cases candidates for the MeetingInitiator actor follows the same guidelines (2º Step).We have one dependency associated with the MeetingInitiator actor (see table 3): the taskEnterDateRange(m). Using guideline 5.2 for this taskdependency we observe that to supply a date range forthe meeting scheduling can include several aspects(sub-tasks) such as to associate range dates withspecific meetings, to establish priorities for specificmeetings, etc. Thus, from the EnterDateRange(m) taskwe generate the EnterDateRange Use Case for theMeeting Initiator actor.Having considered all dependencies for the MeetingInitiator as Dependee, we should now consider specialsituations (guideline 6). Observing Figure 1, wevisualize the goal dependency MeetingBeScheduledbetween Meeting Initiator and Meeting Scheduler(software to be developed), which requires some sortof interaction. Therefore, we can define theMeetingBeScheduled Use Case that represents the useof the system by the Meeting Initiator actor. In thisUse Case, we describe the details of the meetingschedule process. Note that in this special situationthe depender (meeting initiator) is the Use Case actor.• Finally, following the guideline 7 we can to classifyeach discovered Use Case goal, as showed in the table4.Thereby, after we have used the proposed guidelines(2º Step), we have discovered EnterDateRange andMeetingBeScheduled Use Cases for the Meeting Initiatoractor as well as AttendsMeeting, EnterAvailDates andAgreement Use Cases for the Meeting Participant actor.Therefore, we can begin the description of the primaryand secondary scenarios and the Use Cases relationships(3º Step). At this point, the Strategic Rationale (SR)model is used as source of information for the scenariodescription and the Use Cases relationships.Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE

Actor Use Case Goal Goal ClassificationMeeting Initiator EnterDateRange SubfunctionMeeting Initiator MeetingBeScheduled SummaryMeeting Participant AttendsMeeting User GoalMeeting Participant EnterAvailDates SubfunctionMeeting Participant Agreement SubfunctionTable 4. Goal Classification for the MeetingScheduler System.For example, the MeetingBeScheduled Use Casediscovered for the Meeting Initiator actor represents theuse of the system by Meeting Initiator to accomplish themeeting scheduling. This Use Case should contain all thenecessary steps to schedule a meeting that begins whenthe Meeting Initiator supplies information to the systemsuch as the date range to schedule a meeting. Based on thesupplied dates range by Meeting Initiator, the system mustfind available dates for all the participants for the meetingas well as elaborate a consensus dates list within which adate will be chosen to be proposed and agreed. Thisprocess must result in a consensus-scheduled date for themeeting and later in the confirmation of this date for allthe participants. Thus, for the Use CaseMeetingBeScheduled, we could have the primary scenariowith the following steps:Use Case: MeetingBeScheduledActor: Meeting InitiatorUse Case Goal: Schedule a Meeting (summary goal, seeguideline 7)Primary Scenario:1. The Use Case begins with the Meeting Initiator actorsupplying the system with a date range for themeeting; (the EnterDateRange Use Case is included in this step).2. The system should request from participants (MeetingParticipant) an available date list for the meetingbased on the proposed date range by the MeetingInitiator; (the EnterAvailDates Use Case is included in this step).3. The system should find a consensus date list, filteringinformation observing the available dates sent by theparticipants and the proposed date range sent byMeeting Initiator;4. Based on the consensus list, the system proposes adate for the meeting to be scheduled;5. The Meeting Initiator expects that the system requeststhe agreement for a scheduled meeting date. (TheAgreement Use Case is included > inthis step).The information for the description of this Use Casehas as main source the Strategic Rationale (SR) Modelpresented in the Figure 2. Following the guideline 8, wemust observe which elements are involved in the SRmodel to achieve the MeetingBeScheduled goal byMeeting Scheduler actor. This actor has the responsibilityto achieve MeetingBeScheduled which originated theMeetingBeScheduled Use Case (according to guideline6). Thus, observing the internal strategic reasonsassociated with Meeting Scheduler we can conclude thatthe base information for the step 1 in this Use Case, isextracted from the EnterDateRange task dependency,establishing the need that Meeting Initiator supplies daterange for the meeting to be scheduled. Previously, in theUse Case discovery for the system, we considered that theprocess of establishing a date range included several steps(sub-tasks) such as to associate range dates with specificmeetings, to establish priorities for specific meetings, etc.These steps should be described in the EnterDateRangeUse Case. For this reason, this Use Case is included in step 1.Steps 2 and 3 are extracted from the decompositions ofthe task Schedule Meeting (associated with MeetingScheduler in the Figure 2). Step 2 derives from theobservation of the ObtainAvailDates task and itsassociated EnterAvailDates task dependency. TheEnterAvailDates Use Case is included because it represents the necessary steps for the entry ofthe available dates list by participants. Step 3 originatesfrom FindAgreeableSlot goal and the MergeAvailDatestask. This step represents the internal actions of thesystem to define a list of the consensus dates for themeeting scheduling. Step 4, is extracted from observationof the ProposedDate resource dependency in connectionwith the task Schedule Meeting (Figure 2). It is assumed,given the defined information in the models of the Figure1 and 2, that the proposed date should be defined by thesystem, using some previously established and definedcriterion by the Meeting Initiator, taking as base forexample, priorities of organization meetings.Step 5, derives from the system need to obtain theagreement for the chosen date for the meeting scheduling.This information arises from the observation of the taskObtainAgreement and its associated resource dependencyAgreement (Figure 2). Previously, in the Use Casediscovery for the system, we assumed that in order for aparticipant to agree with the proposed date, it wasnecessary the accomplishment of some interaction stepsbetween the participant and the Meeting Scheduler.These steps should be described in the Agreement UseCase. For this reason, this Use Case is included in the step 5. We can describe the others Use Cases in asimilar way.After we have applied the proposed guidelines to thiscase study, we can define, as described in the Figure 4, aversion of the Use Cases diagram in UML for the MeetingScheduler system.Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE

MeetingInitiatorEnterDateRangeMeetingBeScheduledAgreement AttendsMeetingMeetingParticipantEnterAvailDatesImportantParticipantFigure 4. Use Case Diagram for the MeetingScheduler system.The descriptions of the discovered Use Cases couldstill be modified or complemented, as new relationshipsare elicited.6. Conclusions and Related WorksIn this paper we argued that the Use Casesdevelopment can be improved by using the i*organizational models. We presented some heuristics anda case study to show the viability and benefits of ourapproach.Some related works include the requirements-drivendevelopment proposal presented in the Tropos framework[4] and the integration of i* and pUML diagrams [5].These works argue that organizational models arefundamental for the development of quality software,which can satisfy the real needs of users andorganizations. Several groups have also discussed thechallenges and associated risks building quality systemduring goal and scenario analysis. For instance, theScenIC method [12] uses goal refinement and scenarioanalysis as its primary methodological strategies. Thismethod includes systematic strategies to identify actors,goals, tasks, and obstacles into evolving systems. InAnton et al. [2], the GBRAM method [1] is used to derivegoals from a use-case based requirements specification. Inthe CREWS project [13] [14], the CREWS-L`Ecritoireapproach [14] aims at discovering/eliciting requirementsthrough a bi-directional coupling of goals and scenariosallowing movement from goals to scenarios and viceversa.However, these approaches do not considerorganizational models for deriving goals and scenarios forintended systems.Further research is still required to describe moresystematic guidelines, that can aid requirement engineersto relate non-functional requirements [6] (softgoals in i*)with functional requirements of the system, describedthrough Use Cases in UML. Work is underway toincorporate goal-oriented modeling approaches [1] [8][12] [14] into our proposal aiming at discovering otherUse Cases from the exploration of already discoveredgoals. We also expect to develop more real case studies aswell as to provide some tool support for the proposedmapping.7. References[1] A.I. Anton, Goal identification and refinement in thespecification of software-based information systems. Phd Thesis,Georgia Institute of Technology, Atlanta, GA, June 1997.[2] A.I. Anton, R.A. Carter, A. Dagnino, J.H. Dempster, and D.F.Siege, “Deriving Goals from a Use Case Based RequirementsSpecification”, Requirements Engineering Journal, Springer-Verlag, Volume 6, pp. 63-73, May 2001.[3] G. Booch, I. Jacobson, and J. Rumbaugh, The Unified ModelingLanguage User Guide, Addison-Wesley, 1999.[4] J.F. Castro, M. Kolp, and J. Mylopoulos, “A Requirements-Driven Development Methodology”, In: CAISE’01, Proceedingsof the 13 th Conference on Advanced Information SystemsEngineering. Heildelberg, Germany: Springer Lecture Notes inComputer Science LNCS 2068, pp. 108-123, 2001.[5] J.F. Castro, F. Alencar, G. Cysneiros, and J. Mylopoulos,“Integrating Organizational Requirements and Object OrientedModeling”, In Proceedings of the Fifth IEEE InternationalSymposium on Requirements Engineering - RE’01, pp. 146-153,August 27-31, Toronto, 2001.[6] L. Chung, B.A. Nixon, E. Yu, and J. Mylopoulos, Non-Functional Requirements in Software Engineering (Monograph),Kluwer Academic Publishers, 472 pp, 2000.[7] A. Cockburn, Writing Effective Use Cases, Humans andTechnology, Addison-Wesley, 2000.[8] A. Dardene, V. Lamsweerde, and S. Fikas, “Goal-DirectedRequirements Acquisition”, Science of Computer Programming,20, pp. 3-50, 1993.[9] I. Jacobson, Object Oriented Software Engineering: A Use CaseDriven Approach, Addison-Wesley, 1995.[10] J.C.S.P. Leite, G. Rossi, F. Balaguer, and V. Maiorana,“Enhancing a requirements baseline with scenarios”, InProceedings of the Third IEEE International Symposium onRequirements Engineering – RE’97, pages 44-53. IEEEComputer Society Press, January 1997.[11] S. Lilly, “Use Case Pitfalls: top 10 problems from Real projectsusing Use Cases”, In: Proceedings, technology of object orientedlanguages and systems, pp 174-183, 1-5 August, 1999.[12] C. Potts, “ScenIC: A Strategy for Inquiry-Driven RequirementsDetermination”, In Proceedings of the Fourth IEEE InternationalSymposium on Requirements Engineering – RE’99, Ireland, June7-11, 1999.[13] J. Ralyté, C. Rolland, and V. Plihon, “Method EnhancementWith Scenario Based Techniques”, In Proceedings of CAISE 99,11th Conference on Advanced Information Systems EngineeringHeidelberg, Germany, June 14-18, 1999.[14] C. Rolland, C. Souveyet, and C.B. Achour, “Guiding GoalModeling Using Scenarios”, IEEE Transactions on SoftwareEngineering, Vol 24, No 12, Special Issue on ScenarioManagement, December 1998.[15] E. Yu, Modelling Strategic Relationships for ProcessReengineering, Phd Thesis, University of Toronto, 1995.[16] E. Yu and J. Mylopoulos, “Why Goal-Oriented RequirementsEngineering”, Proc. Fourth International Workshop RequirementsEngineering: Foundations of Software Quality REFSQ’98, pp.15-22, Pisa, June 1998.Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE