Can you really have a love affair with a document? Don’t tell my husband, but the answer is “yes”. For me, the love of my business analysis professional life has been use cases. In what follows I’ll share a bit of my personal history with this beloved deliverable – the good and the bad.
(I love use cases so much, I give away my beloved use case template for free. Imagine that!)
Use Case Reviews Mixed with Design
In my early days as a business systems analyst in a relatively-RUP process, the use cases were the center of our world. After “baselining” a hefty 50-60 page requirements document, we’d dive into use cases. We’d hold reviews with the business stakeholders, development team, project managers, and QA and painstakingly review the details of the use case alongside the user interface wireframes. Many of these discussions were essentially design discussions as we all struggled together to figure out what, how, and what’s possible all at the same time.
I’ve come to realize that these meetings were woefully inefficient and violated the basic tenet of separating “what” and “how”, but man were they fun! We had a great time debating details, discussing options, and finding solutions. At the end of the process, we all had a fairly good shared understanding of what was to be done.
By the way, if you are not familiar with use cases check out this video to learn how to write one step by step:
Keeping On with Use Cases as a Solo BA
The love affair continued through my next two positions. First as a solo BA in a small start-up and next as a BA manager at a larger “reborn” start-up where we were merging the IT systems of 5 real start-ups into one. Truth be told, I didn’t really know any other way to be a business analyst.
Focus on the use case I kept saying and eventually we will figure this whole implementation thing out. Use cases have a sort of internal beauty. They just so perfectly get you from point A to point B. The very act of writing a use case inspires some of my best systems thinking. The act of reviewing and validating a use case can create active discussions about the actual requirements.
Finding Agile and Still Writing a Use Case or Two
Then I come along to my first project as an agile business analyst. It becomes agile after I start it as RUP (because that’s what I know and that’s what the client had used before). So I’ve got a use case list and it needs to become a user story list. User stories are smaller, more granular, and development driven.
After a month or so fighting through this transition, it clicks. User stories, done well, could solve many of the conflicts that surface when requirements intersect with delivery. They elevate all kinds of details that use cases brush under the rug. They force me to prioritize that new alternate flow that “just has to be there” instead of embedding it into a use case and hoping it makes it’s way into a design document or project plan.
All good. All good.
In this project, I also have the opportunity to document some business process improvements. And where do I start? Of course, with my beloved use cases.
If you are looking to learn more about user stories, here’s a quick tutorial:
Can Good Wireframes Supplant Use Cases?
Then I land a client with even less process, more desire for quick results, and smaller development team than anywhere I’ve worked before. At first they just want wireframes because they find them easy to develop from. This works for phase 1 because it’s a fairly simple project, but phase 2 is heavy on functionality and interactivity.
I can almost smell it…we need some use cases.
I start with using use cases simply to analyze the problem, never showing them to anyone. I fully realize now how much I love them because of the good thinking that comes from them. You simply do not think this well staring at a set of wireframes. The rules don’t elevate themselves, the analysis just doesn’t happen.
But then we start to struggle in the wireframe reviews. The developers need the use cases too. They don’t want them, but they need them.
Wary of “too much requirements documentation” phobia I try something different. I throw out my templates with headings, and document information tables, and numbers like section 3.1.1.2. I start with a blank Word document. I write a description. I create a flow of events with basic 1, 2, 3 numbers. I add in alternate flows and exception flows, again 1, 2, 3. I add a bullet list at the end to capture open questions and key discussion points.
I’ve captured the absolute essence of a use case in its most simple form. Most use cases fit on a page. In the end, these use cases passed the muster of a simple document for a team that didn’t want too much documentation.
Want to add wireframes to your requirements process (I highly recommend it!). Here’s a video explaining how to create a wireframe:
Still In Love with Use Cases
And then my next project. Again responsible for building a requirements process, but not too much of one at first as we begin to integrate the BA role into the development process. Again figuring out how to bring multiple new stakeholders into an agile environment. Again using use cases upfront to analyze the problem and knowing I’ll need them again on the back-end to document the system. And again trying to find if they have a place in between or if user stories will fill the bill.
I’ve had a long history with these BA deliverables we call use cases. One might even call it a love affair of sorts. Many, many thanks to Ivar Jacobson for creating them way back in the day.
It’s always nice to find a tool that makes you better at what you do. I think no matter what I do, use cases and use case thinking will have a home in my mind and a bit in my heart.
And to Today, Training High-Performing Business Analysts on…Use Cases
Inn 2008 I founded Bridging the Gap, a training company for business analysts. The second course I developed was called Use Cases and Wireframes, which is now part of The Business Analyst Blueprint training program.
Use cases are a core foundational technique we teach in The Blueprint. I love teaching participants how to write them, breaking down all the minute details that separate an ambiguous use case from one that’s clear and complete. I love helping participants understand WHY to write them and also when to write a use case (as well as when not to).
Wondering when to write a use case? Check out this video:
Download Your Use Case Template Today
Get everyone on the same page about software requirements with use cases. Download our (completely free)Â Use Case Template today.
We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.
Click here to download the Use Case Template<<Â
If you’ve gotten this far and aren’t swooning over use cases yet, perhaps process maps are more your style? Here’s a video on this technique – they go hand in hand with use cases:
Use Cases Are One Way to Analyze the Functional Requirements
It’s also important to remember that use cases are just one type of functional requirements specification that you can use on a software project. You leverage use case thinking skills even if you are creating other types of requirements documentation. Get all the details on functional requirements here:
Hi Caroline,
Glad to hear that I am not alone! I’ve also mapped wireframes to use cases and find that combo of visual and text can really help solidify the requirements for some teams. Also agreed that sometimes you just need the structure of an excel document to capture certain details. Business rules is definitely one example, as is data mapping. Domain models (using conceptual language) might be an interesting technique for you as well. More details in this post: https://www.bridging-the-gap.com/bag-of-tricks-3-using-domain-models-to-create-conceptual-understanding/
Laura
Hi Laura,
Your use case experiences mirror my own. I find use cases are an important tool in my toolbox. I use them when we’re talking about interactive processes in our requirements sessions. We link them in closely with the wireframe development calling out to the wireframe in the use case at the appropriate step. Think lots of stickies and flip chart paper with taped lines to start with!
However, I feel the need to turn to other methods when we dive down into the “nitty gritty” of complex business rules, such as integrations with accounting systems. I struggle to find good tools to represent those rules (spreadsheets anyone?) and how to link those complexities into the one step that they pertain to without getting into too much system language for our end users. Would love to hear yours (and anyone elses) thoughts on those topics.
Thanks again – I really enjoy your blog!
Caroline
Hi Jenny,
Thanks for sharing your story. Interesting how we can have different ways of accomplishing the same end goal.
In terms of how we can be sure that our discovery artifacts are correct if we only deliver a subset, I suppose I would say, concretely speaking, no, but we can make them good enough. As I’ve done iterative projects, there is sometimes a need to circle back to documents that you’ve already “completed” in an earlier iteration and make revisions. This works nicely in an agile process because you can just create a new story to hold and prioritize the change as opposed to a more rigorous change control process that might be necessary for a use case with sign-off. Regardless, what was defined in an earlier iteration was good enough to get started. And the information you have later in the process is much better because you might actually be reviewing something in a demo environment, so the change is more informed that if you were just working from your requirements documentation.
Hi Laura, I just saw this one and wanted to chime in. Though I don’t have formal UML experience, what little I do have speaks to me in a way that verbose requirements and use cases don’t. I love figuring out where the processes and modular functionality fit in and work together. And I love the translation of actors and objects and processes into object oriented design.
So for me, when I start on something I use whatever tools seems most appropriate to help me understand what’s going on, what needs to be fixed/improved, etc. I like context diagrams and process flows, but when I think of starting something new, I think I tend to approach them from a UML standpoint. Who is doing what with what? And then we make sure that those answers make sense in terms of the business strategy and process efficiency.
Then once I do understand, I can pull out the artifacts (be they requirements, wireframes, context digrams, data flows, decision trees, or use cases) which best communicates to my stakeholders.
Clearly use cases fill that role for you during your discovery and the ultimate deliverable is something that varies for you as well, depending on your target stakeholder. So the question for me is: Can we be sure that our discovery artifacts are correct, if we only deliver a subset of them for sign off? How much does that matter?