USE CASES

1
USE CASES

• In this lecture Use cases- What are use
  cases?- Why to use use cases?- How to write use
  cases?- What use cases are good for?

2
Use Cases - Why?

• The users are usually not able to produce
  sufficient formal descriptions of the
  functionalities.
• A simple list of the required functionalities is
  not good enough.
• The informal general description by the users
  hardly does the job, either.
• The users may be able to describe by examples how
  they would want to use the system or how they
  perform certain tasks.

3
An Example Raising A Salary

• The user finds the salary data of the employee
  whose salary is to be raised. The user chooses
  the raise salary functionality. The system
  raises a dialogue into which the user types the
  percentage and commits the raise.
• It may be possible to specify preconditions and
  postconditions and exceptions to the processing
  of a use case. The example above had none of
  them.

4
A Definition

• When a user uses the system, she or he will
  perform a behaviourally related sequence of
  transactions in a dialogue with the system. We
  call such a special sequence a use case. A
  use case is a sequence of transactions in a
  system whose task is to yield a measurable value
  to an individual actor of the system. (I.
  Jacobsen)
• The word transaction does not mean exactly the
  same as the technical term transaction in
  database terminology.
• A use case is a story about the usage of the
  system told from an end users perspective.

5
Elements Of A Use Case (1/2)

• Use Case Name - identifies the use case
• Version
• Summary - What is it all about?
• Frequencey - How often the use case is performed?
• Usability Requirements - The most important
  aspects ensuring that the use case can be
  performed safely and efficiently
• Actors - The role of the people and other systems
  interacting with the system
• - to be continued

6
Elements Of A Use Case (2/2)

• Preconditions - When can the use case take
  place?- can be another use case
• Description The story!
• Exceptions
• Illustrations
• Postconditions - Conditions which must hold after
  the use case

7
Example Revisited (1/3)
Name SalaryRaise Version 0.9 Summary User
raises an employees salary Frequency 5 times per
day Usability Requirements Actors The user, the
employee database Preconditions The user has the
rights to search and modify the employees salary
data.
8
Example Revisited (2/3)
Description The user finds the salary data of
the employee whose salary is to be raised by
employee number. Exception Employee not found
The user chooses the raise salary
functionality.Exception No rights to raise
salary The system raises a dialogue into which
the user types the percentage and commits the
raise Exception Maximum salary exceeded
9
Example Revisited (3/3)
Exceptions - Employee not found Raised if no
employee data can be found with the given number.
Error information is shown.- No rights to raise
the salary. Raised if the user has no rights to
update salary data for this employee. Error
information is shown.- Maximum salary exceeded

10
What Can Use Cases Be Used For?

• To give concrete examples of the things we are
  supposed to be implementing.
• To give more flesh to the requirements
  specifications.
• As a source for analysis phase
• As input for the users guide
• As the basis for system testing

11
UML

• We will use UML (Unified Modelling Language) in
  some of the examples of the course. The slides
  will introduce some of the necessary notation.
• UML is a language, which has been obtained by
  merging different languages and features, some
  made for equal purposes, and therefore one should
  not aim for using all of UML in a software
  project. Much rather, pick what you need.

12
UML Use Case Diagram

• A use case diagram represents use cases and the
  participating actors external to the system.
• A use case may also include (use) another use
  case this is represented as an arrow.
• If a use case diagram gets too large, it may be
  divided into logical collections of use cases.

13
The Salary Raise Example
Salary system
Raise asalary
User
14
Several use cases
Vehicle rental system
Booking
Using
Returning
ltltincludegtgt
Official
Customer
Service
15
Use Cases As A Part Of The Requirements
Specification

• Use cases should specify the most important
  functional requirements
• For each functionality specified in the
  requirements there should be one or more use
  cases.
• In principle, the use cases are used to clarify
  the functional specifications and to show how
  different functional specifications relate to
  each other.
• However, by reading through the use cases it may
  be possible to identify system components
  (hardware and software) which have been neglected
  in the requirements specification.

16
What Should Be Chosen As A Use Case?

• Meaningful for implementation
• Valuable for the user (or customer) as such
• Too broad use cases are either too complex to
  understand or too vague to be useful.
• Too narrow use cases are either too detailed or
  describe fairly trivial events.

17
A Use Case Is Just An Example

• A use case depicts a typical way of using the
  system - but nothing more.
• The use cases are not meant to describe all ways
  to peform one task.
• Other ways can be described in other use cases or
  in the Exceptions section.
• A software designer may easily try to cover every
  possibility in the story. This is not meant to be
  done here.

18
Stylistic Issues For Use Cases

• Try to read the use case through if you get
  stuck, the use case is probably too vague.
• A use case should be a complete story, which
  starts from somewhere and ends up somewhere. It
  must make clear how and when it starts and how
  and when it finishes.
• A use case should have an explicit flow of
  actions I took the pizza from the fridge and
  put it in the microwave. I set the time to 2
  minutes and put it on. When it was ready I took
  it out and ate it.

19
More Stylistic Issues

• A use case must be simple and straightforward
• It must be so explicit that it can be argued
  about.
• If nobody disagrees with the first version of a
  use case, it is probably too vague.

20
How Long Should A Use Case Be?

• A rule of thumb It is usually good if the use
  case fits in one page.
• Long use cases are hard to understand. They may
  be too detailed or they try to cover too much
  functionality.
• In the latter case you may be able to break up
  the use case into several use cases.

21
How To Find The Use Cases?

• You (as the analyst) are not supposed to invent
  them, as they express the way the users intent to
  do things.
• So, you must identify the functionalities and
  talk with the users. Use cases are simple, the
  users should be able to provide you with the
  stories.
• You can discuss these stories and try to find out
  if things could/should be done differently.
• The use cases can be refined and modified later,
  but it will produce extra work.
• Make enough use cases!