SOFTWARE ENGINEERING LECTURE 4

1
SOFTWARE ENGINEERING LECTURE 4

• In this lecture- Use cases

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
A USE CASE 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)
• 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)

• Use Case Name - idenifies 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
• Preconditions - when can the use case take
  place- can be another use case - to be
  continued

6
ELEMENTS OF A USE CASE (2)

• DESCRIPTION - the story
• Exceptions
• Illustrations
• Postconditions - conditions which must hold after
  the use case

7
EXAMPLE REVISITED (1)
Name SalaryRaise Version 0.9 Summary User
raises an employees salary Frequencey 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)
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 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 ...
9
USE CASES - FOR WHAT?

• To give concrete examples of the things we are
  supposed to be implementing.
• To give a little more flesh to the requirements
  specification.
• A source for object analysis
• The first version of the users guide
• The basis of system testing

10
USE CASES - RULE 1

• USE CASES MUST SPECIFY THE MOST IMPORTANT
  FUNCTIONAL REQUIREMENTS
• For each functionality specified in the
  requirements there should be one or more use
  cases.

11
USE CASES - RULE 2

• USE CASES ARE USED TO SPECIFY THE SYSTEM IN MORE
  DETAIL, BUT THEY CAN ALSO GIVE RISE TO NEW
  REQUIREMENTS.
• 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.

12
USE CASES - RULE 3

• A USE CASE DESCRIBES SOMETHING THAT THE DESIGNER
  CAN BE PROUD OF AND THE CUSTOMER IS WILLING TO
  PAY FOR.
• 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.
• Each use case must be beneficial to the end user
  as such.

13
USE CASES - RULE 9 (sorry about the order )

• 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 Exception section.

14
USE CASES - RULE 4

• A USE CASE IS A PLAY.
• And you should be able to be one of the actors if
  you read the use case.
• Too much freedom to the actors results in chaos.
• In system testing the tester reads the use case
  through the manuscript.

15
USE CASES - RULE 5

• A USE CASE HAS A BEGINNING, A MAIN BODY, AND AN
  ENDING.
• So, it 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.

16
USE CASES - RULE 6

• A USE CASE IS LIKE AN ESSAY WRITTEN BY AN
  ELEMENTARY SCHOOL PUPIL
• Simple and straightforward
• 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.
• A software designer may easily try to cover every
  possibility in the story.
• If you do not know something, you can refine it
  later, but do not leave the initial use case too
  vague.

17
USE CASES - RULE 7

• A 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.

18
RULE 8 A USE CASE IS LOUD CLEAR

• A use case must make a clear statemnt.
• It must be explicit to the readers.
• 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.

19
RULE 10 USE USE CASES FOR DEVELOPMENT TESTING

• Use cases should be specified so that they can be
  used in object and behaviour analysis. And they
  should be used there, too.
• Also, the use cases should be so explicit that
  they can be used as the basis of system test
  cases. And they should be used there, too.

20
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 will 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 modified later, but it will
  produce extra work.
• Make enough use cases!