Well-written use case narratives (or simply "use cases") offer the analysis, development, and testing teams an invaluable guidebook. A use case (different from a UML use case diagram) is a formalized story that describes how someone procedurally interacts with an existing or proposed system and they should be part of every project managers' permanent tool set.
Introducing use cases
Imagine flying to an unfamiliar foreign country where you plan to rent a car and tour the sights. Most people wouldn't consider starting this trip without a good guidebook. Despite the obvious value of a guidebook's roadmaps and narratives, we information technologists too often embark on software development projects without them. As a result, development teams often wander far from the project objectives - at considerable expense and delay.
What does a use case look like? The document, Customer gets cash from an ATM, available in the download version of this post, represents a detailed description of a business process. The structure of this sample use case reflects a framework I've designed and used in several large projects. While the structure of my use cases differs somewhat from Cockburn's, it accommodates what my analysis teams have generally needed to capture process requirements.
The TechRepublic download version of this blog post is in the PDF format and includes the example use case.
I routinely encourage analysis teams to develop use cases. Here are ten reasons why they are part of my permanent toolset.
Use cases help the analysis team...1. Improve communication among team members
Collaborative effort enhances the success of any team. As the team members work to describe business processes, use cases provide a repository of team members' business knowledge. As a written document, each use case spawns meaningful discussion within the group. The axiom, "the whole is greater than the sum of the parts", applies here. Group discussion exposes in-depth viewpoints that would otherwise remain hidden. With use cases, the team captures these perspectives while identifying the related business goals, conditions, and issues. The result is a comprehensive and meaningful story about each business process.2. Encourage common agreement about system requirements
The process of writing and revising use cases produces three important outcomes in the analysis team -- clarity, consensus, and commitment. Remarkably, it is common for stakeholders to be uncertain about how a process they own actually works! Writing a use case helps stakeholders align the narrative with the details of an existing process.
In a recent project, it became clear that stakeholders could not agree about the specifics of several core processes. However, consensus came quickly as the team wrote and revised use cases. For many stakeholders, these written documents offer a foothold on a sometimes bewildering mountain of complex business processes.
Remarkably, use cases often help stakeholders reach common agreement on "best practice" processes as well. In a facilitated group setting, divergent perspectives are welcomed, understood, and appreciated. As a by-product of this agreement, team members inevitably commit to support improved processes to both management and peers.3. Reveal process alternatives, process exceptions, undefined terms, and outstanding issues
I always have the analysis team start a use case by developing the "Main Course of Events" (see the sample use case). As the group develops a coherent and ordered set of process steps, team members tend to volunteer statements that begin with the words "what about..." - a clue to previously unidentified "Alternative Paths" to a successful outcome. The "Exception Paths" often arise in a similar way. More of these become obvious when the team considers what happens if any step in the "Main Course" fails.
As the facilitator of team meetings, carefully listen for any jargon used by stakeholders. Write these terms down in front of the group and ask for a definition for each one. Later, you'll add these definitions into the project glossary. Also, listen for issues as they arise. Is a process step fuzzy? Is there an area that needs more research, or an item on which team members disagree? Write these down as well and later include them in a project issue log.4. Expose what belongs outside project scope
Constraints on the project may limit resources and/or the project timeline. As a result, the analysis team may need to prioritize development work, or separate project deliverables into phases. You can help the analysis team by creating a catalog of the use case titles, and arranging them into some meaningful order (e.g., by sub-system or umbrella process). With this catalog, the analysis team can prioritize the use cases. They may decide that some fall outside the project scope, or that some are not needed in the first project phase. Either way, you have given the stakeholders an opportunity to declare which functions they need the most, or which ones they need first.5. Transform manual processes into automated processes
When software is being designed to automate aspects of an existing system, the analysis team usually begins by writing "as is" use cases to describe the current business processes. While this effort is time consuming, the result is valuable. Besides revealing the details of an existing business process (including business rules, alternative paths, and exception paths), you will create a launching pad for the team's imagination. As they are writing the use cases, they often discover an improved process, recognize unnecessary steps, or reach agreement on "best operational practices".
The "as is" use cases may also allow the system architect to propose high-level process flow diagrams that represent how the new system could work. While the first attempts may not be viable, iterative review and revision by the analysis team may generate a workable architecture for the new system.
Use cases help the development team...6. Understand business processes
Software developers often lack an understanding of the customer's business. It is easy to forget that software systems should help business people get work done -- effectively, efficiently, and inexpensively. To achieve these objectives, the development team must understand not only the business process the software must support, but also the process' alternatives and exceptions. Use cases provide this information in clear, structured language that developers can readily understand. Use cases also offer a valuable perspective on the stakeholders' business goals, assumptions, and operational rules. These features provide developers with a solid foundation for developing cost-effective solutions to business challenges.7. Recognize patterns and contexts in functional requirements
Developers may view a set of use cases horizontally. For example, one use case requires a customer lookup function. Another use case requires a similar function but with customer data sorted in a different order. The clever development team can find such patterns within a set of use cases. Patterns are often discovered in the "Business Rules" section of use cases as well. Developers may transform these patterns into universal software objects.
As another aid to developers, use cases also reveal operational context. The "Stakeholders Goals", "Pre-Conditions", "Assumptions", and "Post-Conditions" give developers a sense of how the software will be used. By reading these sections, the developer understands what the role identified in the use case is trying to accomplish, and what motivates him or her.8. Prioritize work
Although the analysis team may have prioritized and winnowed the use cases, the development team views them from a far different perspective. As a good development teams writes code, they search for coding efficiencies. While the analysis team may want 12 use cases completed in phase one, the technical manager and the development team may see cost-savings in delivering phase one software for the 12 use cases, plus two more from phase two that are cheaper to build as part of phase one. Of course, the analysis team and the development should jointly consider the effect of this change.
Use cases help the testing team...9. Discover gaps between the requirements and the delivered software
Some years ago, I was asked to join a troubled project in which the system design phase was nearly complete. Unfortunately, detailed functional requirements were no where to be seen, and the developers had already begun writing code! In order to catch up, I taught a team of functional users to write use cases themselves. Although we completed the narratives quickly, the developers largely ignored our use cases.
That condition changed, however, after the developers installed their first software release. It was clear to us that critical features were missing. The rooky analysis team and I compared the delivered software to our use cases. Although we created a long list of missing features, we challenged the developers to close the gaps rapidly. The next installation was acceptable.10. Ensure the delivered software works properly
While use cases significantly differ from test cases, the former may be used to derive the latter. The "Assumptions", "Pre-Conditions", and "Post-Condition", "Main Course", "Alternative Paths", "Exception Paths", and "Business Rules" sections are all source material for creating good test scripts. Bundles of use cases organized into system-wide process flows become a source for writing comprehensive end-to-end test scripts. As an added bonus, the testing team develops test scripts from the use cases as the development team begins its work. The test scripts are now ready for use as developers complete programs.
While writing use cases may seem time consuming and tedious, the result is a foundation for work by the analysis team, the development team, and the testing team. Use cases provide a valuable return on the analysis team's investment in time and resources.