15.1.2003Software Engineering 2003 Jyrki Nummenmaa 1 USE CASES In this lecture: Use cases - What are use cases? - Why to use use cases? - How to write

15.1.2003 Software Engineering 2003Jyrki Nummenmaa

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 user’s 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: SalaryRaiseVersion: 0.9Summary: User raises an employees salaryFrequencey: 5 times per dayUsability Requirements:Actors: The user, the employee databasePreconditions: The user has the rights to search and modify the employees salary data.


8


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


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 user’s guide• As the basis for system testing


11

UML

• We will use UML (Unified Modelling Language) in object-oriented modelling in this course.

• I will introduce some of the diagrams when they are first needed. There will also be a lecture to cover the rest.

• UML is a collection of modelling languages. They are not all meant to be used together. Instead, a suitable set of languages should be chosen.


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

Raise asalary

User

Salary system

The Salary Raise Example


14

Booking

ReturningReturning

Service

Customer Official<<include>>

Vehicle rental system

Using

A Larger Example


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!

Documents

15.1.2003Software Engineering 2003 Jyrki Nummenmaa 1 USE CASES In this lecture: Use cases - What are use cases? - Why to use use cases? - How to write