Use Case Overview
A Use Case is a requirement that directly relates to a user's or
system's ability to do something. The something a user does may include
creating a record, deleting a record, editing a record, searching for a
specific record, logging into a system, generating a specific type of
report, exporting a data, etc. Some projects use user scenarios instead of use cases.
However, many projects still use use cases because this type of
requirement has been around longer and provides clearer direction when
creating requirements. Use Cases are typically included in a document
called the Use Case Specification.
Use Case Properties
Use Cases also have properties. A property is text that provides
specific information about the use case. For example Use Case Name and
Use Case Description are both properties, Following is a list of the Use
Case Properties:
ID: The identify of the use case. Each use case has a unique identifier such as 1, 2, 3, 4, or 1.0, 1.1, 2.0, etc.
Name: A unique name for the use case. Examples: Add a Customer Record, Update a Customer Record, Mark a Customer Record as Inactive (which is associated with the update task), Search Customer Records, Filter Customer records, Generate a Customer Orders Report.
Description: This field provides additional information about the use case.
Date: The date the use case was created or updated.
Actor(s): The user group that will be able to perform this use case. For example, user groups can be HR secretaries, HR Benefits Managements, Accounts Receivable Clerks, Desktop Publishers, teachers, principals, students, parents, etc.
Pre-condition: The condition the system is in before the use case is executed. For example the system might be in a "Validated" state if it is about to store data; but was required to validate the data first.
Post-condition: The condition the system is in after the use case has been executed. For example, if the system just filled an order it might be in the "order filled" state.
Normal Flow: This property outlines the steps the user executes to complete the task defined by the use case. For example, Create a Customer Record the user my 1. Log into the system; 2. Select Customer Management (from the menu); 3. Select Create Customer from the Customer Management page; 4. Enter customer information; 5. Click Save to save the record and return to the Customer Management page.
Alternate Flow: This property outlines any alternate paths a user might take to execute the use case. For example, users might perform step 1 from the normal flow. Then for step 2 users may right click and select Import to import a customer record. Since users are performing a step differently, this is known as a branch. A branch is used whenever users perform the same task (in this case, Create a Customer Record) differently. Step 3 then says "return to step 5. Normal flow". So the alternate flow only outlines were steps differ from the normal flow.
Includes: This property outlines the Use cases this use case includes or uses. To execute the Create a Customer Record use case users must first "Log into the system," which is also a use case that defines logging in requirements. Whenever users must perform the steps in another use case to complete the current use case; the current use cases uses or includes another use case.
Extends: When a use case extends another use case the extending use case adds additional functionality to the base use case. For example, a toy manufacturer may have a program where customers (who meet a certain criteria) can use points they've earned to buy beta toys. Ordering beta toys requires different functionality from the functionality required to order regular toys. For example, customers cannot use money or credit cards to buy beta toys--making the payment method different. Customers cannot purchase beta toys from the regular product stock--making the location where toys are stocked different. In addition customers can't backorder or pre-order beta toys. And, customers must meet a certain criteria to view the available beta toys. Therefore, there should be a use case that supports the functionality to "Place an Order". The "Order Beta Toys" use case would extend the "Place an Order" use case.
Business Rule(s): Many companies establish business rules. Some business rules must be enforced by a system; while other business rules cannot be enforced by a system. If a business rule is to be implemented or enforced by a system; it is associated with the applicable use case. Examples of Business Rules are as follows: 1. An employee must work for the company for 3 years before he/she can enter a customer order into the system. 2. A Customer Service Manager must approve the order before the products are shipped. (Note that both of these business rules can be implemented by the system.)
Feature(s): The feature is the highest level of requirement. Features are used to group a use case. Examples of features include Generate Reports, Manage Customer Records, Interface With Accounting System, etc.
Name: A unique name for the use case. Examples: Add a Customer Record, Update a Customer Record, Mark a Customer Record as Inactive (which is associated with the update task), Search Customer Records, Filter Customer records, Generate a Customer Orders Report.
Description: This field provides additional information about the use case.
Date: The date the use case was created or updated.
Actor(s): The user group that will be able to perform this use case. For example, user groups can be HR secretaries, HR Benefits Managements, Accounts Receivable Clerks, Desktop Publishers, teachers, principals, students, parents, etc.
Pre-condition: The condition the system is in before the use case is executed. For example the system might be in a "Validated" state if it is about to store data; but was required to validate the data first.
Post-condition: The condition the system is in after the use case has been executed. For example, if the system just filled an order it might be in the "order filled" state.
Normal Flow: This property outlines the steps the user executes to complete the task defined by the use case. For example, Create a Customer Record the user my 1. Log into the system; 2. Select Customer Management (from the menu); 3. Select Create Customer from the Customer Management page; 4. Enter customer information; 5. Click Save to save the record and return to the Customer Management page.
Alternate Flow: This property outlines any alternate paths a user might take to execute the use case. For example, users might perform step 1 from the normal flow. Then for step 2 users may right click and select Import to import a customer record. Since users are performing a step differently, this is known as a branch. A branch is used whenever users perform the same task (in this case, Create a Customer Record) differently. Step 3 then says "return to step 5. Normal flow". So the alternate flow only outlines were steps differ from the normal flow.
Includes: This property outlines the Use cases this use case includes or uses. To execute the Create a Customer Record use case users must first "Log into the system," which is also a use case that defines logging in requirements. Whenever users must perform the steps in another use case to complete the current use case; the current use cases uses or includes another use case.
Extends: When a use case extends another use case the extending use case adds additional functionality to the base use case. For example, a toy manufacturer may have a program where customers (who meet a certain criteria) can use points they've earned to buy beta toys. Ordering beta toys requires different functionality from the functionality required to order regular toys. For example, customers cannot use money or credit cards to buy beta toys--making the payment method different. Customers cannot purchase beta toys from the regular product stock--making the location where toys are stocked different. In addition customers can't backorder or pre-order beta toys. And, customers must meet a certain criteria to view the available beta toys. Therefore, there should be a use case that supports the functionality to "Place an Order". The "Order Beta Toys" use case would extend the "Place an Order" use case.
Business Rule(s): Many companies establish business rules. Some business rules must be enforced by a system; while other business rules cannot be enforced by a system. If a business rule is to be implemented or enforced by a system; it is associated with the applicable use case. Examples of Business Rules are as follows: 1. An employee must work for the company for 3 years before he/she can enter a customer order into the system. 2. A Customer Service Manager must approve the order before the products are shipped. (Note that both of these business rules can be implemented by the system.)
Feature(s): The feature is the highest level of requirement. Features are used to group a use case. Examples of features include Generate Reports, Manage Customer Records, Interface With Accounting System, etc.
The Use Case Specification
Use Cases are typically added to a Use Case Specification. The Use
Case Specification is a document that includes the use cases along with
the property details for each use case. Once the Use Case Specification
is completed; it is distributed to the users or user representatives for
review and feedback.
