Apps

10 reasons why use cases are indispensable to your software development project

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 <a href="http://en.wikipedia.org/wiki/Use_case_diagram" target="_blank">UML use case diagram</a>) 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.

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.

Use case narratives were most notably popularized in Writing Effective Use Cases, by Alistair Cockburn.

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.

10 reasons

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.

Lessons Learned

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.

4 comments
don.gulledge
don.gulledge

How many versions or iterations of a development plan can there ever be. Ever since I?ve been involved with computers and development, I?ve heard plan definition after plan definition that always says the same thing under a new name. Life-cycle plan, development plan, project management plan, Case State plan, and on and on. One thing I?ve learned over the years is that the plan is only as good as the paper it?s written on. And, most are written on 20 lb copy paper. Someone can generate a lot of words and paper, that in essence gives nothing to the programmer, and does nothing to describe a coherent system of automated business rules. Seems like every BA I meet involving themselves in development have read this article or one like it and proceed to run the show, write a lot of words on paper, and then dump it on the programmers. And, if they stay true to form, they build a pert chart and try to nail down due dates that puts all the monkeys on the developers. I must say, you did include the what-if scenario which is usually the one that?s never done. But, I think they need to develop the science of describing automation functions and building a great spec for a development project for Business Majors or any one else that decides to build/manage a development and never coded a line of code. One that does encompass all the aspects like what reports are needed, is there data maintained to supply the report, what if, what if, what if?.. The one real problem that these things never overcome is the two human factors. Information hoarding (job protection) and just total incompetence. Seems like no plan ever gets past these two problems. It always ends of being new knowledge well into the developments and always puts the monkey on the programmer?s back. The plan is useless, if it can?t fully spec a system, can?t give the developer every piece of information needed so there?s no surprises.

brian.dobing
brian.dobing

A few years ago, we conducted a web survey of UML usage. The results of this survey have been published in several places, and a summary of the findings is available at: http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=461 We are now conducting a survey specifically on Use Cases. We are interested in responses from those who love them, hate them or anything in between. Our survey can be found at: https://www.uleth.ca/survey/uml/ This is an academic survey. All responses are confidential - only summary data will be reported. Let us know what you think! Thanks Brian Dobing University of Lethbridge

Justin James
Justin James

I agree that use cases can be quite helpful, for all of the reasons that you list. Here are some cautions for them too: * When you get in an "analysis paralysis" cycle trying to document every little use case, instead of moving forwards. * When use cases become the focus of attention, instead of the functionality itself ("no, I want them to click on the 'OK' button, not the 'Finish' button!"). * When use cases end up driving bottom up development; the focus ends up on the trees, not the overall forest. I have seen projects derailed by months by a use cases happy BA, and I have seen them be quite effective, it is all in how you use them! J.Ja

Locrian_Lyric
Locrian_Lyric

...the world becomes a nail. I agree with you. Use cases should be *a* tool, not *the* tool.

Editor's Picks