CSC/ECE 517 Fall 2010/ch4 4a RJ

Use Cases

Introduction

Use cases can be defined in many ways. There are many formal definitions for it. Very simply put, a use case is a reason to use a system. For example, a student borrowing a book from a library would be a use case of the library or a bank cardholder might need to use an ATM to get cash out of their account. More formally, “a use case is a collection of possible sequences of interactions between the system under discussion and its Users (or Actors), relating to a particular goal” [1].

A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. The system is treated as a "black box", and the interactions with system, including system responses, are as perceived from outside the system.

Use Case Basics

"Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system."[2]

Terms used with Use cases

Now let us define some terms used with use cases: [3]

1. Actor: An actor is a type of user that interacts with the system (ex student borrowing book or cardholder using ATM). Actors are also external entities (people or other systems) who interact with the system to achieve a desired goal. The goal must be of value to the actor.
2. Goal: Without a goal a use case is useless. There is no need for a use case when there is no need for any actor to achieve a goal. A goal briefly describes what the user intends to achieve with this use case. For example, the goal of a student using the library is to obtain the book. There is no point in having a use case like “the student enters the library” as that in itself has no value to the actor.
3. Stakeholder: A stakeholder is an individual or department that is affected by the outcome of the use case. Individuals are usually agents of the organization or department for which the use case is being created. A stakeholder might be called on to provide input, feedback, or authorization for the use case. The stakeholder section of the use case can include a brief description of which of these functions the stakeholder is assigned to fulfill.
4. Trigger: A trigger describes the event that causes the use case to be initiated. This event can be external or internal. If the trigger is not a simple true "event" (e.g., the customer presses a button), but instead "when a set of conditions are met", there will need to be a triggering process that continually (or periodically) runs to test whether the "trigger conditions" are met: the "triggering event" is a signal from the trigger process that the conditions are now met. In our example with the student, a trigger would be the need for the book due to an approaching exam or test which causes the student to go to the library to borrow a book.
5. Precondition: A precondition defines all the conditions that must be true (i.e., describes the state of the system) for the trigger to meaningfully cause the initiation of the use case. That is, if the system is not in the state described in the preconditions, the behavior of the use case is indeterminate. For example, the student should be a member of the library and have the required identity to borrow a book. If the student is not a member of the library, there is no point in the student trying to borrow a book from that library.
6. Scenarios: A scenario usually specifies when the use case starts and ends. It describes the interaction with actors and shows the flow of events between a user and system. For example, when a student tries to borrow a particular book from the library, it doesn’t always necessarily turn out the same way. Sometimes the book is available and sometimes it is already borrowed by someone else or the library may not have a given book. These are all examples of use case scenarios. The outcome in each case if different depending on circumstances, but they all relate to the same goal that is, they are all triggered by the same need(in this case, need for the book) and all the scenarios have the same starting point.

Simple Example

Now that we know something about use cases, let us go ahead and describe a simple use case:

Use Case 1: Request book from the library (automated system).

1.1: Summary/Goal
  To borrow book a particular book from the library

1.2: Actors
  Student

1.3: Preconditions
  Student should be a member of the library and have an id.

1.4: Main Path
  System requests for student ID and checks if he/she is a member
  Student selects “request book”
  Student enters name(s) of the book(s)
  System checks for availability of books and displays results accordingly
  Student confirms the order
  System displays details of where the requested books are stacked

1.5: Alternate Path
  System does not recognize Id or student is not a member. System will not allow any books to be checked out.
  All books requested are already checked out. Displays this information to student and closes request.

Important Characteristics of Use Cases

The above description shows a very simple use case. However, there are a few essential characteristics to be noticed about the use case:

1. We have identified the key components of a use case, that is, the goal, actors, preconditions, key scenarios/flow and preconditions. It is very essential that we identify these components before writing a use case.
2. We have not gone into any sort of technical details about implementation or user interface design. Use cases only represent a very high level design. We are only trying to understand the flow and uses of the system.
3. We have recorded a set of paths (scenarios) that traverse an actor from a trigger event (start of the use case) to the goal (success scenarios).
4. We have recorded a set of scenarios that traverse an actor from a trigger event toward a goal but fall short of the goal (failure scenarios).

Where can we use ‘use cases’?

1. Use cases are usually used to capture the requirements of an interaction based system. When there is a lot of interaction between actors and the system, it makes sense to capture as many interactions and scenarios possible before starting development of the system.
2. Use cases help to eliminate rework due to requirements misunderstandings between developers and stakeholders by aiming to reach a point where there are no surprises for the users. Use cases help to build an explicit shared understanding that everyone can take away with them, the users, developers, testers, technical authors, and others.
3. Use cases have received some interest as a starting point for test design. By analyzing use cases for the system, we can know various interactions between the system and actors which will help in drawing out test plans.

Where can’t we use ‘use cases’?

[ http://en.wikipedia.org/wiki/Use_case]

1. Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
2. Some systems are better described in an information/data-driven approach than in a functionality-driven approach of use cases. A good example of this kind of system is data-mining systems used for Business Intelligence. If you were to describe this kind of system in a use case model, it would be quite small and uninteresting (there are not many different functions here) but the set of data that the system handles may nevertheless be large and rich in details.

Common mistakes while writing Use cases:

1. The system boundary is undefined or inconstant. A system boundary is a boundary that separates the internal components of a system from external entities. If we are not able to identify the system boundaries, we will not be able to clearly define the actors, scenarios and other essential factors involved in writing a good and useful use case. For example, the system described in the library example, has a clear boundary. It is used to accept inputs as book names, checks the id and provides a location for the books. We know its role very clearly. Suppose the system was used to manage everything like security, employee details etc, we will not be able to identify the goal, actors and scenarios very clearly.
2. Use cases should not be used to capture all the details of a system. The granularity to which you define use cases in a diagram should be enough to keep the use case diagram uncluttered and readable, yet, be complete without missing significant aspects of the required functionality.
3. The use cases are written from the system’s (not the actors’) point of view. Use cases written from a system point of view will make the writer have the tendency to get into technical details. If we wrote the example test case above from the systems point of view, we would have statements like “obtain location of book from database and display location of books to user”. This is more detail than necessary. Also, this would not capture the interaction with the actor very clearly. Use cases also give a brief insight into how the UI should look but when written from the system these details might not be captured clearly.

Writing Use Cases

Writing Use Cases for a system is a process taken between those designing the system and the Stakeholders. Use Cases can take many different forms, depending on the type of development process being used [4]. The format that a Use Case takes is not as important as the process that it goes through [5].

Iterative Process

Normally, this process is done iteratively, so that the iterations can build upon each other [6]. Below is an example of three iterations of the Use Case writing process to illustrate how it can reveal things about a system and layout the functional requirements.

For this example, we will be creating Use Cases to solve the following problem statement:

Develop a system to allow users to schedule meetings with each other.

In this system, the stakeholders will be the users of the system. The Users will also be the only Actors in the system.

Iteration 1

For the first iteration, we will write out short sentences to describe the functionality that the system will have. Some use cases could be:

Use Case #	Description	Actor
1	Request a Meeting	User
2	Approve a meeting request	User
3	Suggest a new time	User
4	View a User's schedule	User

In this example, the fourth Use Case may not have been an obvious requirement that could be derived from the original problem statement, but in the process of creating the Use Cases, it was discovered that it would be a good requirement for the system to have.

Iteration 2

The next iteration would involve writing out longer descriptions for each. This could be done in paragraph form, or by writing a list. Below are the Use Cases in paragraph form:

Use Case 1 – Request a meeting
User A chooses the date and time for a meeting with User B.  User A chooses User B as the recipient of the meeting request.
User A sends the meeting request to User B through the system.

Use Case 2 – Approve a Meeting Request
User A receives a meeting request from User B and accepts the user request.  A notification that User A has accepted the meeting is sent to User B.

Use Case 3 – Suggest a different meeting time
User A receives a meeting request from User B and suggests a different time and/or date for the meeting.  The response is sent to User B through 
the system.

Use Case 4 – View a User's schedule
User A would like to schedule a meeting with User B.  User A starts the system and opens up User B's schedule.  
User A can see when User B has already scheduled  meetings and User A can then use that information to send User B a meeting request.
Use A can also access their own schedule to view when User A has scheduled meetings.

From writing out the Use Cases with more description, it should become clear that Use Case 2 and Use Case 3 are very similar. In both Use Cases, User A responds to a meeting request and a response/notification is sent to User B. This might lead the designers of the system to combine these two Use Cases into one Use Case for "Respond to Request."

Iteration 3

In the next iteration, we're going to use a Use Case template. There are many different Use Case templates, which include different information [SOURCES]. A template can be created that is unique for the system being described, provided each Use Case uses the same template. The template we will use will include:

Use Case <Number>: Title

<Number>.1: <Summary/Goal>

<Number>.2: <Actors>

<Number>.3: <Preconditions>

<Number>.4: <Main Path>

<Number>.5: <Alternate Paths – including sub-flows [S] and error-flows [E]>

Writing Use Case 1 in this format yields:

Use Case 1: Request a meeting

1.1: Summary/Goal
User A can choose the date and time for a meeting with User B [Main].  User A can choose User 	B as the recipient of the meeting 
request [Main], or multiple Users as the recipient [S.2].  User A sends the meeting request to User B through the system [Main]. 
Before User A sends the meeting request, User A can opt not to send the request and delete it [S.1]. If User B is no longer in 
the system, User A receives notification that the meeting request cannot be sent [E.1].

1.2: Actors
Users

1.3: Preconditions
- User A and User B are recorded as Users in the system
- User A has logged into the system

1.4: Main Path
1) User A chooses a date for a meeting
2) User A chooses a time for a meeting
3) User A chooses User B as the recipient for the meeting request
4) User A submits the meeting request
5) User B receives the meeting request the next time User B logs into the system

1.5: Alternative Path
S.1 
User A creates a meeting request, but down not submit it.  A meeting request is not sent to User B

S.2
User A creates a meeting request for more than one User.  User A submits the meeting request and each User receives it the next
time they log in

E.1
User B is no longer a User in the system.  User A receives notification that the meeting request cannot be sent.

Results

There are a few interesting things revealed about the system by re-writing the Use Case in this format. The most important is likely that Users will need to "log-in" to the system. This implies that there could be another Actor in the system, namely an Admin. This leads to these additional Use Cases:

Use Case #	Description	Actor
5	Log into the system	User
6	Create a User in the system	Admin

Each of these new Use Cases would then go through the iterations listed above until they are in the template form.

As you can see from the example, each iteration refines the Use Case and helps to clarify the requirements of the system.

Use Case Diagrams

Use Case Diagrams are useful for showing how each component in a system will interact with other components of the system [7]. They are not good for showing the flow of events that a system will have, like the written Use Cases are [8]. Also, unlike written Use Cases, Use Case Diagrams use UML so that there is a standard. UML is a standardized modeling language for software development.

Components of a Use Case Diagram

"UCDs have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements."[9]

Actors in Use Case Diagrams are represented by stick figures:

Use Cases are represented by ovals:

Relationships are represented by Solid Lines. Sometimes, arrowheads are added to the lines to indicate the direction of the invocation, or to show which actor is the primary actor [10]

Two special relationships that can be shown in a Use Case Diagram are the Extends and Includes relationships. These relationships are usually shown with a dotted line with an arrowhead and <<extend>> or <<include>> written near the line.

The Extends relationship is used to show when Use Case X is a special case of Use Case Y [SOURCE]. In this situation, the dotted line is drawn from Use Case X to Use Case Y with the arrowhead pointing to Use Case Y.

The Includes/Uses relationship is used to show that every time Use Case X is done, Use Case Y must also be done [SOURCE]. In this case, the arrow points to Use Case Y.

Creating a Use Case Diagram

A Use Case Diagram for the same system described in the Writing a Use Case might look something like:

As you can see, "Accept Meeting" and "Suggest new time" are special cases of "Respond to request". Also, from this diagram, the system designers are saying that in order to "Request a Meeting" the user must "View Schedule".

Advanced Topics

Essential Use Cases Vs System Use cases

[11]

Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The difference between these is the scope.

• A business use case is described in technology-free terminology which treats system as a black box and describes the business process that is used by its business actors (people or systems external to the process) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate). The business use case will describe a process that provides value to the business actor, and it describes what the process does. Business Process Mapping is another method for this level of business description. A significant advantage of essential use cases is that they enable you to stand back and ask fundamental questions like "what's really going on" and "what do we really need to do" without letting implementation decisions get in the way. These questions often lead to critical realizations that allow you to rethink, or reengineer if you prefer that term, aspects of the overall business process. A Very good example of essential use case can be seen in this link: http://www.agilemodeling.com/artifacts/essentialUseCase.htm
• A system use case describes a system that automates a business use case or process. It is normally described at the system functionality level (for example, "create voucher") and specifies the function or the service that the system provides for the actor. The system use case details what the system will do in response to an actor's actions. For this reason it is recommended that system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher). An actor can be a human user or another system/subsystem interacting with the system being defined

Pluggable Use Cases:

[12]

Use cases describe various scenarios and sequence of operations to achieve a given goal between actors and systems. We have seen that we can write Use Cases in various styles with varying degrees of details, varying aims and for varying audience in terms of business and System use cases. Business use cases are very readable with very little technical content so that stakeholders and business managers can understand the system as a black box. This may not work with the developers. They would like to see more technical details and have use cases that describe fully what a system must do under all circumstances.

It has been seen through experience that there is some amount of common behavior that is replicated in many business use cases. By extracting these common processing details (e.g. create, read, update, delete, etc), the contents of use cases can be reduced. These common processing details can be put into what is called lower level pluggable use cases. Essentially, we are creating various levels of use cases. At the highest level, what we can call as the main use case shows the more fundamental processing steps with the names of the pluggable use cases 'plugged' in-between. This helps abstracting out lower level details and keeping the use cases more simple. What this also does is, business managers and stake holders can see the higher level use case which still remains simple and readable whereas the lower level details which are of interest to developers is not lost either. These use case levels provides the freedom of reading at various degrees of granularity.

Pluggable use cases have to be written in a generic form so that it can be used wherever needed. It should be generic enough that it can be plugged into other use cases. All the rules of a regular use cases still apply in terms of finding goals(which are essentially sub goals of the system), actors etc. Pluggable use cases can be produced in a way where their content is the same for all transactions, that is, it is common to various scenarios and projects. The difference in each project or scenario is mainly the data they handle and the sequence of activities being performed. The unique data and rules of each scenario are separated and documented independently in "Companion Tables" from the process steps which enable flexibility and maximum reuse.

Thus pluggable use cases become building blocks for higher level use cases. They are organized and applied within each use case to reach its goals. Whenever a pluggable use case is invoked, the invocation references the companion table that provides the unique data and rules for that use case. They are most effective when they are used in conjunction with these tables.

Use case content is dependent on the requirements of the system under design. This is also true for pluggable use cases. While the majority of pluggable use case content can be used verbatim across any project or company, minor customizations may be needed to accommodate the individual needs of the project and company.

Some use case sequences are simple while others are complex. To manage degrees of complexity, a use case can exercise one, multiple or a series of pluggable use cases wherever desired and in any order. To maximize use case cohesion and increase reusability a pluggable use case may employ another pluggable use case. The versatility of pluggable use cases provides a solid foundation for the construction of project use cases.

The following link has excellent examples of how pluggable use cases can be written and used http://alistair.cockburn.us/Pluggable+use+cases

Tools and Examples

Tools

There are many different tools available to create Use Cases. For a more comprehensive list, go to Wikipedia's list of UML modeling tools. A sampling are below:

• Rational Rose: One of the most popular tool for use-case driven development. http://www-306.ibm.com/software/awdtools/developer/rose/index.html
• Sun Java Studio Enterprise: Sun Java Studio Enterprise offers a UML tool. http://developers.sun.com/jsenterprise/
• Visual case: UML & E/R Database Design Tool http://www.visualcase.com/

Examples

There are many different examples of Use Cases. Some are listed below:

• http://www.objectmentor.com/resources/articles/usecases.pdf
• http://www.w3.org/2002/06/ws-example
• http://www.agilemodeling.com/essays/useCaseReuse.htm
• http://www.soi.wide.ad.jp/class/20040034/slides/07/9.html
• http://www.cs.colorado.edu/~kena/classes/6448/s05/reference/usecases/examples.html
• http://courses.softlab.ntua.gr/softeng/Tutorials/UML-Use-Cases.pdf