People sometimes like to dive right in to requirements definition by simply starting to write them on a blank sheet of paper – or blank Word doc for those of us who have gone completely green. Starting the requirements definition process this way can be very intimidating at best and full of oversights, omissions, and conflicts at worst. Even if you define and document scope in detail as I’ve discussed in the past, it’s still a big leap from a scope document to detailed requirements. Customers often have a hard time with requirements and you certainly can’t write all the requirements for them. You can help … but be sure to bill for it.

Use cases are a simple, cost-effective way to build a consensus among stakeholders and to discover missing requirements. They tend to address two large classes of requirements errors – omitted requirements and conflicting requirements. While drilling down further into requirements, the customer – usually with your help – can utilize use cases to get detailed requirements across all life-cycle phases to support the requirements definition process.

Why develop use cases?

Use cases are relatively easy to generate. The customer must access their stakeholders and subject matter experts (SMEs) to get well-thought out use cases that can be used to derive detailed and meaningful requirements for the engagement. Below are some of the reasons and pluses for generating these use cases:

  • Use cases are intuitive and easy to generate. Creating use cases are like storytelling. It comes naturally to most people. Simply imagine the operation of the future product or system and document the steps in using it. People from many different backgrounds and user perspectives can quickly get into creating these scripts. It’s easy – and very productive - to involve customers and users in the creation of use cases.
  • Use cases are in a language that everyone understands. Use cases are effective in communicating with users and developers alike. They bridge the domain experience gap between customers, users, and developers.
  • Use cases reduce the debate. Creating use cases do not usually kindle the fiery debate that requirements definition discussions often do. Yet use cases generate good requirements. Most people have use cases in mind when they try to write requirements, even if they haven’t formally documented them. Unless the use cases are documented well first, the differences that arise in people’s thought processes can’t be visualized by the group and debates arise.
  • Use cases facilitate complete and consistent requirements. Correcting what you have is easy compared with determining what you are missing. People tend to focus on the normal operation of a system or product in an ideal environment when they write requirements. In reality, this normal operation is not often the case. The requirements definition phase is the time to consider issues and risks that can come up and make those part of your use cases.
  • Use cases identify user interface issues early. Human interfaces are often the greatest challenge a development team faces. Too often, their implementation is just a fallout from the rest of the design effort. Use cases will show how personnel resources interact with the system or product as well, not just system interfaces. As the concepts are developing with use cases, you’ll see where the system may require data entry fields, etc. that would require a human interface.
  • Use cases offer inexpensive opportunities for early validation. You can take use cases to a wide variety of customers, users, testers, etc. to get feedback on what is feasible. This feedback will help fill in gaps, find inconsistencies, and correct issues before they really become issues.
  • Use cases form a foundation for testing scenarios during user acceptance testing (UAT). Scenario-based testing is one of the best ways to flush out problems before the system or product is rolled out. If the UAT team runs through verifying the requirements in the order they appear in the requirement specification or an order that minimizes verification time and resources, they will check off all of the verification boxes but risk missing problems associated with the transitions. Use cases can become realistic test scripts to guide the UAT team.

Information for this article was derived, in part, from Hooks and Farry’s book “Customer-Centered Products.”