1. A Linguistics-Based Approach for Use Case Driven Analysis Using Goal and Scenario Authoring Vijayan Sugumaran Oakland University Rochester, Michigan, USA Coauthors: Jintae Kim, Sooyong Park Sogang University Seoul, Republic of Korea

2. Content  Introduction and background  The overview of our approach  Four abstraction level  Goal and scenario modeling using linguistics  Use case conversion  Future work and conclusion

3. Background  Use case driven analysis  Popular  Cope with the complexity  Limitations  The lack of support for a systematic elicitation process  No rationales where a use case is derived  Problems  Difficulty in finding a use case  Not easy to handle use cases

4. Introduction  We propose  to enhance use case driven analysis using Goal and Scenario authoring  Why goal ?  Goal modeling is an effective way to identify requirements  A goal provides a rationale for requirements  Why scenario?  Scenarios support goal modeling  A scenario is familiar to both users and developers

5. Related approaches  Cockburn’s approach  the use of goals to structure use cases by connecting every action in a scenario to a goal  It is just concerned with the description of scenarios in a use case  Ralyté’s approach  integrated scenario based techniques into existing methods  does not provide any rationale for identifying use cases  cannot reflect where the use cases come from

6. Research Objective  Provide a supplementary elicitation process, which helps a human engineer to analyze the system with UCDA through goal and scenario modeling  Specifically, develop an approach that supports deriving use cases from goal modeling through authoring scenarios

7. Our approach

8. Our contribution  Goal and scenario authoring rules  Make it easy to identify requirements using goal and scenario  Based on linguistics concept  Bridge between elicitation and analysis  Provide rules for conversion from goal and scenario based requirements to use case diagram  Based on the linguistics concept

9. Four abstraction levels of Goal and Scenario  Reason that we need these levels  Separation of concern in Requirements  Easy for goal and scenario modeling

10. Four abstraction levels (1)  Four levels  Business level: to identify the ultimate purpose of a system  e.g. “Improve the services provided to our bank customers” (business goal)  Service level: to identify the services that a system should provide to an organization and their rationale  e.g. “Cash withdrawal” (service goal)  e.g. “The customer withdraws cash from the ATM” (service scenario)

11. Four abstraction levels (2)  Four levels (continued)  Interaction level: the interactions between the system and its agents  e.g. “Withdraw cash from ATM ” (interaction goal)  e.g. “Users Insert a card into ATM ” (interaction scenario)  Internal level: what the system needs to perform the interactions selected at the system interaction level  e.g. “Deliver cash to the user ” (internal goal)  e.g. “The ATM engineer counts the amount of cash by counter” (internal scenario)

12. Goal and Scenario Modeling  A goal is defined as “something that some stakeholder hopes to achieve in the future”  A goal is described using the template:, where V is an active verb, Target is a conceptual or a physical object Direction is either source or destination.  Example:  ‘(Withdraw) Verb (Cash) Target (From the ATM) Dir ’  A scenario is “a possible behavior limited to a set of purposeful interactions taking place among several agents”  The scenarios capture real situations or concrete behaviors

13. Scenario Authoring  As each individual goal is discovered, a scenario can be authored for it.  Once a scenario has been authored, it can be explored to yield further goals  A scenario at a higher level may yield goals for the next level  Scenarios at the Service level may yield specific goals for the Interaction Level  Similarly, scenarios at the Interaction Level may yield goals for the Internal Level

14. Scenario Structure

15. Scenario authoring rules  Scenario authoring rule 1 (S1)  All scenarios should be authored using the following format:  ‘Subject:Agent + Verb + Target:Object + Direction:(Source, Destination)’  e.g. (The customer) Agent (deposits) Verb (cash) Obj (to the ATM) Dest  Scenario authoring rule 2 (S2)  ‘Subject’ should be filled with an Agent  e.g. (ATM) Agent sends a prompt for code to the user

16. Scenario authoring rules (contd.)  Scenario authoring rule 3 (S3)  ‘Verb’ should include the properties stated at requirements levels  e.g. The customer (withdraws) Verb cash from the ATM (service scenario)  e.g. The ATM (displays) Verb a prompt for amount to the user (interaction scenario)  Scenario authoring rule 4 (S4)  ‘Target’ should be an object.  e.g. The ATM delivers (the cash) Obj to the user

17. Scenario authoring rules (contd.)  Scenario authoring rule 5 (S5)  ‘Direction’ should be either source or destination  e.g. The bank customer withdraws cash (from the ATM) So  Scenario authoring rule 6 (S6)  The designed system and the other agents are used exclusively in instantiating the Subject and Direction constructs  e.g. (The bank customer) Agent withdraws cash (from the ATM) So

18. ATM example of rule S1 ~ S2 LevelGoalsScenarios Service Cash withdrawal (g1) 1. The customer withdraws cash from the ATM 2. The ATM reports cash transactions to the bank Interaction Withdraw cash from ATM (g1.1) 1.The ATM receives a card from user (action) If the card is valid, then (state) 2. ATM sends a prompt for code to the user(action) 3. The ATM receives the code from user(action) If the code is valid, then (state) 4. The ATM displays a prompt for amount to the user(action) 5. The ATM receives the amount from user(action) If the amount is valid, then (state) 6. The ATM ejects the card to the user(action) If the user asked the ATM to supply a receipt, then (state) 7. The ATM ejects the printed receipt to the user(action) 8. The ATM delivers the cash to the user(action) Internal Check the validity of Card (g1.1.1) 1. The ATM engine asks the card reader to read the validity date and the card number 2. The card reader returns the card number and validity date to the ATM engine 3. The ATM engine transmit the card number and validity date to Bank 4. The ATM receives the result of card validity from Bank

19. The output of goal and scenario modeling

20. Identifying Use Cases  Typically, a use case contains the set of possible scenarios to achieve a goal  The purpose of the use case specification is to describe how the agent can interact with the system to get the service and achieve a particular goal.  Our core idea is that the goals and scenarios at the interaction level are used to help construct use cases  The interaction level focuses on the interactions between the system and its agents  A goal at the interaction level is achieved by one or more scenarios

21. Use case Conversion  The structure of relationship between goals and other artifacts

22. Use case Conversion rules  Conversion guiding rule 1 (C1)  Goals listed at the interaction level become use cases in accordance with the output of goal and scenario modeling  The interaction level focuses on the interactions between the system and its agents  Similar to the definition of a use case

23. Use case Conversion rules (contd.)  Conversion guiding rule 2 (C2)  Agents included in scenarios within a goal and wanting to achieve a goal become primary actors

24. Use case Conversion rules (contd.)  Conversion guiding rule 3 (C3)  The States contained in scenarios at the Interaction Level are mapped to internal goals at the Internal Level  Conversion guiding rule 4 (C4)  If goals at the internal level have more than two parent goals, they become another use case with the relationship

25. The final output of our approach

26. Meeting Reservation System (MRS)  Some typical high-level requirements for MRS  The reservation system should be able to present a list of reservation suggestions based on:  time period, duration, equipment, room capacity, equipment capacity.  Notifications should provide efficient feedback to participants and it should be very simple to respond to them.  Help the users in determining the most appropriate reservation by making suggestions based on input from the user as well as relevant information that is available.  E.g. suggest meeting room(s) nearby based on room properties (number of sites, room equipment etc),  suggest additional equipment if appropriate (e.g. extension lead, appropriate plugs, etc.

27. Goal Hierarchy

28. Use Case Diagram

29. Summary and Future work  Presented an approach for Generating Use Cases  It overcomes the lack of support for the elicitation process in UCDA and the underlying rationale  a) both goal modeling and scenario authoring  b) use case conversion guidelines  The artifacts resulting from our approach could be used as input to a use case diagramming tool to partially automate the process of use case diagram generation  Future work  further refinement of the scenario structure  further refinement of the authoring and conversion rules  Develop a proof-of-concept prototype  Empirical Validation