CSC/ECE 517 Fall 2010/ch4 4a RJ: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
= Use Cases = | = Use Cases = | ||
== Introduction == | == Introduction == | ||
== Use Case Basics == | == Use Case Basics == | ||
== Writing Use Cases == | == Writing Use Cases == | ||
<p>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:</p> | |||
<ol> | |||
<li>Never include implementation specific terminology in the Use Case [SOURCE]</li> | |||
<li>Each Use Case should be a set of scenarios, which include different flows of events [SOURCE]</li> | |||
</ol> | |||
<p>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. </p> | |||
<p>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. </p> | |||
<p>For the first iteration, we will write out short sentences to describe the functionality that the system will have. Some use cases could be:</p> | |||
<table> | |||
<tr> | |||
<td>Use Case #</td> | |||
<td>Description</td> | |||
<td>Actor</td> | |||
</tr> | |||
<tr> | |||
<td>1</td> | |||
<td>Request a Meeting</td> | |||
<td>User</td> | |||
</tr> | |||
<tr> | |||
<td>2</td> | |||
<td>Approve a meeting request</td> | |||
<td>User</td> | |||
</tr> | |||
<tr> | |||
<td>3</td> | |||
<td>Suggest a new time</td> | |||
<td>User</td> | |||
</tr> | |||
<tr> | |||
<td>4</td> | |||
<td>View a User's schedule</td> | |||
<td>User</td> | |||
</tr> | |||
</table> | |||
== Use Case Diagrams == | == Use Case Diagrams == | ||
== Advanced Topics == | == Advanced Topics == | ||
Revision as of 22:47, 19 October 2010
Use Cases
Introduction
Use Case Basics
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:
- Never include implementation specific terminology in the Use Case [SOURCE]
- 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 |