Use Cases

These notes should ideally be read before Iterative development is studied.

 

definition 1:  when we talk about the domain, we mean the world that the computer system is being designed for; this could be the world of law, of farming, of medicine etc.  Successful systems analysis and design involves getting two groups of people to talk to each other: experts in the relevant domain and experts in software development. 

 

definition 2: hyperlink: when you press on a piece of usually underlined text on a web site and it takes you to another page. 

 

Part 0: Introduction:

 

This chapter of the notes deals with use cases.  Use cases enable us to capture user requirements in chunks. 

 

Part 1 introduces you to the art of  how to represent use cases textually 
Part 2 shows you how to use case diagrams to provide a diagrammatic table of contents for your textual use case descriptions. 
Part 3 explains how to discover use cases

Part 4 explains the difference between business use cases and system use cases
Part 5 provides end of chapter exercises

In the early 90s Ivar Jacobson emphasised use cases as a way of finding the requirements of the users and did so, I think, largely because he, and loads of other people, were concerned about  the quality of existing software products and the fact that very often it was  difficult to capture user requirements accurately. 

Use cases:

(a) help to get communication going between domain representatives and developers and ensure that they can get to grips satisfactorily with what the system is to do. 

(b) also provides a way of planning iterative development.

 

 

Writing use cases is a way of dividing up the functionality of a system into manageable chunks. 

 

It’s best to define the term use case by first defining a scenario:

 

A scenario is a sequence of steps describing just one interaction between a user and a system. 

 

A use case is set of scenarios tied together by a common user goal. 

 

By just one interaction is means something like any one of the following five
* withdraw money from one's bank account,
* top-up one's mobile phone credit,
* submit lotto numbers to a machine,
* register in WIT,

* borrow a book from a particular library,

* buy a train ticket from a vending machine,

* check-in for a flight using a machine for that purpose
etc.

 

(In fact each of these, above,  is a complete use case, not just one scenario.  For instance buying a train ticket from a vending machine can involve either a credit card purchase or a cash purchase scenario.)

 

A scenario is an instance of a use case just as an object is an instance of a class. 
Or to put it another way, scenario is to use case as object is to class. 

 

Part 1: Using text to describe use cases. 

 

Use Case with Three Scenarios: PURCHASING GOOD ON-LINE:

 

Scenario 1: Purchase a number of items:

 

1. Customer browses through catalogue and selects items to buy.
2. Customer goes to checkout
3. Customer fills in delivery information
4. Systems presents full pricing information, including delivery
5. Customer fills in credit card information
6. System authorises purchase
7. System confirms sale immediately
8. System sends confirming email to customer

 

Scenario 2:  As above (1 to 8) but with the following modifications:

Alternative:  Authorisation Failure

At step 6, system fails to authorise credit purchase

Allows customer to re-enter credit card information and retry

 

Scenario 3: As above (1 to 8) but with the following modifications:

Alternative:  Regular Customer

3a System displays current shipping information, pricing information, and last four digits of credit card information

3b Customer may accept or override these defaults

Return to primary scenario at step 6

 

(The purpose of the underlining in point 1 will be discussed later.)

 

There is

(a)     a main success scenario (MSS), numbered 1 to 8,

(b)     one failure extension scenario (generically there are either none or else one or more of these) and

(c)     one alternative success scenario (generically there are either none or else one or more or these). 

There’s another example at http://homepage.eircom.net/~iandowney/procsl.htm

 

That’s the way most use cases are.  First your write out the MSS and then you brainstorm each step of the MSS to think out ways

(a) in which things can go wrong or,

(b) less commonly, alternative ways in which things can go right.  

 

There are many additional parts one can use when writing out use cases.  For example, some people add additional information to their description of a use case, such as pre-conditions; those are things that the system will ensure are satisfied before the use case begins.  There may also be sections for guarantees; those are things that are promised to be true after the use case ends.  There can be guarantees that are true only in event of success or ones that are true always. 

 

Advice as to what to include in a use case description can be found in big fat books on the topic and by attending conferences and workshops.  Professional developers choose only the details that work for their own type of projects and discard the rest. 

 

 User interface design is NOT part of use cases.  Use case design will, however, precede user interface design.  A use case describes the intent of the user, not the detailed mechanics of what he/she does.

 

It’s best to write too little for a use case, than too much.  One or two pages will usually do.  This is because other developers in your team won’t read them if they’re too long-winded.  If they’re a bit too short, then fellow-developers can ask you questions to fill in the details.  In any case, the details can be fleshed out just before a use case is written and the resulting code will serve as proof of whether the use case has been satisfactorily understood or not.  Although it's best not to write too much, what is written must be very perceptive and clear, not just waving one's hands about.  For example, everyone thinks they know how to use a vending machine, but there are subtleties that may be worth bringing out in a use case description if the use case is going to be of any real help in developing a system.

 

Note that the underlined portion in the use case description (see point 1 in blue text above) suggests an included use case (see <<include>> in the notes below).  This is how an included use case might be dealt with in a computerised system for representing the text of use cases.  The underlined segment would be a hyperlink. 

 

As mentioned at the top of this note, use case usage was publicised extensively to the developer world round about 1992 by Ivar Jacobson and others, in conferences and papers.  Since then developer proficiency in requirements capture has been greatly improved. 

 

The UML gives no advice about writing use cases.  All it does is to supply a technique of representing use cases diagrammatically.  These diagrams are entirely optional and they do little more than supply a sort-of graphical table of contents for the use cases that a system or sub-system contains.  It is important to emphasise this point:  writing use cases does not necessarily involve drawing any use case diagrams at all.  Indeed often use cases are described without such diagrams.

 

 

Part 2: Using use case diagrams (if, as a developer, you want or need to!)
 

Use case diagrams are not a useful way of describing use cases. Rather they provide a sort of graphical table of contents merely to support the textual or tabular description of a use case.  They are very much an optional extra.

 

There are a number of symbols used in use case diagrams.  They are described on the next page. 

 

Before I go on any further, I must stress that use case diagrams are ABSOLUTELY NOT about putting each of the numbered steps in a scenario into an equal number of bubbles and chaining these bubbles together with connecting arrows, and sticking a stick figure before the chain.  Quite apart that drawing such a diagram is NOT a use case diagram, it’s not necessary to draw a diagram like that.  The numbered steps in a scenario do that for you.

 

If you opt to draw use case diagrams you MUST learn EXACTLY how to use the symbols, otherwise you are not drawing use case diagrams, and so you might as well not bother.   

 

Some people draw what they think are use case diagrams but are, in fact, drawing activity diagrams, using the symbols for use case diagrams.  If you want to draw activity diagrams, by all means draw them, if you think they're helpful, but call them activity diagrams, and use the symbolism for activity diagrams.  

 

Activity diagrams and use case diagrams are entirely different, not just in symbols used but in meaning and intent.  Please don't confuse them.  If you don't yet know what activity diagrams are, then you'll see no reason why you might confuse them, but when you do learn about activity diagrams, then you must look out for that danger. 

 

I repeat, then that use case diagrams provide a graphical overview of what’s in the textual use case descriptions.  They have a limited but sometimes powerful use, just like other sorts of tables of contents.   If you don’t think that use case diagrams are worth drawing then don’t draw them!  There’s nothing wrong with the textual descriptions alone. 

Use Case Diagram Symbols:

 

1.  Symbol for an actor:

 

a stick figure.  This represents an actor, better described as role (there was a mistranslation from Swedish, the language in which use cases was first written about).  We're now, it seems, stuck with that mistranslation for ever.  The actor symbol should have a label underneath it with a description of the role that he/she/it plays in relation to the system:  for example, bank customer, interview short-lister, accounts system.  The actor is something that we are NOT modelling and so corresponds, perhaps, to the term external entity used in traditional modelling.  the actor does NOT have a white head; that's due to a mistake in using the graphics package.  Also don't draw a funny face in the stick figure however tempting it might be!

 

 

 

 

 

 

 

 

 

 

2.  Symbol for the use case itself:

 

Ovals.  These represent use cases and each should have a strong simple verbal statement placed inside it, such as open account, not effect account initialisation or some such.  Again, they actually have an interior colour the same as the background, unlike here!

 

Each oval represents an entire use case description of one or more scenarios, each scenario having numbered steps.  Thus logically at least half a page of A4 text fits inside! 

 

 

 

 

3.  Symbol for communication between an actor and a use case:

 

Straight lines.  These represent communication between actor (see above) and a use case. 

 

 

4.  Symbol for include or extend:

 

open-arrowed broken lines.  This is used to show the include or extends relationship between use cases.  Include is used where there is a chunk of functionality common among more than one use case or where it’s too unwieldy to be included in a base use case and so is spun off into a use case of its own.

 

 Extends is similar to generalisation (see below) but is more formal/more tightly defined than generalisation.  We won’t discuss extends in any more detail. 

 

5.  Symbol for generalisation:

 

A solid line with an open bounded arrow at the end.  This represents  generalisation and is drawn between two use cases or between two actors (see below).  The entity at the non-arrowed end of the line is a special case of the entity at the other end.  Its use is similar to the use of generalisation in class diagrams. 

Very simple, example of a use case diagram, illustrating how it can be regarded as a graphical table of contents:

 

 

Diagram 1

 

Note the use of a system boundary, with system title.  We model only what’s within the boundary.

Further Examples of Use Case Diagrams

 

This use diagram shows an actor (really meaning role) performing four possible use cases.  Notice that each use case starts with a strong verb:  open, deposit, withdraw and close.  This is preferred compared to something like effect a/c opening transaction etc.  Of course, one may have to show on the diagram the vocabulary used by the domain (e.g. banking, farming, fishing etc) and the domain may not necessarily use strong verbs.  The verbal phrase in each of the ovals becomes a series of numbered

steps, together with any alternative scenarios, also expressed that way.  See the blue text in the use case for purchasing good on-line in Part 1 above.

 

 

 

 

Diagram 2

 

 

The customer is represented with a stick figure and can either be a person or a non-human system.  We do not model the stick figures, although they may be modelled in some other system that is not our concern.  They are thus an external entity.  In general the stick figure should show the role that is played, not the job title.  Thus, in another possible example of a use case, a stick figure may be labelled job shortlister, and not human resources manager since we should reflect the precise role in the particular use case being played out.  A human resource manager will have many roles.

 

Another example of a use case is shown below.  Here Withdraw funds includes another use case, namely identify customer.  We use includes where there’s a chunk of functionality that is repeated across several use cases and so we spin it off into a separate one.  Sometimes it’s simply a chunk of functionality used only once but it’s considered clearer to un-clutter it from the base use case into a separate one. 

 

Withdraw funds over internet is a special case of withdraw funds.  The inheritance arrow points from the more specific/more usual/exceptional use case to the general. Even if internet transactions were to become the norm, we could still regard them, conceptually, as unusual. 

 

Another way of showing the relationship between these two use cases would be by converting the arrow into a broken line with an open arrow head,  and labelling it with the word  <<extends>> (there's an example of this later Diagram 6).     Note that  the inheritance (or <<extends>>) arrow always points towards the base use case, whereas the <<includes>> one points away.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 Diagram 3

Yet another example is shown below:

 

 

 

 

 

Diagram 4

 

The find book use case above means that the position of the book on the shelf is found, something that has to be done if the book is to be disposed of , or if the book is to be re-shelved.  Assistant librarians have three possible use cases to enact, whereas, library assistants, a lower rank, have only two. 

 

The use case above shows a library system.  Limits exceeded is a special case of borrowing a book.  In this case it’s a separate use case.  A different policy decision on behalf of the developers could have made it a separate scenario just as credit card failure was just one scenario of the purchase a product use case.  Limits exceeded simply means that the user currently has on loan a number of books equal to his/her borrowing quota and may borrow no more.  Notice that lending a book and disposing of a book both require locating the book.   

 

A use case diagram for a restaurant:

 

 

 

 

Diagram 5

 

Study this use case diagram and see if you can suggest any changes.

Part 3: Discovering Use Cases

 

Many use cases may exist in a particular system.  The problem is discovering them all.  One handy knack for doing this is to consider all the actors that interact with the system.  Once you’ve considered them, you can think about all the use cases that they’re likely to be involved in. 

 

Another technique is to consider all the events to which your system is likely to have to react.  Sometimes an event requires a response from the system that doesn’t involve any actor but quite often some actor is involved in responding.  That means that you’ve discovered another use case. 

 

A third method is to do conceptual modelling (using predominately conceptual class diagrams-see class diagram notes on this site) with the domain people at the same time as one is trying to discover use cases.  The act of thinking about the system conceptually can cause use cases to be discovered.

 

 

Part 4: Business use cases and system use cases

 

Sometimes focussing on use cases can prevent one seeing new ways in which an organisation can be run.  Perhaps there are new and different ways for actors to achieve their goals. 

 

Considering business use cases helps to achieve a more radical change to an organisation’s practices, perhaps at the same time as re-computerisation is taking place.  Rather than replace an old computer system with a new one that does more or less what the old one did, it may be worth reflecting on the whole manner in which the organisation goes about its business. 

 

A business use case focuses more on how a business responds to the needs of its customers and to events, whereas a system use case is more about how a user interacts with a piece of software.  Some developers have found themselves developing a number of business use cases and then for each business use case, a number of system use cases.

 

An example of how a new business use case might occur would be if a supermarket were replacing its staff-operated customer check-out equipment.  Rather than documenting how the existing system works (and perhaps making slight improvements), one might stand back and consider the possibility of customer-operated check-outs in addition to ones where a staff member carries out the checking-out activities.  (For an example of the two types of check-outs, see the systems in operation at Tesco Ardkeen in Waterford City.)

 

 

Part 5: End of chapter exercises

 

 

1.  Consider, in relation to an ATM,  the use case withdraw cash.  In addition to the MSS, what alternative scenarios are there that will need to be fleshed out in a sequence of steps? (Answer below)

 

2.  Consider the following use case diagram.  Explain what it shows. 

 

 

Diagram 6
 

Hint:  the difference between generalisation (indicated by a solid line with an closed white arrow at its end) and extend (indicated by a broken line with a open arrow at its end and the text <extend>> beside it) can largely be ignored.  There is a subtle difference between the two, but for the most case you can treat them as the same thing, if you see them on someone’s use case diagram.  Thus we can regard the enrol senior citizen in university and perform security check use cases as having (more or less) the same relationship to the enrol student in university use case.

 

If you’re drawing your own use case diagrams, I suggest you stick to one or the other, and ignore the subtle difference between them, at least for a few years.  Each is designed to indicate a variant on normal behaviour, a deviation from the norm. 

 

 

An answer to Question 1 above:

 

Some alternative scenarios are:

 

• The customer’s card is not recognised and rejected.
• The customer enters the wrong PIN and is asked to re-enter it
• The customer enters the wrong PIN three times and the card is retained by the ATM.
• The customer enters an invalid figure for the amount of cash.
• The ATM attempts to connect to the bank’s main system, but it is out of action or there is a network failure, so it cannot connect.
• The ATM doesn’t have enough cash to meet the customer’s request.
• The customer’s account does not have enough funds to meet the request.
• The customer cancels the transaction part way through. 

 

Each of these would have to be spelled out in a sequence of steps.