1.
Project Management System
2. Requirement Engineering Tool
3. Document Management System
4. Bank Management System
Develop an application to manage Project
tasks and members (i.e. help plan, organize,
and manage resource and develop resource
estimates)
Example:
http://www.inflectra.com/SpiraPlan/Highligh
ts.aspx
https://www.atlassian.com/software/jira/try
Software system that helps manage the
various manually intensive tasks in the
requirements development and requirements
management processes.
Example:
http://www.capterra.com/requirements-
management-software/
Develop an application to manage document
storage and retrieval.
Example
https://www.zoho.com/docs/writer.html
Develop an application to help a bank manager
manage customer accounts. The bank offer several
bank accounts types. Each customer can have one or
more accounts. The customer can go the operations
permitted by the account type, such as deposit,
withdraw, or balance enquire. The bank manages the
account by debiting the fees, or crediting the profits.
Both the bank employees and the customers can print
reports about the current account details.
Narrative descriptions of domain processes in a
structured prose format
They are stories or scenarios of how people use
the system
Dice game
A software simulates a player rolling two dice. If
the total is seven, they win; otherwise, they lose.
Use case: Play a game
Actors: Player
Description: Player requests to roll the dice.
System presents results: If the dice face value
totals seven, player wins; otherwise, player loses.
Actors
Something with behavior such as person, computer system, or
organization
Scenario
It is a specific sequence of actions and interactions between
actors and the system. It is also called use case instance
It is one particular story of using a system
▪ E.g. scenario of successfully purchasing items with cash or scenario of
failing to purchase items because of credit payment denial
Use case then is a collection of success and failure scenarios
Use cases are requirements, primarily functional.
A UC is a dialogue between an Actor and a system
that accomplishes a task.
The dialogue is presented as a sequence of steps
A complete sequence of steps is a use case scenario
A scenario (UC instance) forms a complete path through the
UC.
UC can contain multiple scenarios (i.e., >1
path through UC)
Can range from simple (brief summary) to
elaborate (detailed steps using adopted
document template)
UCs are NOT object-oriented artifacts! They
feed into other OO models
Kinds of Actors
Primary actor
▪ has user goals fulfilled through using services of the SuD
▪ Why identify? To find user goals, which drive the use cases.
Supporting actor
▪ provides a service (for example, information) to the SuD
▪ Why identify? To clarify external interfaces and protocols.
Offstage actor
▪ has an interest in the behavior of the use case
▪ Why identify? To ensure that all necessary interests are
identified and satisfied.
Guidelines
How to find use cases
1.Choose the system boundary
2.Find primary actors
3.Identify goals for each primary actor
4.Define Use cases that satisfy user goals
Computerized application used to record sales and
handle payments
Used in retail store
It includes hardware and software
It also interfaces to other applications, such as a third-party
tax calculator and inventory control
Multiple and varied clients-side terminals
and interfaces
Commercial POS
Enterprise Selling Things
Checkout Service
Sales Tax
Agency
POS System
Goal: Collect
taxes on sales Sales Activity
System Cashier
Customer
Goal: Buy items Goal: Analyze sales Goal: Process sales
and performance data
Brainstorm the primary actors first.
Questions to help identify Actors and Goals
Who starts and stops the system?
Who does user and security management?
Who does system administration?
Is “Time” an actor because the system does something in
response to a time event?
Are there any external software system that call upon the
services of the system?
Organize the actors and goals in an Actor Goal List
Define Use cases for user goals
system boundary NextGen POS communication
Process Sale alternate
notation for
Customer a computer
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier
«actor»
Cash In Accounting
System
Manager
«actor»
«actor» Analyze Activity
HR System
Sales Activity
System
Manage Security
System Manage Users
Administrator use case
...
NextGen Some UML alternatives to
illustrate external actors that
Process Sale «actor» are other computer systems.
Payment
«system» Authorization The class box style can be
Payment Payment Service used for any actor, computer or
Authorization Authorization human. Using it for computer
...
Service Service actors provides visual
distinction.
Use cases are text documents, not diagrams and
use case modeling is primarily an act of writing text,
not drawing diagrams.
Use Case Style
Black Box Use cases
▪ Focus on what not how
Use Case Formats
Brief
Casual
Fully dressed
Brief one-paragraph summary usually the main success
scenario done during early requirements analysis should take
only a couple of minutes
Causal informal paragraph format multiple paragraphs
covering various scenarios
Fully dressed details all steps and variations includes supporting
sections such as preconditions and success guarantees etc.
Use case Section Comment
Use case name Start with a verb
Scope The system under design
Primary Actor Calls on system to deliver its services
Stakeholders and interests Who cares about the system and what do
they want
Precondition(s) What must be true on start
Post condition(s) What must be true on successful completion,
and worth telling the reader
Main Success Scenario Unconditional happy path scenario of
success
Extensions Alternate scenario of success or failure
UC: Process Sale
1. User selects new sale option
2. System requests item identifier
3. User enters item identifier
4. System records sale of item, and
5. System displays item description, price, current total
Steps 2-5 repeated until user finished
6. User selects sale finished option
7. System displays total and taxes due
8. User selects payment option
9. System requests payment information
10. User enters payment information
11. System handles payment
12. System logs completed sale and sends sale information to Accounting System
and Inventory System
13. System generates receipt
A computerized library system for a
university keeps track of all books and
journals in the library and their check-out EmployeeLogin
status.
Checkout and return are automated
through a bar code reader (an external CheckIn
device).
The library system also interfaces with
an external relational database which LibEmployee CheckOut
stores information about the library
users (students, faculty, and staff),
including whether they have any library CheckBookAvailability
items checked out.
Library users can access the catalog and
recall books and journals. LibUser
Library employees have the same access IssueBook
as well as additional capabilities (e.g.,
listing the status of an item).
Note: the library catalog is part of the ReturnBook
library computer system so it is not
shown as an actor.
1. Employee initiates use case by
entering user name EmployeeLogin
2. System prompts for password
3. If password is valid, employee is CheckIn
logged on and now has access to
employee commands LibEmployee CheckOut
Exceptions? e.g., cannot find the
employee login CheckBookAvailability
LibUser
IssueBook
ReturnBook
ReturnBook
1. User/Employee initiates use case by
selecting the check book availability EmployeeLogin
option
2. System prompts for choice of search
by title, author, or call number CheckIn
3. User makes selection and enters
title, author or call number
4. System performs search through the LibEmployee CheckOut
library catalog database
5. If a match is found, system displays
item status (not checked out, CheckBookAvailability
checked out and due date, overdue)
LibUser
Exceptions? IssueBook
ReturnBook
List main system functions (use cases) in a column
Draw ovals around the function labels
Draw system boundary
Draw actors and connect them with use cases
Use-Case Diagram Case Study [1]
After client interview the following system scenarios were
identified:
– A customer buys a product
– The supplier restocks the machine
– The supplier collects money from the machine
On the basis of these scenarios, the following actors
can be identified:
Customer; Supplier
