SOFTWARE ENGINEERING LECTURE 4 - PowerPoint PPT Presentation

1 / 20
About This Presentation
Title:

SOFTWARE ENGINEERING LECTURE 4

Description:

SOFTWARE ENGINEERING LECTURE 4 In this lecture: - Use cases USE CASES - WHY? The users are usually not able to produce sufficient formal descriptions of the ... – PowerPoint PPT presentation

Number of Views:115
Avg rating:3.0/5.0
Slides: 21
Provided by: uta106
Category:

less

Transcript and Presenter's Notes

Title: 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!
Write a Comment
User Comments (0)
About PowerShow.com