Some call them user stories, others all them use cases but all in all they serve much the same purpose: to align the business and the technical interests in a project. Use cases have many benefits when used correctly and I have seen them used effectively in several different areas of life including healthcare standards, software development, and family decisions.
Use cases are beneficial in many ways. At the very basic level they bring needed clarity to any given situation by stepping back to consider what it really is that is trying to be achieved. I’ve seen so many software developers that just jump in and start designing and coding without vetting the business requirements first. And I know this especially well because I used to be one of those developers (it is an impulse problem, and as a developer gains experience he/she should learn to control it) . Use cases act as a bridge between the business and technical interests by providing a communication path for these different groups. In earlier software design and development models the generally accepted approach was to thoroughly vet the requirements, which included use cases, by the business analyst/product team. Once everything was vetted properly, which could take months, documentation was handed off to the development team to execute on them and deliver software. The problem with this model is that there is little to no communication between those two groups. As we have learned in the past decade or so requirements often change before software is delivered to the field, and methods have been created to combat this challenge. Use cases and user stories are often used as a central discussion point in support of such methods. Use cases also bring confirmation of the goals of the project by illustrating what the software (or whatever the use case is being applied to) is supposed to achieve. It is a way to “check your answer,” similar to what one would do to validate a math problem.
I have much experience with use cases in the realm of healthcare information technology standards profiling in my work within Integrating the Healthcare Enterprise (IHE). A profile in IHE provides implementation guidance for systems in the healthcare domain. One of the base level requirements of a profile is a use case, or set of use cases. I have been involved in the development of over 15 IHE profiles over the past several years and every time I discuss a profile with someone, be they architects, engineers, product managers or VPs, I always get back to the use case at some point. It is a very effective way to center the conversation around one central goal, consistently representing the message across and between these different groups.
Use cases can often be effectively applied to planning family excursions as well. My wife and I are very fortunate to have four children, and this means that we must thoroughly think through any vacations we plan, day trips or other traveling we may choose or be required to do as a family. Although we do not use the same terms as I would in my professional career, we use the concept of use cases constantly by playing out what our trip will look like. For example, say we are planning a camping trip, we need to plan what to bring (because no one wants to be stuck in the woods without the necessary supplies to care for a two year old). So we could play it out in conversation, my wife may say to me “Honey, we will be changing a few diapers while we are in the woods so we will need to bring plenty of supplies.” And I may say “Ah of course! This is a fantastic idea and makes complete sense! Let’s be sure to pack those items so we do not end up in an undesirable situation.” This of course is a bit of a stretch because we would not necessarily need to have such an explicit conversation. At this point in our child rearing experiences we inherently know that diapers, wipes and a sealable trash bag are a must on our packing list. However the point I am making here is that all of us do this in our heads on a daily basis, whether it is for a camping trip, a grocery store run, or something else that needs to be planned. It is a natural part of our psyche, so it makes sense that this can be effectively applied in a work situation as well.
In the event that use cases are not used for a project or at least not done so properly many negative consequences may occur. The worst case scenario would be a complete mismatch between what the stakeholders are expecting and what the development team delivers. In the camping trip example this would be the failure of one spouse delivering what the other spouse is expecting. Projects that fail to keep communication lines open between stakeholders and the development team are at a very high risk of this landing in this situation. It is easier than you might think to accidently “fool” the stakeholders of what is being developed. Without consistent hands on functionality demonstrations and reviews it is hard to really get a pulse on how closely aligned the development work is aligned with the project requirements.
Use cases help to mitigate this risk by bringing together all parties on agreement and understanding of the story the software should tell, that is, the functionality that the user will interact with, the problem being solved, and how from any end user’s perspective it solves it. Not using use cases usually results in the developer writing code as directed but without at least in part understanding why. This results in a high risk of delivering a solution that is far off the original target as understood by the stakeholders. In the camping example from above this would mean a messy situation in the middle of nowhere. In which case I would at least hope there is a water source and the temperature is not too cold! In a work environment this means money lost, unhappy customers, or worse: patients not properly cared for because the system the clinician is using does not provide the appropriate functionality.
Use cases need not be complicated. If you are in doubt of how to start my suggestion is just to write a short narrative of what you want to accomplish. If you find your narrative becoming overly complex then split it apart to more manageable pieces. Most importantly remember that use cases are meant to help clarify the business requirements, improve communication and ultimately create better results in whatever situation they are applied to.