How To Write Use Case Preconditions and Triggers

Use case writing is key to effective requirements management. Each use case represents a single idea or logically grouped behaviors. When you define a use case, there are several mistakes you can make. Preventing those mistakes is the first order of business. The second order of business is making sure that the use cases in the system work together. This requires an understanding of the context in which the use case happens. To fully understand a use case you have to know what is promised to be true before the use case happens, as well as what causes the use case to happen. These are subtly different.

Use Cases In Requirements Management

Use cases are a key element of any structured approach to requirements management.

Use cases can be written in either a formal or informal style. Selecting one of the two styles is a matter of preference – your team may work more effectively with the guidance that a formal use case template provides, or may be more effective with the reduced overhead of using an informal template. When writing a formal use case, you describe the use case with a more structured format for the information.

Two elements of that structured information are preconditions and triggers.

Use Case Preconditions

A precondition is a promise, contract or guarantee. The writer of the functional requirements and the implementation team can rely upon the preconditions to be established prior to the initiation of the use case.

Use Case Triggers

A trigger is the initiator of a use case. It is what causes the use case to start. There isn’t a promise that this event happens – only an indication that this event triggers the start of a use case.

Use Case Example

Consider that you are developing use cases for a system to help a local exterminator manage their business. The company, BugBGone, has someone who works in the office – answering calls and scheduling visits. BugBGone also has a technician who visits customer locations and provides treatments. BugBGone needs to schedule customer visits and manage their technician’s schedule. Here’s how part of the use case for scheduling visits might look.

The actor is the person working in the office – the customer is the person whose location is going to be visited by the technician.

Schedule Exterminator Visit To Customer

1. Actor retrieves customer records.
2. Actor requests available times for a technician visit.
3. System presents available times for a technician visit.
4. Actor and customer select an acceptable time from the list of available times.
5. Actor adds visit time and location to technician’s schedule.
6. System confirms that appointment has been scheduled.
7. Actor confirms the appointment with the customer.

Triggers

The simple use case above is initiated by one of two events:

• Existing customer calls to request an appointment.
• Actor identifies that a customer is due for their next appointment.

The first event is the obvious one – an external event initiates a response from BugBGone. The second event is driven by BugBGone’s business rules. Perhaps they have a quarterly treatment program, and every week they review the previous quarter’s appointments to contact existing customers and schedule new appointments for them.

Either trigger could initiate the use case, but neither is required to have happened. This lets the team know that they have to account for either trigger, but can not rely on either of them (having happened prior to the start of the use case).

Preconditions

There are two preconditions that this use case depends upon:

• The user is logged in to the system with authorized access to customer and technician data.
• The customer’s location is in the system (*we’ll revisit this one).

The login / authorization precondition is sometimes referred to as CRUD (create, retrieve, update, delete). This is an indication that these are trivial requirements. Teams should try and minimize the effort spent on defining CRUD, as it adds minimal value to the implementation team. Some people will spend a lot of time and effort debating the importance of managing CRUD requirements and use cases. Defining them provides clarity. Most teams don’t need it, but some might. Our suggestion is to document them, but don’t spend a lot of time on them. By implication, if something is important to the operation of the system, then it isn’t CRUD. This tangent only applies to things where your developer is inclined to say “well, duh!”

Step 5 in the use case, Actor adds visit time and location to technician’s schedule, requires the actor to know the customer’s location. By identifying this as a precondition, we are saying that it is a requirement that this location be in the system. You can imagine how that might not be required (and we’ll come back to that).

Use Case Completeness

By specifying the precondition above that the customer’s location is already in the system, the business is constrained. The triggers that are identified also limit BugBGone to scheduling appointments only for existing customers.
Only existing customers can get treatments scheduled. That’s not what BugBGone wants – they have a goal of growing their business, and this isn’t helping.

Reviewing the preconditions and triggers has identified a problem with the completeness of the use case.

In an earlier article, we discussed the 8 goals of use cases. Completeness validation would be one of the supported goals of documenting preconditions and triggers.

Use Case Refactoring

A simple revision of the use case will address the incompleteness of the use case at achieving BugBGone’s goals. This revision can be done with a use case extension.

Use Case Extensions

A use case extension is an enhancement of a use case that deals with conditionals (if / then situations). BugBGone wants to be able to handle calls from potential customers. To do that, we write an extension for step 1 of the use case.

1. Actor retrieves customer records.

1a. Actor creates new customer account.

The extension, 1a, allows for an alternative – creating a new account – for when there are no existing customer records to retrieve.

* One of the preconditions, The customer’s location is in the system, needs to be removed. It is no longer a requirement for this use case. This precondition was preventing the use case from supporting new customers. Now it supports them too.

Preconditions for Subordinate Use Cases

Subordinate use cases provide additional structure and clarity in use case documentation. In short, a step in one use case could represent an entire other use case. This organizational approach maximizes re-use of use cases, and improves the overall structure of the documentation.

Step 5 in BugBGone’s use case, 5. Actor adds visit time and location to technician’s schedule, could easily represent another use case. This use case will also have triggers and preconditions. This use case could be titled Add Appointment to Technician Schedule.
There may be multiple triggers for the Add Appointment to Technician Schedule use case. One of them is obvious – Schedule Exterminator Visit to Customer is a trigger to the subordinate use case. Another trigger might be the cancellation of another technician’s schedule – perhaps his truck broke down in the middle of the day, BugBGone would try and honor the previously scheduled appointments.

The preconditions for the subordinate use case can be identified by reviewing the super-ordinate (parent) use case.

• The customer’s location is in the system.

This is now a valid precondition, without limiting BugBGone’s ability to grow their business. An appointment can’t be scheduled without the address information. This requirement feels “cleaner” too. The actor of the original use case doesn’t need to know the customer’s location to answer the phone – but the technician does need to know it to keep the appointment.

Summary

Documenting preconditions and triggers is important to validating the completeness of use cases and requirements. There are subtle differences between them. Preconditions are promises that describe the state of the system prior to initiating the use case. Preconditions are mandatory. Triggers are events that cause a use case to be initiated. Any given trigger is optional.