IT2004 004

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____

IDENTIFYING USER STORIES AND USE CASES 4. The current balance and new balance must be
displayed.
Use Case Description Use Case
- An activity the system performs in response to a request by a
User Story user.
- It states what an end-user does as part of his or her work. - Two (2) techniques are recommended for identifying use
- It describes a goal the user has when using the system cases:
- A basic concept in Agile development because it focuses on 1. User goal techniques
simplicity, additional value, and user collaboration. 2. Event decomposition technique
- Document the functional requirement quickly and less - Use case techniques place the responsibility for identifying
formally than traditional requirements modeling by focusing and detailing the requirements on the system developers.
on who, what, and why for each function.
- The standard template for a user story looks like this: Use Cases and User Goal Technique
“As a <role played>, I want to <goal or desire> so that <reason - The user goal technique is a technique to identify use cases
or benefit> .“ by determining what specific goals or objectives must be
For example, some user stories for a bank teller might be: completed by the system for the user.
 “As a teller, I want to process the deposit to quickly to - The user goal technique for identifying use cases includes
serve more customers.” these steps:
 “As a teller, I want to balance the cash drawer to assure 1. Identify all the potential users for the new system.
there were no errors.” 2. Classify the potential users in terms of their functional role
 As a customer of the bank using an ATM, some user (e.g., shipping, marketing, sales).
stories might be: 3. Further classify potential users by organizational level
 “As a bank customer, I want to withdraw cash and feel (e.g., operational management, executive)
confident with the stack of cash I get is the correct User User goal and resulting use
amount.” case
 “As a bank customer, I want to deposit a check and feel Potential customer Search for item
confident the deposit is recorded correctly.” Fill shopping cart
View product rating and
Acceptance Criteria comments
- The final part of a user story Marketing manager Add/update product information
- Indicate the features that must be present for the user to Add/update promotion
be satisfied with the resulting implementation. Produce sales history report
- Its focus on functionality, not on features or user-interface Shipping personnel Ship order
design. Track shipment
- Example: “bank teller making a deposit”: Create item return
1. Customer lookup must be by name or by account Table 1. Identifying the use case with the user goal technique
number.
2. It would be nice to display the photo and signature 4. Interview each type of user to determine the specific goals
of the customer. they will have when using the new system. Start with
3. Any check hold requirements must be indicated. goals they currently have and then get them to imagine

03 Handout 1 *Property of STI

 [email protected] Page 1 of 7
 IT2004 004

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____

innovative functions they think would add value.

Encourage them to state each goal in the imperative verb-
noun form, such as Add customer, Update order, and
Produce a month-end report.
5. Create a list of preliminary use cases organized by type
of user.
6. Look for duplicates with similar use case names and
resolve inconsistencies.
7. Identify where different types of users need the same use
cases.
8. Review the completed list with each type of user and then
with interested stakeholders.

Use Cases and Event Decomposition

- A technique to identify use cases by determining the business
events to which the system must respond
- Table 1 shows the potential customer use cases: Search for
item, Fill shopping cart, and View product rating and Figure 1. Events in a charge account processing system
comments are good examples of elementary business that lead to use cases
processes.
- An event occurs at a specific time and place, can be -
Figure 1 shows some events that are important to a retails
described, and should be remembered by the system. store’s charge account processing system.
- Events drive or trigger all processing that a system does, so  The functional requirements are defined by use cases
listing events and analyzing them makes sense when there is based on six events.
a need to define system requirements by identifying use
 A customer triggers three events: “customer pays a
cases.
bill”, “customer makes a charge”, and “customer
changes address.”
Event Decomposition Technique
 The system responds with three use cases: Record a
- When defining the requirements for a system, it is useful to
payment, Process a charge, or Maintain customer
begin by asking, “What business events occur that will require
data
the system to respond?”
- The initial perspective helps keep the analyst focus on a high-  Three other events are triggered inside the system by
level view of the system (looking at the scope), rather than on reaching a point in time: “time to send out monthly
the inner workings of the system. statements,” “time to send late notices,” and “time to
- It also focuses on the system’s interfaces outside people and produce end-of-week summary reports.
other systems.  The system responds with use cases that carry out
what it is time to do: Produce monthly statements,
Send late notices, and Produce summary reports.
Types of Events
1. External events

03 Handout 1 *Property of STI

 [email protected] Page 2 of 7
 IT2004 004

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____

2. Temporal events
3. State events (also called internal events) Identifying Events

External Events - Events Versus Prior Conditions and Responses

- An event that occurs outside the system – usually initiated by  It is sometimes difficult to distinguish between an
an external agent or actor event and part of a sequence of prior conditions that
- An external agent (actor) is a person or organizational unit that leads up to the event.
supplies or receives data from the system.  Consider a customer buying a shirt from a retail store,
- Checklist to help to identify external events: as shown in Figure 2.
 The external agent wants something resulting in a  The analyst has to think through such a sequence to
transaction. arrive at the point where an event directly affects the
 The external agent wants some information system.
 Data has changed and needs to be updated.  In this case, the system is not affected until the
 Management wants some information. customer is in the store, has a shirt in hand ready to
purchase, and says, “I want to buy this shirt.”
Temporal Events
- An event that occurs as a result of reaching a point in time.
- The analyst begins identifying temporal events by asking
about specific deadlines that the system must accommodate.
 What output are produced at that deadline?
 What other processing might be required at that
deadline?
- Checklist to use in identifying temporal events:
 Internal outputs needed
 Management reports (summary or exception)
 Operational reports (detailed transactions)
 Internal statements and documents
(including payroll)
 External outputs needed
 Statements, status reports, bills, reminders
Figure 2. Sequence of actions that lead up to only one event
State Events affecting the system
- An event that occurs when something happens inside the  The way to determine whether an occurrence is an event
system that triggers the need for processing. or whether it is part of the interaction following the event
- Also called internal events. is by asking if any long pauses or intervals occur (i.e., can
- Often, state events occur as a consequence of external the system transaction be completed without
events. interruptions?) or is the system at rest again, waiting for
- Sometimes, they are similar to temporal events, except the the next transactions?
point in time cannot be defined.

03 Handout 1 *Property of STI

 [email protected] Page 3 of 7
 IT2004 004

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____

- The Sequence of Events: Tracing a Transaction’s Life Cycle  Figure 4 list some examples of events that can be
 A useful method for identifying events is to trace the deferred until the developer is designing in the system
sequence of events that might occur for a specific external controls.
agent or actor.
 From Figure 3, the analyst can think through all the
possible transactions that might result from one new
customer.

Figure 4. Events deferred until designing system controls

- Steps in the Event Decomposition Technique

1. Consider the external events in the system
environment that requires a response from the
Figure 3. The sequence of “transactions” for one specific customer system by using the external events checklist.
resulting in many events 2. For each external event, identify and name the use
case that system requires.
- Technology-Dependent Events and System Controls 3. Consider temporal events that require a response
 Sometimes, the analyst is concerned about events that from the system using the temporal event checklist.
are important to the system but do not directly concern 4. For each temporal event, identify and name the use
users or transactions (i.e., design choices or system case that the system requires and then establish the
controls). point of time that will trigger the use case.
 The analyst temporarily ignore these events; however, 5. Consider the state events that the system might
they became important later for design. respond to, particularly if it is a real-time system in
 The system controls checks or safety procedures put in which devices or internal state changes trigger use
place to protect the integrity of the system. cases.
 Perfect technology assumption states that events should 6. For each state event, identify and name the use case
be included during analysis only if the system would be that the system requires and then define the state
required to respond under perfect conditions (i.e., which change.
equipment never breaking down, capacity for processing 7. When events and use cases are defined, check to see
and storage being unlimited, and people operating the if they are required as part of the analysis using the
system being completely honest and never making perfect technology assumption. Do not include events
mistakes) that are involved such system controls as login,
logout, change password, and backup or restore the
database, as there are put in as system controls.

03 Handout 1 *Property of STI

 [email protected] Page 4 of 7
 IT2004 004

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____

Fill shopping cart Customer

Use Cases, Actors, and Use Case Diagram Notation Empty shopping cart Customer
Check out shopping cart Customer
Brief use case description – an often one-sentence description that Fill reserve cart Customer
provides a quick overview of a user case Empty reserve cart Customer
Convert reserve cart Customer
Use case diagram – the UML model used to illustrate use cases and Create phone sale Customer service representative
their relationships to actors Create store sale Store sales representative
Table 3. Use cases and actors for CSMS Sales Subsystem
Automation boundary - the boundary between the computerized
portion of the application and the users who operate the application CSMS Account Subsystem
but are part of the total system.
Use Cases Users/actors
Create/update customer Customer, customer service
Use Case Brief use case description
account representative, store sales
Create customer User/actor enters new customer representative
account account data, and the system assigns
Process account adjustment Customer
an account number, creates a customer
Send message Customer
record, and creates an account record.
Browse message Customer
Look-up customer User/actor enters customer account
Request friend linkup Customer
number, and the system retrieves and
displays customer and account data Reply to linkup request Customer
Process account User/actor enters the order number, Send/receive partner credits Customer
adjustment and the system retrieves customer and View “mountain bucks” Customer
order data; actor enters adjustment Transfer “mountain bucks” Customer
amount, and the system creates a Table 4. Use cases and actors for CSMS Marketing Subsystem
transaction record for the adjustment
Table 2. Use case and a brief description

CSMS Sales Subsystem

Use Cases Users/actors
Search for item Customer, customer service
representative, store sales
representative
View product comments and Customer, customer service
ratings representative, store sales
representative
View accessory combinations Customer, customer service
representative, store sales
representative
Figure 5. A simple use case with an actor

03 Handout 1 *Property of STI

 [email protected] Page 5 of 7
 IT2004 004

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____

Figure 6. A use case diagram of a Customer Account subsystem for

RMO, showing all actors

Figure 7. All use cases involving the customer actor for the Sale
subsystem

03 Handout 1 *Property of STI

 [email protected] Page 6 of 7
 IT2004 004

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____

Developing a Use Case Diagram

- The steps to develop a use case
1. Identify all the stakeholders and users who would benefit
from having a use case diagram.
2. Determine what each stakeholder or user needs to review
in a use case diagram. Typically, a use case diagram
might be produced for each subsystem, for each type of
user, for use cases with the <<includes>> relationship,
and for use cases that are of interest to specific
stakeholders.
3. For each potential communication need, select the use
cases and actors to show and draw the use case diagram.
Many software packages can be used to draw use case
diagrams.
4. Carefully name each use case diagram and then note
Figure 8. Use cases involving the customer service representative how and when the diagram should be used to review use
and store sales representative for the Sales subsystem cases with stakeholders and users.

REFERENCE:

Satzinger, J., Jackson, and R., Burd, S. (2015). Systems Analysis and Design in
a Changing World – Course Technology. USA. Cengage Learning.

Dennis, A. Wixom B and Tegarded, D. (2015). Systems Analysis and Design:

An Object Oriented Approach UML (5th ed.). USA: Wiley

Figure 9. A use case diagram of the Fill shopping cart <<includes>>

relationships

03 Handout 1 *Property of STI

 [email protected] Page 7 of 7