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 <strong>from</strong> 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 <strong>modeling</strong>of 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 <strong>use</strong> 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 <strong>use</strong>d by thesoftware engineering community to understand, modeland validate <strong>use</strong>rs 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 <strong>use</strong>d to describe the <strong>use</strong> 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 <strong>Requirements</strong> 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) flowsbeca<strong>use</strong> 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. <strong>Deriving</strong> Use Cases <strong>from</strong> 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 the<strong>organizational</strong> 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 <strong>from</strong> <strong>organizational</strong> <strong>modeling</strong> using i*allows requirement engineers to establish a relationshipbetween the functional requirements of the intendedsystem and the <strong>organizational</strong> goals previously defined inthe organization <strong>modeling</strong>. Besides, through a goalorientedanalysis of the <strong>organizational</strong> models, we canderive and map goals, intentions and motivations of<strong>organizational</strong> actors to main goals of Use Cases. Weassume, that for each Use Case we have associated a maingoal, which represents what the <strong>use</strong>r aims to reach as aresult of the execution of the Use Case. In our proposal,the Use Case scenario description is based on<strong>organizational</strong> models, which are well known andunderstood by all stakeholders. Note that our approachcan be <strong>use</strong>d 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 <strong>Requirements</strong>Engineering. 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 <strong>organizational</strong>environments, where systems are increasingly <strong>use</strong>d tofundamentally change businesses process [16].<strong>Deriving</strong> Use Cases <strong>from</strong> 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 <strong>from</strong> theactor’s (not the system’s) point of view. We deriveUse Cases <strong>from</strong> 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 <strong>organizational</strong>model development also allows customers (actors) tobetter understand the Use Cases originated <strong>from</strong> 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*<strong>organizational</strong> 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 derived<strong>from</strong> 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 <strong>from</strong> <strong>organizational</strong> <strong>modeling</strong> with i*.Proceedings of the IEEE Joint International Conference on <strong>Requirements</strong> Engineering (RE’02)1090-705X/02 $17.00 © 2002 IEEE
Change language