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.
Great advice, Jonathan. “Keeping it simple” is probably the best all-around advice for use case authors. Use cases become unwieldy when the author loses sight of the fact that the entire point is to communicate – quickly and simply.
Always good to get the 'best practices' for use cases back in the front of mind – great evergreen content. I especially appreciate the call-out of isolating business rules (and not just implementation details). Good article.
Nice summary of key points, Jonathan. thanks.
Your bit about business rules, and also so nicely focused on by Scott in his article you reference is soooo critical. embedding rules (and data) inside use cases ends up being the bane of the entire delivery team.
a while back (2002?!) i wrote a 2-parter for IBM’s Rational Edge on top 10 misuses of use cases. there i also rant a tad about the need to separate out rules…(http://ebgconsulting.com/Pubs/Articles/Top10MisusesOfUseCasesPart1-Gottesdiener.pdf).
the thing is: rules operate across many use cases. and change, potentially a lot.
your advice to keep it simple is essential.
in practice, spending time elaborating use cases specifications is not a good investment; many of the steps and variations and exceptions don’t end up being get implemented. spending time on use case specs is, as dare say, as sinful as writing requirements specs cuz the template and process says so!
We also just plain forgot what we meant in those specs; what was that i meant when i wrote that months ago? hmmm…ends us as muda, waste.
better to be lean with these use cases (if used). on agile projects, they can be useful for what i refer to as “big view” and perhaps “preview” of requirements (product and release levels).
not a good idea for the “now” (iteration) level.
anyway, thanks for the blog, and forgive me mini-rant 😉
~ ellen
Thanks for the comments.
Scott, I really appreciated your article on extracting business rules as reference.
Matt, appreciate the comment – BTW, I’m giving the latest Case Complete a test drive at home just because I’m a geek like that. Seems like a really nice product.
Ellen, you’re welcome to “rant” as much as you want on this blog. I really value your feedback. Your comments on use cases for agile projects are especially interesting to me as I’ve never really worked in a truly “agile” methodology. I’ll have to read up on that. Any references to recommend?
Jumping in quite late into this ….but it is a nice article on use cases.
I am great supporter of use cases and in my point of view, it is good to invest some time writing up all the exceptions and alternatives, especially in complex projects.
My suggestion will be start with the business use cases initially.
Then as we proceed with each business use case, complete the functional use cases.
As part of the functional use cases, when we do write up all the main flow criteria, all exceptions and alternatives, it gives a good chance to weigh them against the probablity of occurrence and then prioritize them.
During the technical design stage, we may take a decision to not implement some of them – but that should be a calculated decision based on the possibility of occurrence and the its prioprity from business point of view.
Not late at all, Charu. Thanks for the comment, and for the sound advice.
Use cases are the most intuitive way I’ve come across (so far) for identifying the alternate scenarios, exceptions and business rules in context.
All very useful advice. Thank you. I would add to the discussion about breaking out Business Rules that I agree that a business rule should not be embedded in a step, but I do find it useful to provide a specific unique reference to the business rule at the applicable step, regardless of whether the rule is documented in a separate rule section of the use case or is in a rule repository. This removes any ambiguity about which rule should be applied and when, but keeps the use case ‘clean’ and readable, just as Jonathan wisely recommends. The rule can still be updated independently without impacting the use case steps. I have found it best to give each rule a unique number and brief name (e.g. BR0053 Online Customer Validation). Keeping numbers unique may not be possible if you don’t have a corporate-wide rule repository, but you can at least keep them unique within a project, or perhaps a domain.
I appreciate the comment, Bernie. You make a good point. I do like the naming/numbering technique.
As I said, it’s a good practice to extract the rules from the use cases, but you still want your use cases to be as useful/usable as possible so you want those rules to be easy to get to for those that are going to be using the use cases to design and build.
To that end, I’ve heard it argued that some designers and developers prefer the rules embedded in the use case steps because that way they have it all right in front of them.
Of course, you lose the stability I mentioned above and maintaining the use cases could become a chore for the BA, but if that’s the trade-off an organization wants to make in order to get a good product out the door as quickly as possible, then I’m not going to knock it.
When you get down to it, the use case is just a technique – another tool in the toolbox – to help facilitate creation of a good product.