Write a Use Case: Gathering Requirements that Users Understand

Quick: Is this book for you?

Yes, if you want to craft requirements that are:

• Focused on user goals, tasks, and benefits
• Consistently organized, complete, and clear
• Understood and agreed-to by both stakeholders and developers
• Discussed extensively and collaboratively updated
• Used as a blueprint for code that meets or exceeds user expectations
• Transformed into test cases that measure your success

You’ll learn how to create a series of artifacts:

1. Descriptions of user needs, requests, and dreams
2. A list of features that might satisfy those demands
3. An overall vision for the proposed product
4. A set of requirement statements, if you must (deprecated)
5. .A model diagramming all the possible use cases
6. Use cases that make sense to both stakeholders and developers
7. Test cases that prove that the code meets user goals
8. User stories, for smaller, more agile projects

What’s included?

• Step-by-step instructions for creating each elements
• Explanations of the why behind the how and the what
• Lots of yes-and-no examples
• A formal architecture that works with structured writing tools and content management systems
• Advice and tips based on the experiences of many writers working with development teams on large and small projects for consumer, corporate, and government customers
• Checklists for heuristic evaluations
• An index

This is a writer’s guide. Use cases help stakeholders and developers reach real agreement on what needs to be built, reducing the chances for disappointment and disaster.

As a compiler of the requirements, you make a meaningful contribution to the success of the project, clarifying goals, avoiding misunderstandings, clearing away a lot of possible defects, reducing life cycle cost, and increasing speed to market.

Yes, you have to analyze the customers’ business in object-oriented terms, but this book is not aimed at programmers, or business analysts. And, yes, use cases make it easier for managers to track backlog, burn rate, and priorities for each phase of development, but this book is not aimed at project leads, scrum masters, or managers. I’m writing for writers.

If you are accustomed to working in a structured framework, you’ll find this approach familiar, with clear definitions of each element, standard patterns, and well-beaten paths through the process. You are creating content, not documents. Your focus is on an ongoing process, as you revise, test, and revise again. These ongoing conversations are, ultimately, more important than the artifacts.