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
- Actor retrieves customer records.
- Actor requests available times for a technician visit.
- System presents available times for a technician visit.
- Actor and customer select an acceptable time from the list of available times.
- Actor adds visit time and location to technician’s schedule.
- System confirms that appointment has been scheduled.
- 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.
I question the expertise of this author since he lacks the basic understand of the CRUD acronym which has been known for decades if not longer. His statement of “replace” is 100% incorrect. C-R-U-D are the four basic transactions or actions that can be performed on any data. Create, READ, Update, Delete. His “replace” is synonymous with “update” in a database and is totally wrong. Also his supposed explanation on CRUD and preconditions is off base.
Thanks “knowing person” – major typo on my part. If you look at the earlier article, I described it as “Retrieve”, which is synonymous with READ.
I’m updating this article so as to not distract other readers (and keeping these comments as history). Thanks for catching it.
The point I was making (in both articles that reference CRUD) is that there are elements of software development that many (but not all) people take to be “understood.” It raises interesting debates about how to document and approach them when writing requirements.
By analogy – if you set up a database, of course you need to be able to retrieve a record. If you have a secure website, of course the user has to be logged in.
There are cases in both domains where you absolutely must specify this stuff.
But there are also cases where the effort to document “understood” levels of detail provides little return.
I have several comments on this Use Case, as I am used to write them somewhat differently. Let me explain what I do different and how I jumped to the conclusion to do it different.
Comment 1: the first precondition is superfluous, as it is already stated that the actor of this Use Case is the office worker, whose work it is to schedule exterminator visits to customers.
This precondition can be modeled more elegant by specifying the actor in the Use case in stead of saying “Actor”. I normally put the Actor names in Italics in my Use Cases.
Comment 2: use alternative flows in stead of extensions.
Almost every Use Case has alternative flows, so don’t introduce another mechanism (extensions) when alternative flows can handle the situation.
Schedule Exterminator Visit To Customer
1. The Office worker verifies customer is an existing customer.
2. The Office worker retrieves customer records.
3. The Office worker requests available times for a technician visit.
4. System presents available times for a technician visit.
5. The Office worker and customer select an acceptable time from the list of available times.
6. The Office worker adds visit time and location to technician’s schedule.
7. System confirms that appointment has been scheduled.
8. The Office worker confirms the appointment with the customer.
Alternative flows
A1.1 New customer
When the Actor determines that the customer is NOT an existing customer,
the Actor adds a new customer record including the customers location.
Continue at step 2.
Comment 3: “Actor adds visit time and location to technician’s schedule” is not a Use Case, as it does not represent a complete User’s goal, it is only a step in it.
“Add visit time and location” could be a subflow of this use case. Use subflows to prevent the main flow from becoming too complex. Subflows, in my opinion, should NEVER have preconditions.
The reader of the Use Case should be able to first understand the mainflow, and after that delve deeper into the subflows.
In order to be able to understand the mainflow, the reader should know about the preconditions for the subflow while reading the mainflow.
So insteat of:
Flow:
4. Step …
5. Step … (see subflow S)
6. Step …
Subflow S
Precondition: some condition you might think of DOES hold
Step
Step
Step
I prefer:
4. Step …
5. The verifies that some condition you might think of DOES hold
6. Step …
Alternative flows
A5.1 If some condition you might think of DOES NOT hold
Continue at step …
Again: use the construct “Alternative flows” which we use already.
Hope to hear from you all.
Hey Harry, thanks for commenting, and long term reading!
You make really good points about extensions versus alternates. I’ve always used alternates in the past, but Cockburn suggests extensions. I think you’ve convinced me that alternates are better. What do other folks think about alternates versus extensions?
As to preconditions for subordinate use cases – I think the power of subordinate use cases comes from encapsulation and reuse. With that approach in mind, a subordinate use case is just another use case that happens to be reused. And therefore should have preconditions – allowing it to be reused from within multiple other use cases.
Hi all,
I’ve been writing usecases for a number of years… I have no strong preference for using either extensions or alternative flows *from a writing point of view*. In my experience, using extensions (Rather than alternative flows) makes the usecases easier to read for people not familiar with the UC technique. That, for me, is sufficient reason to use extensions.
Just my five cents
P.S. I really like the book by Cockburn. It is one of the most complete discussions on the topic of usecases so perhaps my comment is slightly biased..
Hi,
Your suggestion of the trigger is:
* Existing customer calls to request an appointment.
* Actor identifies that a customer is due for their next appointment.
I wonder whether we should include those events in the use-case specification. To develop our software, all we need to know is that sometimes the actor will use our Scheduling use-case. That’s enough. We needn’t worry and should not worry about the real-life situation that lead the actor to intiate the use-case. The reason is simple, we cannot/ hardly imagine all of the real-life situations. Maybe, the customer call officer (by phone)/ email or visit face-to-face the officer. Maybe, the technician request a visit (on behalf of the customer…).
Sometimes, some types of trigger are important (eg. a stimulous from sensor, a package from network, receive a message/email….). However, real-life situation trigger like your use-case seems to be not necessary. How about your idea?
I read some UML book. When talking about extension of use-case, the authors usually mention about 2 types of relationship between use-case: include and extend. Use-case extension is good for re-use (save some time for documenting the use-case specification). However, I wonder why should we make a difference between include & extend relationship? It is so meticulous and why don’t we focus on it in design phase in some diagram like activity diagram or sequence diagram?
Hope to hear from you all
Hai Ly-Hoang
Hi,
In addition to Precondition, Some UML book also mention about Postcondition. It make me a little bit confusion about how to use Postcondition. Can you give me some example about PostCondition
Thank in advance.
Hi All,
Use case is understood and wrote in many establishments with difference, yes, surprisingly true. Additionally, every one claims that they are using the proper method and not the other one!
Graphical representation surely helps. But sometimes it confuses too. Along with the graphical representation, description of the events – as it happens – helps a lot.
However, in many cases, Business Analyst has to explain once again to the team as they fail to understand! (dont say – your use case is imperfect.
Thanks, Jo!
I think that having a “proper method” of writing a use case is like having a “proper method” of cracking an egg. It doesn’t matter if you tap the egg on the side of a skillet or the surface of a counter, or crack it open with a spoon. As long as you can get the egg out of the shell, you’re doing it “right.” Different circumstances will make different methods more effective. When I was working in a cafeteria during my freshman year of college, I had to crack sixty dozen eggs on Saturday mornings to feed the hordes of students. I would crack them four at a time – two in each hand – letting the eggs fall through a strainer to catch any errant bits of shell. When I’m baking, I will carefully crack an egg on the side of the bowl, so that I can not only control the shell, but so that I can use the halves of the shell to separate the yolk from the white of the egg. Both of them are “proper methods” and both would work in either situation – but one is clearly better than the other in each situation.
The same is true of writing use cases – as long as you are communicating the requirements, your method is a “proper” one. Some approaches and techniques will be more effective than others, given the nature of the requirements, the communication dynamics with members of your team, and the context in which you are all working. If someone gives you a hard time about a particular approach, maybe ask them to crack some eggs. At the same time, ask yourself – maybe there’s a better way to crack this egg, this time.