Deriving use cases from organizational modeling - Requirements ...

More documents

Recommendations

Info

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
Page 1 and 2: Deriving Use Cases from Organizatio
Page 3: system performs that yields an obse
Page 7 and 8: Actor Use Case Goal Goal Classifica

Deriving use cases from organizational modeling - Requirements ...

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

Delete template?

Save as template?