CSC/ECE 517 Fall 2010/ch4 4a RJ

From Expertiza_Wiki
Jump to navigation Jump to search

Use Cases

Introduction

Use Case Basics

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 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.

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.

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. There are many different ways to write Use Cases [SOURCE]. Because of this, there are many different formats that Use Cases can take when they are written. There are, however, certain guidelines that should be followed in the process of writing Use Cases. In general, these guidelines are:

  1. Never include implementation specific terminology in the Use Case [SOURCE]
  2. Each Use Case should be a set of scenarios, which include different flows of events [SOURCE]

Iterative Process

Normally, this process is done iteratively, so that the iterations can build upon each other [SOURCE]. 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 [SOURCE]. They are not good for showing the flow of events that a system will have, like the written Use Cases are [SOURCE]. Also, unlike written Use Cases, Use Case Diagrams use UML so that there is a standard.

DEFINE UML HERE

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.[SOURCE: http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html#uses – DIRECT QUOTE]

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 [SOURCE: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm]

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

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:

Examples

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

Further Reading

References

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch4_4a_RJ&oldid=38840"