When you are capturing functional requirements, you usually create use cases. There are two parts to a use case: 1. Use case diagram and 2. Writing part. Use cases are used to identify and illustrate the different parts of a process. It captures:

1. Actors
2. Business Rules
3. Pre-conditions
4. Trigger
5. Main Flow
6. Alternate Flow(s)
7. Post-condition

Title

You can’t just come up with any random use case title. The title describes the value for the users. For instance, let’s say you were working on a financial management system and were capturing a budget process. You are trying to write a use case for how users get the budget numbers from the top level.

Bad title – Top-Level Budget Numbers

Good title – Getting Budget Numbers from Top Level to Start Budget Process

Do not get stuck in this part though. You can always come back and change the title when you finish the use case. I worked once with a Requirements Analyst who never turned any requirements to the client because he was changing the title every day.

Description

If someone were to just glance at your use case document, would he/she have to read the entire thing? You would hope he/she would, but sometimes this isn’t the case (especially for stakeholders). Therefore, you want to have two-three sentences at the top of the document that describes the process.

Actors

Actors in a use case are the ones performing different tasks in a process. The roles that they perform are the functional roles. You have to show the flow of their steps in a process. As you know, they are the little stick people that you show in the diagram. Use case diagrams are a great way to capture all the user roles needed in a system. It gives a pictorial view for stakeholders and users to look at because there are times when they don’t think about all the users in a process. I mean that they might think of users are just the ones inputting into a system. However, even users who are just making decisions, but not inputting, are still part of the process.

Business Rules

Business rules are just what they look like.  They are policies that affect how a process flow.  You have to remember that some business rules can be unwritten, so you have to ensure that you capture those as well.

Pre-conditions

Pre-conditions are circumstances that have to be true before the trigger can ignite the use case.  Therefore, the pre-conditions are NOT triggers. In the budget process example, pre-conditions like the budget process has already started.  Things of that sort.

Trigger

A trigger is what causes the use case to begin. Get it? Trigger? Gun? I’m being silly now, but you understand where I’m going. In the financial management example above, the trigger for the lower levels to get the numbers from the top level, they have to receive notice. A notice can be anything from a memo, email, system prompt, etc.

Main Flow

These are the basic steps that the user will go through from beginning til end. It will usually go something like this:

1. User enters the system
2. User gets notice that top-level has published the budget numbers
3. User presses a button and the budget numbers are in their working area

Alternate Flow(s)

Alternate flow(s) are secondary scenarios that are variations for the main flow. For instance, let’s say that a user group has access to additional detail than the other user groups accessing the same budget numbers.  However, in order to view this, they have to go through an additional layer of security.  You would want to capture that here.

Post-condition

After the use case is completed and everything is collected, this use case will be the pre-condition for the next use case, which you have to briefly summarize what that will be.

Writing use cases takes practice.

Written by: Shevonne on December 8, 2010.
Last revised by: Shevonne on November 16, 2011.

Tags: requirements use cases, uml, uml diagram, use case document, use cases