Transcript Use Cases - University of Waikato

Use Cases
•Why use ‘em?
•How do they work?
•UC diagrams
•Using them later in the software
development cycle
Requirements analysis:
Use Case Model
• Use cases document what a system
does/should do, not how it delivers/will
deliver those functions
• UCs document system behavior from the
user’s point of view
– Work inwards from user requirements
– Thinking in terms of what the user wants to do
with the system, not how the system will be
implemented
…continued
• A use case is a sequence of actions that an actor
performs within a system to achieve a particular
goal
• An actor represents an external entityt that
interacts with the system
– An actor exchanges information with the system
– A role that a user can play with regards to a system
– An entity such as another sytsem or a database (outside
of the system being modeled)
…continued
• UC model is developed to help with:
– Capturing system requirements
– Maintaining traceability across iterations in
system design/development
– Creating system validation (testing) models
• UCs evolve; as understanding of users, user
needs, system requirements, environment,
etc etc change, UCs must reflect that change
An aside: System Development
Life Cycle
•
•
•
•
•
•
•
•
•
Project proposal
Preliminary investigation
Requirements analysis and specification
System design
Detailed design
Programming/implementation
Testing
Installation and changeover
Maintenance
Use Cases for requirements
capture
• Result of Use Case modeling: all required system
functionality is described in the UCs
• UCs provide a structured approach to
requirements capture
– Identify the actors
– For each actor find out
• What they need from the system; that is, what use cases there
are which have value for them
• Any other interactions they expect to have with the system,
that is, which UCs they might take part in for someone else’s
benefit
Identify Actors
• Potential human actors tend to be easy to identify
– Note distinction between actor and user:
• User is anyone who uses the system
• Actor is a role that a user can play
• A single person (user) can play more than one role (be an
instance of more than one Actor)
• Actors don’t have to be described in great detail;
they are identified to help you figure out the UCs
that they carry out
…identify actors
• Non-human actors can be less clear
– Wht counts as an external system or device?
– Do whatever seems to be most useful—show
interactions with external systems:
• Always
• When it is the other system that initiates the contact
• When it is the other system that gets value from the
contact
Example: actors in a library
system
• Users:
– Librarian
– Library member
– Non-member of the library
• Actors (roles):
–
–
–
–
–
Librarian
BookBorrower
JournalBorrower
Browser
Homeless
Developing the Use Cases
• Sit down with the Actors and identify their
pertinent Use Cases
• Ask:
– What are the main tasks (in terms of the organization)
performed by each actor?
– Will the actor read or update any information in the
system?
– Will the actor have to inform the system about changes
outside the system?
– Does the actor have to be informed about unexpected
changes?
Use Cases in a library system:
diagram
• BookBorrower
– Reserve book, Borrow copy
of book, Return copy of
book, Extend loan
• JournalBorrower
– Borrow journal, Return
journal
• Browser
– Browse
• Librarian
– Update catalog, …
• Homeless
– Special case of Browser
Documenting Use Cases
• Detail of each UC must be written down
– Use third person, active voice English
– Use terms from the problem domain
– Say what the system does (in terms of the business;
what it accomplishes for the business), not
implementation detail or how
• The basic course of action is the main start-tofinish path the user will follow under normal
circumstances
• An alternative course of action can represent an
infrequently used path, an exception, or an error
…documenting
• Create a simple UC template:
– Actor(s) that initiate the UC
– Basic course
– Alternate courses
• Eliciting Use Cases from system stakeholders:
– Ask “what happens?” This gets the basic course of action started.
– Ask “and then what happens?” Keep asking this question until you
have all details fo the basic course on paper
– Be relentless. “what else can happen? Are there any other things
that can happen?” Keep asking until you have a set of alternative
courses written down.
– Alternative courses usually hardest to elicit—hard to think of
unusual situations, odd occurrences, …
Borrow copy of book UC
Actor: BookBorrower
Basic course:
1.
A BookBorrower presents a book.
2.
The system checks that the borrower is a member of the library and
that s/he does not already have the maximum permitted number of
books on loan.
3.
The system records that this library member has this copy of the
book on loan.
Alternative course(s):
1.
If potential borrower is not a member of the library, then the system
refuses the loan.
2.
If the library member has the maximum permitted number of books
(12 for staff members, otherwise 6) then the system refuses the loan.
Scope of a UC
• Often difficult to decide whether a set of user-system
interactions is one UC or several UCs
• Rule of thumb:
– A UC typically represents a major piece of functionality that is
complete from beginning to end
– A UC must deliver something of value to an actor
• Focus on things of value that a system provides to an actor
– Group sequences of actions together
– Review, modify, test action sequences as a unit
– Note that a UC represents a complete functionality—don’t
represent an individual action that is part of an overall function as a
UC (ex: Borrower presenting a book is not a single UC)
Relationships between UCs
• <<extend>> relationship: extends a UC by adding new
behavior or actions
– Example: Borrow ‘Adult Materials’ book; <<extends>> Borrow a
copy of a book
– need to follow additional steps for AM books
• <<include>> relationship: one UC references another UC
– Means that one UC uses the other UC when executing
– Example: would make sense to have a UC ‘Check library fine’
– Then ‘Borrow copy of a book’ would have an <<include>>
relationship with ‘Check library fine’ UC
Use Case diagrams in the analysis
process
• Client interviews start the process
– Use terminology of the client
• Start talking to users (generally more than the single client
person)
– Initial interviews reveal actors and functional requirements in
general terms (high level UCs)
– Helps define boundaries and scope of the proposed system
– Later interviews delve into more detail. Produce UC models that
show usage scenarios and sequences in detail
• Diagrams and UCs should be produced iteratively
UCs through the development cycle
• Planning
– Need a list of all UCs for the proposed system, together
with:
• A good idea of what each entails
• An understanding of who wants each, why, and how much
• Knowledge of which UCs carry the most risk when
implementing
• An estimate of how long it should take to implement each UC
• Political aspects
– Identify which UCs are most important to which people
– Satisfy the most influential people first
…through development
• Technical aspects
– Attempt/deliver UCs associated with highest
risk first
• System validation
– Each UC satisfies some functional
requirement(s)
– Correct design realizes each UC
– Derive system tests from UC walkthroughs