With all the craze about use cases lately, you’d think that no collection of requirements documentation would be complete without at least one, and perhaps several, use cases. The reality is that while use cases are an extremely useful requirements tool and one that just about every BA should have in their tool belt, there are projects and situations in which writing use cases would be a big mistake.
Choosing the best deliverables for a project situation is a necessary skill to be an effective and valued business analyst and sometimes use cases are simply not the right choice. In certain project contexts, choosing use cases means creating way too much documentation. In other contexts, the use cases make it difficult to highlight the most important requirements so they can be easily implemented. Other times, they are simply not an appropriate tool for the type of requirements you are creating.
That being said, I do have my own love affair with use cases, the latest installation of which is facilitating a virtual course called Use Cases and Wireframes. Love affair or not, use cases are not always the best choice.
Let’s look at 3 signs you shouldn’t be writing a use case.
Sign 1: You Are Not Specifying Software Requirements
Use cases are ideal for specifying functional requirements in such a way that shows how the user interacts with a software system to achieve a specific user or business goal. If you are not documenting requirements for software, then you shouldn’t be writing a use case.
If you are not specifying software requirements, you are most likely defining requirements for a business process change. If so, consider a business process model.
Sign 2: Software Changes Are Not Interactive or User-Driven
A use case is an ideal choice for providing context to user-driven or interactive software features. Because each functional requirement happens in response to a user action, there is a flow to a use case that makes them easy to understand and review. However, it’s possible to specify software changes and requirements that are not particularly interactive.
For example, let’s look at reporting requirements. Typically when you write reporting requirements you are working from an existing reporting system. The functionality already exists for selecting a report, selecting criteria, and generating the report. A typical small project will add a new report to the existing system. It might be tempting to write a use case to describe the report, but unless the report itself is interactive (for example, if you click on a data row, then filtering is applied) there is not much value in writing a full-blown use case to capture these requirements. Instead a detailed wireframe (perhaps with an accompanying user interface specification) or sample report would be better choices.
Of course, if you are building a new reporting system or updating the flow of an existing reporting system, then a use case could be entirely appropriate. For instance, if users are going to be able to generate their own reports for the first time by specifying criteria and choosing from a list of report types, then a use case could be a very logical choice for detailing these functional requirements.
Sign 3: Your Team Prefers Another Form of Documentation
No matter how much we like one business analysis technique, it’s important that we customize our business analysis activities to meet the need of our stakeholders. When it comes to functional software requirements, the needs of our technical implementation stakeholders in software development and quality assurance are of primary concern.
They might prefer a functional specification so that all of the requirements are included in one document. Or, if they are using agile methods on their project, they may prefer a collection of user stories with a few selected visual models to tie the requirements together. In light of your team’s preferences, you might choose not to write use cases even if they’d be a logical and appropriate choice otherwise.
(On the flip side, if your technology team has been asking for a simpler solution to a functional requirements spec, you could run a few use cases by them and see if they work better than your current process. Or, you might find that you do your best analytical thinking by writing use cases and so create some working drafts that do not become part of your final work product.)
How to Choose Your BA Deliverables Wisely
There is no one type of business analysis deliverable that must be created in all situations. Smart BAs make smart choices based on the type of requirements they are specifying and the needs of the project team. Make a choice that you can defend and start with it. Seek feedback and iterate until you find a deliverable mix that works for you, your business stakeholders, and your implementation team.
When in doubt, remember that it’s not likely your project is destined to fail if you choose a technique that’s not a perfect fit. You’ll have many opportunities to course correct as long as you pay attention to feedback and keep an eye on your project’s scope along the way.
Learn How to Create Use Cases
(and Wireframes Too)
Interested in learning how to write a use case? 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.