Title: SOFTWARE ENGINEERING LECTURE 4
1SOFTWARE ENGINEERING LECTURE 4
- In this lecture- Use cases
2USE 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.
3A 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.
4A 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.
5ELEMENTS 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
6ELEMENTS OF A USE CASE (2)
- DESCRIPTION - the story
- Exceptions
- Illustrations
- Postconditions - conditions which must hold after
the use case
7EXAMPLE 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.
8EXAMPLE 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 ...
9USE 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
10USE 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.
11USE 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.
12USE 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.
13USE 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.
14USE 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.
15USE 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.
16USE 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.
17USE 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.
18RULE 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.
19RULE 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.
20HOW 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!