I’ve been “heads down” on some use case work the past few days, so this is a topic that is fresh in mind. While I’m thinking of it, I thought I’d share just a few guiding principles that I like to use to keep me “out of the weeds” as I identify and document use cases. I hope some of you will benefit from them, and perhaps have other ideas to add and share.
Start With a Goal
A use case enables the user (actor) to do something that is of value to them. Think of the reasons a user would want to use the system. Why do they need the system? What do they hope to accomplish with the system? These user goals are the system’s primary use cases. Work on identifying these first.
Once you’ve identified the primary use cases, you’ll usually want to capture use cases for auxiliary activities that provide value to the user, but that might not be among their main reasons for using the system. A couple examples of these might be user registration or user identification/authentication processes. They quite likely aren’t the main reasons the user wants to use the system, but they do provide value.
For instance, user registration may enable the system to recognize the user and retain useful user information about the user for subsequent visits, saving the user from having to re-enter it. The login process demonstrates to the user that the application provides a level of security for user information and access, and enables the system will recognize him/her once they’ve logged in successfuly.
Take Out the Tech
To the extent possible (and I know that this varies by situation/environment) take out references to screens, fields, clicks, etc. Once you begin including user interface details a] it becomes more difficult to know when to stop, and b] you’ll find that your use cases will become more complex and will require more frequent updates.
I’ll use a few steps from the main success path of a simple user identification/authentication use case as an example:
1] The user identifies self and provides proof of identification. 2] The system evaluates the identification information, and recognizes the user as valid and authorized. 3] The system grants the user access to the system.
As you read the steps above, you might reflexively envision a logon screen or modal into which you would enter a user ID and password, or maybe an ATM machine with card swipe and PIN entry. But as you read the steps again, I could just as easily replace “user” with “walk-in customer” and “system” with “teller” and be referring to a person walking up to a bank teller and asking to withdraw cash. The teller would first make sure the customer had an account, and then verify that the customer was who he said he was by looking at a bank card or some other form of ID.
Freeing use cases from a specific technical (or other) context enables your use cases to remain relevant as technologies change. It makes them more portable. More reusable. Freeing use cases from technical context also increases the freedom of the designer to decide how technology might best be applied instead of constraining him/her upfront.
Use cases can be a great enabler for moving from a legacy system to a new system as they preserve user goals with the minimal steps to achieve them while leaving behind all of the implicit technical overhead that may be obsolete or undesirable with the new technology.
Sure, you can still use more detailed and technical use cases, but you’ll have saved yourself a lot of churn and potential heartache if you port user goals with context-free descriptions than if you have to evaluate every screen, field and click from the old system as you design the new.
Break Out the Rules!
Even if we “take out the tech”, we can still end up with use cases that are bogged down with rules and constraints. Extracting rules from the use cases enables us to change the rules without having to change the use case. Who wants to update the use case description every time a business policy or rule changes? Some recommend keeping separate business rules repository as an enterprise asset for maintaining business rules. I like that idea, but if you don’t have that enterprise asset in place, and it isn’t practical in the short term to get started on one, I would reference the business rules in the use case in a dedicated rules section possibly toward the bottom of the use case.
Again, let’s look at the example use case steps above. There may be company standards or regulatory rules on how we identify and authenticate a user. We might require that a username be of a certain character type and length. We may not require that a user be registered before accesing our system. We might require a certain level of security for a user password. These are important to how we implement the use case, but they don’t have to be in the body of the detailed use case description.
By filtering out the situational rules and constraints, use cases become quite stable. They may only need to be modified when the way an actor goes about accomplishing the use case changes fundamentally.
The Communication Trump Card
The tips I laid out here were to take complexity out of the use case and keep it simple. In my experience I’ve found that the more complex a use case gets, the more churn and re-work it requires.
All my comments and opinions aside, the most important thing to remember is that use cases – and requirements specs in general – are nothing more than communication tools. The goal of what we’re doing with use cases is to communicate requirements in a way that gives us the best chance at producing solutions that address business needs. Your situation may require you to communicate a greater amount of detail in your use cases in order to properly equip the designers, developers and testers.
Regardless of your situation, I would still apply the guidelines above to get started. Start out with the basics – the bare minimum – and build from there. Describing the principle (pattern) of BreadthBeforeDepth, Adolph and Bramble advise that, “the more detailed your early endeavors, the more you will have to change them as you learn about the system.”
Whether or not your use cases end up looking as simple as the sample above, you’ll benefit from keeping them extra simple in the beginning, and as simple as possible (or reasonable) as you move forward.
Do you have any quick use case “rules of thumb” that help you identify and specify use cases? If so, please share! I’m anxious to hear what is working for you.
Commentaires