CSC/ECE 517 Fall 2010/ch4 4a RJ

Use Cases

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]

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.

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.

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

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.

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.