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.
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.
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 agile project. 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.
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 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 documentation” phobia I try something different. I throw out my templates with headings, and document information tables, and numbers like section 188.8.131.52. 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.
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. 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.
Create Your Own Love Story (er, Use Cases)
Have I convinced you that writing use cases is not only a great way to specify functional requirements but can, well, be fun? Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.