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