A LinguisticsBased Approach for Use Case Driven Analysis Using Goal and Scenario Authoring

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

• Cockburns 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 ltV
  Target Directiongt, 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
• SubjectAgent Verb TargetObject
  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
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 ltincludegt 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