Deriving use cases from organizational modeling - Requirements ...

More documents

Recommendations

Info

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
Page 1 and 2: Deriving Use Cases from Organizatio
Page 3 and 4: system performs that yields an obse
Page 5: the system. For instance, the softg

Deriving use cases from organizational modeling - Requirements ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?