Making the case for use cases
You spent months, and millions of dollars developing that fantastic new system. Only, when it was unveiled, it fell short of expectations. What happened? Who is to blame? How do you avoid it from happening again? If this sounds like your last project, don’t feel bad. It has happened to many project teams. And how do you prevent it from happening in the future? The key to true project success, is not just requirements, but requirements that are understood and agreed upon by all. IT Systems are developed to support business processes and decision making. Building successful systems requires close collaboration between stakeholders, business users, and IT staff. Getting these parties to the table and speaking the same language can oftentimes be a barrier to IT project success. The key to overcoming this barrier is through solid software requirements that are easily understood by all parties involved. One answer to that problem is Use Cases.
What Are Use Cases and How are they Used?
According to Karl Wieger, use cases offer “the ultimate goal of software engineering: to create products that let customers do useful work.” To put it another way, a use case, represents an easy to follow series of steps that outline a user’s interaction with a system. According to the book, The Unified Software Development Process (Boch, Jacobson, Rumbaugh), A use case is a piece of functionality in the system that gives a user a result of value. It is important to note, that the term user not only refers to humans, but other systems as well. Use cases define business process in a manner that makes it easy for IT staff to understand. This process-centric approach to software development removes the technology from the requirements gathering process, and focuses on true business needs. Use cases allow for a more process-centric approach to software development, rather than a technology-centric approach. By allowing the business process to drive requirements, you minimize the risk of delivering a solution that vastly differs from what the stakeholders envisioned. In addition, use cases foster a level of interaction between stakeholders and IT staff that promotes greater ownership and buy-in of the final product.
What are User Stories and How Do They Differ From Use Cases?
User stories are similar to use cases in that they offer a way for the business and IT to communicate about requirements in an easy to understand format. They differ from use cases however, in their format and function. User stories represent a quick way to present requirements without having to deal with the overhead of creating and maintaining formalized requirements documentation. It is popular in Agile Development methodologies because it allows the team to be flexible and adapt to change. User stories are usually no longer than what can be captured on a note card. This is quite different from use cases which are normally comprised of a formal use case document accompanied by a use case model. You could say that user stories represent an informal method to capture requirements, and use cases offer a more formalized and documented approach to capturing requirements.
Which One is Better and When Would You Use One Over the Other?
Both use cases and user stories have their place in the requirements gathering process. Each serves as a tool for communication between stakeholders and IT. Additionally, each provides a means for the stakeholders to describe their requirements in a process-centric fashion. Which one you use depends on several factors including size or complexity of the project, development methodology for the project, and experience of team members involved in the project.
Why Use Cases are Often More Appropriate
Use cases are great for projects that are large or complex in nature. In addition, projects that have significant regulatory or security implications would benefit from the structured and more formalized approach to requirements offered by use cases. By documenting requirements in a formalized manner, stakeholders in such projects are able to more effectively manage the risks associated with such complex projects. Requirements Gathering for IT Projects does not have to be a frustrating experience. When stakeholders and IT staff are able collaborate using a methodology that is agreed upon by all, the result is a finished product that closely matches the needs of the stakeholders.