Use Case Forms

2.0 Use Case Form

A Use Case Form is used to describe a Single Use Case. Thus, EVERY Use Case should have a Use Case Form. There is no one correct Use Case Form format - but most formats/content are quite similar. A Use Case Form Template is available on GCULearn (Slightly different to the Use Case Form in UML@Classroom).

A use case is a dialogue between actor(s) and system. An actor appears, interacts, goes away and the use case documentation defines what the system must do. This Documentation is a text generic description covering lots of examples of what happens within a Use Case. Each example is a scenario, where a scenario is a specific example of an actor using the system. Between them, the Main Flow & Alternative Flows describes ALL the possible scenario paths within a Use Case. Therefore, a use case describes all the possible scenario paths e.g. what happens if the bank customer has enough money in his account, what happens if he has not, etc. A use case should be written at the level slightly above scenarios.

The Main Flow of Events is the normal sequence of events written in terms of what the system should do. The normal flow is the basic flow when everything goes smoothly and there are NO complications (e.g. scenario 1 in the ‘Borrow Book’ Example below). This is written as a list in normal language. The Alternative Flow Of Events are exceptions to the normal flow. These are alterative paths to deal with errors, different circumstances etc.

Use Case Name	MUST match Use Case Diagram!!!
Description	Brief description that states the purpose of the use case in a couple of sentences
Actors	Which actors interact with the use case
Pre-conditions	What has to occur before the use case starts
Trigger	What triggers the use case
Main Flow of Events	The normal sequence of events When everything goes smoothly -> NO complications Written as a list in normal language.
Alternative flow of Events	Exceptions to the normal flow. These are alternative paths to deal with errors. different circumstances etc.
Post-condition	What occurs after the use case ends
Issues	Any special issues with this use case not mentioned in any of the rows above

2.1 Example - 'Borrow Book'

Possible Scenarios from a library system, the Use Case is ‘Borrow Book’. This is the ‘normal’ Main Flow of events:

Use case begins when borrower brings a book to the librarian and asks to take it out. The librarian asks for the borrower’s library card. Using the library card, the librarian checks that the borrower does not already have his full quota of books on loan, and finds that the borrower has no other books on loan. The librarian checks that the book is available for loan and can be borrowed. The librarian swipes the book’s bar code, stamps the book with the return date and hands the book to the borrower.

These scenarios include possible Alternative Flow of events

Borrow Copy of Book - Scenario 2

Use case begins when borrower brings a book to the librarian and asks to take it out. The librarian asks for the borrower’s library card. The borrower says he does not have a card, but would like to join the library. The librarian asks him to fill in an application form, and show identification. This the borrower does to the librarian’s satisfaction. The librarian checks that the borrower does not already have a library card. He does not. The librarian makes up a new library card for the borrower. The librarian checks that the book is available for loan, and can be borrowed. The librarian swipes the book’s bar code, stamps the book with the return date and hands the book to the borrower.

Borrow Copy of Book - Scenario 3

Use case begins when borrower brings a book to the librarian and asks to take it out. The librarian asks for the borrower’s library card. Using the library card, the librarian checks that the borrower does not already have his full quota of books on loan, and finds that the borrower has no other books on loan. If the borrower already has a full quota of books on loan, then they cannot borrow the book. The librarian checks that the book is available for loan, and finds that it is for reference in the library only. The librarian takes the book from the borrower saying that she’ll return it to the shelf. End of use case.

Analysing Information:

It is very important that when you are analysing how a system works that you fully understand it. The system description can be VERY detailed, thus, to understand the system, you should break it down into smaller sections/areas and understand each one individually. In the Scenarios in the previous slides, they are all written in a single paragraph. This makes both the reading and the understanding of each scenario difficult to understand. Let’s look at the scenarios again, by splitting it into separate sections (paragraphs) making it easier to read and understand.

2.2 Possible Scenarios (with paragraphs):

Borrow Copy of Book - Scenario 1 (main, or “happy”, flow)

Use case begins when borrower brings a book to the librarian and asks to take it out. The librarian asks for the borrower’s library card.

Using the library card, the librarian checks that the borrower does not already have his full quota of books on loan, and finds that the borrower has no other books on loan.

The librarian checks that the book is available for loan, and finds that it can be borrowed.

The librarian swipes the book’s bar code, stamps the book with the return date and hands the book to the borrower.

Borrow Copy of Book - Scenario 2 (with paragraphs)

Use case begins when borrower brings a book to the librarian and asks to take it out. The librarian asks for the borrower’s library card.

The borrower says he does not have a card, but would like to join the library. The librarian asks him to fill in an application form, and show identification. This the borrower does to the librarian’s satisfaction. [A1]

The librarian checks that the borrower does not already have a library card. He does not. The librarian makes up a new library card for the borrower.

The librarian checks that the book is available for loan, and finds that it can be borrowed.

The librarian swipes the book’s bar code, stamps the book with the return date and hands the book to the borrower.

Borrow Copy of Book - Scenario 3 (with paragraphs)

Use case begins when borrower brings a book to the librarian and asks to take it out. The librarian asks for the borrower’s library card.

Using the library card, the librarian checks that the borrower does not already have his full quota of books on loan, and finds that the borrower has no other books on loan. If the borrower already has a full quota of books on loan, then they cannot borrow the book [A2]

The librarian checks that the book is available for loan, and finds that it is for reference in the library only. [A3]

The librarian takes the book from the borrower saying that she’ll return it to the shelf.

Use Case Form for the “Borrow Copy of Book” use case:

Use Case Name	Borrow Copy of Book
Description	The librarian facilitates the borrowing of a book from the library.
Actors	Librarian
Pre-condtions	Library books must be added to the system
Trigger	Borrowers ask to borrow book
Main Flow of Events	1. Librarian swipes the borrower's library card. [A1] 2. Librarian checks that the borrower does not already have his full quota of books on loan. [A2] 3. Librarian swipes the books bar code. 4. Librarian checks that the book is available for loan. [A3] 5. Librarian stamps the book with the return date and hands the book to the borrower.
Alternative Flow of Events	A1. Borrower is not a library member. Librarian adds borrower as new member (E. "Add new Member"). Return to step 1. A2. Borrower has full quota of books out already. End of use case. A3. Book is not available for loan. End of use case.
Post-condition	New loan added. Book is recorded as out on loan.
Issues

Look at the above example again in your own time make sure you understand the use of Main Flows AND Alternative flows.

2.3 Purpose of Use Case Diagrams

Scope describes the range of a system; what’s inside and what’s outside, what it does and what it doesn’t do. Where scope is not stated users and developers may well have differing interpretations. Badly chosen or misunderstood scope is a major cause of dissatisfied users and frustrated developers. It’s vital that the system scope is understood by all parties

Software has users (humans or machines). These users are called actors, and actors are outside the system. Users (actors) use software to perform activities or accomplish goals. These activities are known as use cases:

Use Cases drive the design of the system

Use Cases capture the functional requirements of the system

Use Cases form part of the specifications of a system

Originally Ivar Jacobson used the terms usage scenarios and usage case, which were the more correct translations of the Swedish word "användningsfall" he used, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case.

A Use Case diagram provides a visual representation of the functional requirements. The diagram is often easier to interpret for the client stakeholders than the actual specification document. A Use Case diagram provides a high-level view of the entire system. This view can be the basis for a common language between the client stakeholders and the development team. The system’s Use Cases form the basis for all future development. A Use Case diagram shows the scope of the system.

A use case captures the system behaviour as it responds to a request from an actor. The actor is known as the primary actor and it initiates an interaction with the system in order to achieve some goal. In a library system we could have the Use Cases which include: Borrow Book, Add New Member, Update Member Details, etc. In brief, The Use Case Diagram provides a high level view of system functionality from the user’s perspective. A Use Case is an activity the system performs, usually in response to a request by a user (Actor). Actors are external and Use Cases are internal, this is signified by a system boundary, a Use Case MUST have a system boundary. This is represented by a box:

Each Use Case is an interaction (or a sequence of interactions) between a user and the system. It achieves a discrete goal for the user. Collectively the Use Cases define the system requirements. These requirements will form the basis of system design.

An Actor is anything outside the system to which the system interfaces:

Person or thing e.g.

Users

Groups of users

Other systems

Machines

Devices

Actors are users of the system, they identify those people who will physically use the system and identify what interaction occurs between them and the system. They may also be other computer systems/equipment that directly interfaces with the system. The actors define the systems boundary, usually at the software level but it could be at the business process level. An actor represents a role, not a person; think of a ‘job title’. A single actor may represent a number of different users if they interact with the system in the same way. A single actor may be associated with many use cases and a use case may have several actors.

An Actor is connected to a Use Case using Associations. An association specifies that the Actor communicates with the System and uses certain functionality. Every actor must communicate with at least one Use Case.
2.4 Example (Library System)

A Member can borrow a book by giving the book and library card to the librarian who will then enter the details into the Library system. The Member can also update their details by giving the Librarian their library card and their updated details (e.g. new address):

Defining a good use case:

1. Choose a good name

2. Illustrate a complete behaviour

3. Identify a complete-able behaviour

4. Provide “inverse” use cases

5. Limit each use case to one behaviour

6. Represent the actor’s point of view

1. Choose a good name:

A use case is a behaviour, so you should name it with a verb phrase. To make it more precise, you should add a noun to the name to indicate the class of objects that the action effects. Look at a possible good name for your use case, by examining the name of the relationships of the actor to the system’s objects – e.g. Book Hotel

2. Illustrate a complete behaviour:

A use case must be a complete behaviour that starts with the initiating event from the primary actor and ends with the actor normally reaching his/her goal. If a proposed use case is only a step along the way to the goal, don’t treat it as a use case unless you can consider it a goal in itself. For example, Specify the Hotel Name is an activity that you have to perform to book a Hotel— but it’s only a part of the Book Hotel use case because it never really stands alone and doesn’t (by itself) return a useful result.

3. Identify a complete-able behaviour:

To achieve a goal and produce value for an actor, the use case must complete. When you name the use case, choose a verb phrase form that implies completion or ending. For example, use Book Hotel, rather than Booking a Hotel, because the “ing” describes an ongoing behaviour.

4. Provide “inverse” use cases:

Whenever you see a use case that accomplishes a goal that is to change a state in the system, you probably need a use case to un-accomplish that goal. For example, the use case Book Hotel is undone with Cancel Hotel Booking. Use cases that just obtain information don’t need an undo. (For example, you don’t need an undo for Check Hotel Availability.)

5. Limit each use case to one behaviour:

Sometimes you might be tempted to have a use case achieve more than one goal or do more than one activity. To avoid confusion, keep the use case focused on only one thing. For example, the potential use case Book Hotel AND Hire Car is unfocused; it attempts to describe two different behaviours. If a proposed use-case name has an ‘AND’ or an ‘OR’ in the name, it’s probably too unfocused to be one activity.

6. Represent the actor’s point of view:

Write the use case from the actor’s point of view, using the terminology of the actor, not that of the system. For example, you would allow a Customer to use the system to help Book Hotel (using common Customer terminology), but you would not name that use case Schedule Customer Hotel Allocation, because that’s the Travel Agent’s terminology and not the Customer’s.
2.5 Relationships that can be used to connect Use Cases

The following Relationships can be used: (UML@Clasroom - chapter 3.5 )

Include

Extend

Generalisation between Use Cases

Generalisation between Actors (chapter 3.4 )

“Include” Relationship:

It’s not unusual to find that more than one use case, in a system, contain the same piece of functionality. The use cases are not the same, but there is a part that is common to others, e.g. in a shop order system the “Process Order” and “Process Item return” would BOTH include the “production of a Invoice”. To avoid redundancy and enhance reuse a common sequence of events can be abstracted out of a number of similar use cases and placed in a new use case. The Original use case is the ‘base’ use case.

We use ‘include’ relationships to model relationships between use cases in which a base use case instance will ALWAYS include the behaviour specified by a common use case. ‘include’ relationships are used to share common behaviour among use cases. They are denoted by an open arrows with a dashed line pointing AWAY from the base Use Case. The keyword <<include>> is written in guillemets alongside the relationship arrow.

When an Order is processed or an item is returned - and invoice is ALWAYS produced

‘Extend’ Relationship:

We use ‘extend’ relationships to model relationships between use cases in which a base use case instance MAY include the behaviour specified by an extending use case, subject to conditions specified in the extends relationship. Used to capture exceptional behaviour or variation from normal behaviour. Model occasions where one use case may optionally be extended by the functionality in another use case. They are denoted by an open arrows with dashed line pointing TOWARDS the base Use Case that is being extended. The keyword <<extend>> is written in guillemets alongside the relationship arrow.

When an Order is processed or an item is returned - an invoice is ALWAYS produced. In certain circumstances, it MAY be neccessary to order an item from Supplier

Some Rules (general, not absolute):

Use include when some common function /activity is being carried out in two or more separate use cases.

Use extend when you are describing a variation on normal behaviour, and that variation is being carried out by more than one separate use cases or the variation involves interaction with another actor.

Very generally speaking, you would only show 2 use cases linked in a use case diagram if both of them were also linked to other use cases and/or to separate actors

Remember, the Use Case Diagram is a High-Level view of the system. Keep Use Case diagrams as simple as possible and do NOT overuse ‘include’ and ‘extend’ relationships.

Another example: include and extend

Note Direction of Arrows !!!
2.6 Use Case Generalisation:

Sometimes there may be different versions of the same use case. There is the general case, then specialisations of this use case. This is similar to the idea of inheritance in classes. This can be represented in a diagram using the Generalisation association, which is drawn using an arrow with a triangular unfilled arrowhead.

The generalisation relationship between use cases lets us capture the functional requirements of a complex system using layers of abstraction. We can describe a use case at an abstract or general level before supplying more concrete or special descriptions.

Consider the “Update Member Details ” use case from the library system. It may be that a Member can update their details on line or at the library:

There can also be generalisation between actors. One actor being a specialised form of another. The specialised form can do everything the general actor can do, and more. Consider the following system:

A manager is responsible for a department and must review the staff in that department each year.

The manager is also responsible for ordering new equipment and furniture.

From time to time the Manager of Department A (one of the managers) must also recruit additional staff. This involves placing advertisements and keeping track of all applicants up to the closing date
2.7 Best Practices - from UML@Classroom

Use case diagrams do NOT model processes/workflows!

Actors are NOT part of the system, hence, they are positioned outside the system boundaries!

Many small use cases that have the same objective may be grouped to form ONE use case

The various steps are part of the use cases

NOT separate use cases themselves!

NO functional decomposition

The Use Case Diagram is a High-level view of the system

Keep Use Case Diagrams as simple as possible

Do NOT overuse 'include' and 'extend'

Each Use Case should be a MAJOR function/task

Each Use Case will be defined in detail later

using Use Case Forms and Activity Diagrams

So no need for details in Use Case Diagram

Major functions/Task only!!!