A Linguistics-Based Approach for Use Case Driven Analysis Using Goal and Scenario Authoring
Vijayan SugumaranOakland University
Rochester, Michigan, USA
Coauthors:
Jintae Kim, Sooyong ParkSogang University
Seoul, Republic of Korea
Content Introduction and backgroundThe overview of our approachFour abstraction levelGoal and scenario modeling using
linguisticsUse case conversionFuture work and conclusion
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
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
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 meth
ods does not provide any rationale for identifying use cases cannot reflect where the use cases come from
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
Our approach
Goal and Scenario levelBusiness
ServiceInteraction
Internal
Separation of concernsGoal & Scenario modeling
ScenarioAuthoring Rules
<Subject + Verb + Target + Direction>
Systematicguideline
<Goal, Scenario>
elicit
represented
Transfer rules
<Goal, Scenario> <Actor, Use case>
Use case Transfer
Use case diagramSystematic guideline
elicited
:artifact :activity
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
Four abstraction levels of Goal and ScenarioReason that we need these levels
Separation of concern in Requirements Easy for goal and scenario modeling
Business goal
given
Service goalService
Scenarios
refined
Interactiongoal
InteractionScenarios
yield
Internalgoal
InternalScenarios
yield
author
author
author
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)
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)
Goal and Scenario Modeling A goal is defined as “something that some sta
keholder hopes to achieve in the future” A goal is described using the template:
<V + Target + Direction>, 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
Scenario AuthoringAs 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 goalsA 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
Scenario Structure
Action
Subject Verb
Parameter
Target Direction
1
11
1
1 1+
Agent Activity Object Source
Destination
Normal Scenario Exceptional Scenario
Scenario State1
1+
Goal achieve
1 1+1+
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
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
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
ATM example of rule S1 ~ S2Level Goals Scenarios
ServiceCash withdrawal (g1)
1. The customer withdraws cash from the ATM2. The ATM reports cash transactions to the bank
InteractionWithdraw 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)
InternalCheck the validity of Card (g1.1.1)
1. The ATM engine asks the card reader to read the validity date and the card number2. The card reader returns the card number and validity date to the ATM engine3. The ATM engine transmit the card number and validity date to Bank4. The ATM receives the result of card validity from Bank
The output of goal and scenario modeling
Provide the ATM services to our bank users
Withdraw cash from ATM
Cash withdrawal Deposit Transfer Inquiry
Report the transaction
Check the validity of
card
Business Level
Service Level
Interaction Level
Internal Level
G
g1g2 g3
g4
g1.1g1.2
g1.1.1g1.1.2
Check the validity of code
Check the validity of amount
Print the receipt
g1.1.3
g1.1.4g1.1.5
g1.1.6
Connect Bank
g1.2.1 g1.2.2
goal
Send the transaction
Eject the card
Deposit cash into ATM
Deliver the cash to user
goal having one more parent goals
AND
OR
……
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
Use case ConversionThe structure of relationship between
goals and other artifacts
Agent Actor
Goal Use case
Scenario
derives
has
names
contains
achieves
1+
1
1+
1 1
1+
11
1+
communicates
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
Use case Conversion rules (contd.)
g1.1: Withdraw cash from ATM
Sc1.1:1.The ATM receives a card from userIf the card is valid, then (state)
2. ATM sends a prompt for code to the user3. The ATM receives the code from userIf the code is valid, then (state)
4. The ATM displays a prompt for amount to the user5. The ATM receives the amount from userIf the amount is valid, then (state)
6. The ATM ejects the card to the userIf the user asked the ATM to supply a receipt, then (state)
7. The ATM ejects the printed receipt to the user8. The ATM delivers the cash to the user
user
<Subject, Verb, Target, Direction: user>
Agent: user
achieve
has
derived
by rule S6
Conversion guiding rule 2 (C2) Agents included in scenarios within a goal
and wanting to achieve a goal become primary actors
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 <include> relationship
The final output of our approach
User
Bank
Withdraw
Report
Deposit
Transfer
Inquiry
Check validity
<<include>>
<<include>>
<<include>>
<<include>>
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.
Goal Hierarchy
Manage the Meeting Reservation (G)
Handle Reservation (g1) View Information (g2)
Make Meeting Reservation (g1.1)
Change Meeting Reservation (g1.2)
Cancel Meeting Reservation (g1.3) View Meeting
Schedule (g2.1)View Resource Calendar (g2.2)
Log in(g1.1.1)
Send the notification email(g1.1.3)
Display the schedule(g2.1.1)
Confirm making reservation (g1.1.2)
Confirm changing reservation (g1.2.1)
Confirm canceling reservation (g1.2.1)
Display the calendar (g2.2.1)
goal
goal having one more parent goals
AND
OR
Business level
Service level
Interactionlevel
Internal level
Use Case Diagram
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