Requirements: Writing Use Cases

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.

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.

Requirements & Traceability

Traceability is a key aspect of requirements management. When non-requirements management tools (such as Excel) are used to manage requirements; true traceability is lost. The objective of this post is to discuss the tools needed to trace requirements, the requirements needed to perform tracing and the benefits of tracing.

Tools Needed

To trace requirements, a requirements management tool that allows traceability is required. Most of my experience has been with Rational RequisitePro by IBM (http://www-01.ibm.com/software/awdtools/reqpro/). However, I have used other tools that perform the job equally as well. Rational tools have been around for a very long time and most large organizations and agencies prefer this tool. But, research can be conducted to find a comparable tool for your project, if necessary.

Requirements Needed

To perform a complete trace all levels of requirements must be captured as follows:  Features (FE), Business Rules (BR), Use Cases (UC), and Functional Requirements (FR). In this post I will briefly cover each requirement type and provide a basic example.

The Features of a system provide the highest level of grouping for requirements. For example, FE1: Manage Customer Sales is an example of a Feature. The next level consists of use cases. For example, UC1: Add a Customer Record, UC2: Add an Employee Record and UC3: Place a Customer Order. 

Business Rules can also be captured. For example, BR1: All customers must be associated with a primary salesperson. It should be noted that some BRs will be implemented by a system and some will not. Either way, it's best to capture all BRs and add annotations to clearly mark the stakeholders' decision regarding implementation. If a complete list of BRs is managed, as stakeholders look at the list, they are able to more easily determine whether or not a BR is missing. 

Functional Requirements are the lowest level of requirements. For example, FR1: Once a customer  purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status. Now our list of requirements is as follows:

FE1: Manage Customer Sales
    UC1: Add Customer Record
    UC2: Add an Employee Record
    UC3: Place a Customer Order (Includes UC1 and UC2. In other words, you must perform UC1 and UC2 to perform this use case.)
        BR1: All customers must be associated with a primary salesperson. (System Implementation)
        FR1: Once a customer  purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status.

If the Project Manager wants an accurate reporting of the impact a change has on time-lines and project costs, the requirements management tool can be configured to also support managing Test Cases (TCs) and Test Procedures (TPs). For example, TC1: Place an Order will include the following UCs:  UC1: Add a Customer Record, UC2: Add an Employee Record, and UC3: Place a Customer Order. We also need test procedures to test the business rule and the functional requirement. Therefore, our test items are as follows:

TC1: Place an Order  
     TP1: Test procedure for UC1 not included in this example.
     TP2: Test procedure for UC1 not included in this example.
     TP3: Test procedure for UC1 not included in this example.
     TP4: Test procedure for UC2 not included in this example.
     TP5: Test procedure for UC2 not included in this example.
     TP6: Add a customer record (No salesperson).   Expected Result:  An error message displays "Salesperson is required" and save is not executed. (Test procedure for UC3.)
     TP7: Add a customer record (with salesperson)  Expected Result:  The record is saved. (Test procedure for UC3.)
     TP8: Customer order total < $1000. Expected Result: A notification is NOT sent. (Test procedure for UC3.)
     TP9: Customer order total = $1000. Expected Result: A notification is sent.  (Test procedure for UC3.)
     TP10: Customer order > $1000.   Expected Result: A notification is sent. (Test procedure for UC3.)

In our requirements management system FE1 is traced to UC1, UC2 and UC3. UC3 is traced to BR1, FR1 and TC1. TC1 is traced to TP1 through TP10. 

Benefits of Tracing

In supporting IT projects sometimes business decisions impact the requirements gathered. If this occurs there are only two ways to assess the damage:  guess or analyze facts. In today's market, inaccurate guesses can result in loosing a customer. For example, guessing a shorter time frame than what is required means the team rushes to meet the deadline; but, the work is not completed accurately. Or, over guessing may result in providing inflated costs and time-lines,  which may cause mistrust. Generating an Impact Analysis report provides the facts needed to make sound decisions for an IT project.

For example, initially a customer agrees to wait three weeks for the Place a Customer Order component. However, the customer's company has been invited to a trade show in 1 week. Now the customer wants the component completed by then. Below is a copy of our Impact Analysis report: 


Impact Analysis Report for UC3:  Place a Customer Order

UC3: Place a Customer Order
     BR1: All customers must be associated with a primary salesperson. (System Implementation)
     FR1: Once a customer  purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status.
     TC1: Place an Order
          TP1: Test procedure for UC1 not included in this example.
          TP2: Test procedure for UC1 not included in this example.
          TP3: Test procedure for UC1 not included in this example.
          TP4: Test procedure for UC2 not included in this example.
          TP5: Test procedure for UC2 not included in this example.
          TP6: Add a customer record (No salesperson)   Expected Result:  An error message displays "Salesperson is required" and save is not executed.
          TP7: Add a customer record (with salesperson)  Expected Result:  The record is saved.
          TP8: Customer order total < $1000   Expected Result: No notification is sent,
          TP9: Customer order total = $1000. Expected Result: A notification is sent and
          TP10: Customer order > $1000. Expected Result: A notification is sent.
          UC1: Add a Customer Record 
                 FR2: Functional requirement for UC1 not included in this example.
          UC2: Add an Employee Record
                 FR3: Functional requirement for UC2 not included in this example.
------------------------END SAMPLE IMPACT ANALYSIS REPORT--------------------------

The Project Manager meets with the customer and provides a copy of the Impact Analysis report. The Project Manager negotiates holding off on implementing BR1 and FR1 to meet the new deadline; and, the customer agrees. Therefore, the following items do not have to be completed for the upcoming release: BR1, FR1, UC2, FR3, TP4, TP5, TP6, TP7, TP8, TP9, TP10.

In addition to being able to generate an Impact Analysis report, traceability provides other benefits. For example, when a requirement changes the requirements management system will typically mark the associated requirement(s) as invalid. For example, if UC3 changes the requirements management system marks its relationships with BR1, FR1 and TC1 as invalid. The analyst rechecks those items to make sure the relationships is still accurate and makes any necessary changes.  Also, a trace matrix can be used to ensure 100% testing coverage of all requirements. This provides a tangible way to guarantee all requirements and business rules have been accurately implemented to ensure a successful implementation.