It Internation

HS2011 Systems Analysis and Design
Lecturer: Afrooz Purarjomand

Lecture 2
Modelling System Requirements (use cases, user stories and related
concepts)
3 Learning Objectives
1
User Stories, Use Cases and functional requirements
2 How we identify “Use cases”?
3 Event table
4 Use Cases – example

The System Development Life Cycle (SDLC)
Our Journey
6 Ridgeline Mountain Outfitters (RMO)
7 System Vision Document
 Problem description
 System capabilities
 Business benefits
8 Problem Description
9 System Capabilities
10 Business Benefits
What Are Requirements?
 System Requirements:
 Functional requirements- the activities the system must perform
 Non-functional requirements- other system characteristics
Analysi
What Are Requirements? (continued)
 Document functional requirements by creating models
 Analysts create models during analysis phase activity –

Define system requirements
 Two concepts help identify functional requirements in
the traditional approach and object-oriented approach
 User stories and Use cases
User stories & Use cases
 These two concepts are similar in that they focus on the

goals of the user, and they show the list of functions at the
appropriate level of detail.
 Key Differences:
– User stories are about needs. Use cases are about the
behavior you’ll build into the software to meet those needs.
– User stories are easy for users to read. User cases
describe a complete interaction between the software and
users (and possibly other systems).
User stories
 A user story is usually one short sentence in the everyday language of

the end user that states what a user does as part of his or her work.
 The users and stakeholders are responsible for identifying the user stories.
 A standard template helps users think through what they want and why they
want it.
 “As a <role played>, I want to <goal or desire> so that <reason or
benefit>.”
 For example, one user story for a bank teller might be: “As a teller, I want to
shorten each deposit processing time so I can serve more customers.”
User stories (cont.)
 A final part of a user story is the acceptance criteria. These indicate the
features that must be present for the user to be satisfied with the resulting
implementation.
 They focus on functionality, not on features or user-interface design.
 For example, the following are the acceptance criteria for the user story “bank
teller making a deposit”:
1. Customer search must be by name or by account number.
2. It would be nice to display photo and signature of customer.
3. Any check hold requirements must be indicated.
4. Current balance and new balance must be displayed.
User stories (cont.)
 Acceptance criteria define the boundaries of a user story, and are used
to confirm when a story is completed and working as intended.
 Another example: As a conference attendee, I want to be able to register
online, so I can register quickly and cut down on paperwork.
 The acceptance criteria could include:
 A user cannot submit a form without completing all the mandatory fields.
 Information from the form is stored in the registrations database.
 Protection against spam is working.
 Payment can be made via credit card.
 An acknowledgment email is sent to the user after submitting the form.
Identify Use Cases
An example: eBay Use Case
Use Case Diagrams Symbols
Use Cases (continued)
 Name each use case using Verb-Noun

E.g. Search item, fill shopping cart, produce sales history
report etc.
 Two techniques for Identifying use cases
 User goal technique
 Event decomposition technique
Use Case Diagrams for each Subsystem
Use Case Diagrams for a single actor, such as customer
Use Case Diagrams for internal RMO actors
Use Case Diagrams— The <<Includes>> relationship
Use Case Diagrams: Steps
 Identify all the stakeholders and users who would benefit by seeing a
use case diagram
 Determine what each stakeholder or user needs to review in a use
case diagram: each subsystem, for each type of user, for use
cases that are of interest
 For each potential communication need, select the use cases and
actors to show and draw the use case diagram. There are many
software packages that can be used to draw use case diagrams
 Carefully name each use case diagram and then note how and when
the diagram should be used to review use cases with stakeholders
and users
User Goal Technique
 This technique is the most common in industry

 Simple and effective
 Identify all of the potential categories of users of the system
 Interview and ask them to describe the tasks the computer can
help them with
 Probe further to refine the tasks into specific user goals, “I
need to Ship items, Track a shipment, Create a return”
User Goal Technique Some RMO CSMS Users and Goals
User Goal Technique: Specific Steps
1. Identify all the potential users for the new system

2. Classify the potential users in terms of their functional role
(e.g., shipping, marketing, sales)
3. Further classify potential users by organizational level (e.g.,
operational, management, executive)
4. For each type of user, interview them to find a list of
specific goals they will have when using the new system
(current goals and innovative functions to add value)
User Goal Technique Specific Steps (continued)
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
Event Decomposition Technique
 More Comprehensive and Complete Technique

 Identify the events that occur to which the system must respond.
 For each event, name a use case (verb-noun) that describes what the system
does when the event occurs
 Event– something that occurs at a specific time and place,
can be described, and should be remembered by the
system
Events and Use Cases
Types of Events
 External Event
 an event that occurs outside the system, usually initiated by an external agent or actor
 Temporal Event
 an event that occurs as a result of reaching a point in time
 State Event
 an event that occurs when something happens inside the system that triggers some
process
e.g. reorder point is reached for inventory item
External Event Checklist
 External agent or actor wants something resulting in a

transaction
 Customer buys a product
 External agent or actor wants some information

 Customer wants to know product details
 External data changed and needs to be updated
 Customer has new address and phone
 Management wants some information

 Sales manager wants update on production plans
Temporal Event Checklist
 Internal outputs needed at points in time

 Management reports (summary or exception)
 Operational reports (detailed transactions)
 Internal statements and documents (including payroll)
 External outputs needed at points of time

 Statements, status reports, bills, reminders
Tracing a sequence of transactions resulting in many events
Technology-dependent events: Perfect Technology Assumption
 Don’t worry about functions built into system because of limits in technology and people.
Wait until design.
 Following events deferred until the design phase
Event Decomposition Technique: Specific Steps
1. Consider the external events in the system environment that

require a response from the system by using the checklist
shown before
2. For each external event, identify and name the use case that the
system requires
3. Consider the temporal events that require a response from the
system by using the checklist shown before
4. For each temporal event, identify and name the use case that
the system requires and then establish the point of time that will
trigger the use case
Event Decomposition Technique: Specific Steps (continued)
5. Consider the state events that the system might respond to,
particularly if it is a real-time system in which devices or internal
state changes trigger use cases.
6. For each state event, identify and name the use case that the
system requires and then define the state change.
7. When events and use cases are defined, check to see if they are
required by using the perfect technology assumption. Do not
include events that involve such system controls as login, logout,
change password, and backup or restore the database, as these
are put in later.
Information about Each Event in an Event Table
RMO CSMS Project Event table
RMO CSMS Project Use Cases – Sales subsystem
RMO CSMS Project Use Cases – order fulfillment subsystem
RMO CSMS Project Use Cases – customer account subsystem
RMO CSMS Project Use Cases – marketing & reporting subsystem
References
 Satzinger, J , Jackson R.B. and Stephen D. Burd, Systems

Analysis and Design in a Changing World, 7th edition,
Thomson Learning Course Technology, 2015. Chapter 1
and Chapter 3

It Internation

Uploaded by

Copyright:

Available Formats

It Internation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

It Internation

Uploaded by

Copyright:

Available Formats

HS2011 Systems Analysis and Design

Lecturer: Afrooz Purarjomand

2 How we identify “Use cases”?

4 Use Cases – example

 Functional requirements- the activities the system must perform

 Non-functional requirements- other system characteristics

 Document functional requirements by creating models

 Analysts create models during analysis phase activity –

 These two concepts are similar in that they focus on the

 A user story is usually one short sentence in the everyday language of

 Name each use case using Verb-Noun

 This technique is the most common in industry

1. Identify all the potential users for the new system

5. Create a list of preliminary use cases organized by type of

 More Comprehensive and Complete Technique

 External agent or actor wants something resulting in a

 External agent or actor wants some information

 Management wants some information

 Internal outputs needed at points in time

 External outputs needed at points of time

1. Consider the external events in the system environment that

 Satzinger, J , Jackson R.B. and Stephen D. Burd, Systems

You might also like