Is this book for you? Yes, if you’re a writer. Not a programmer. Not a suit. Yes, if you want to craft requirements that on user goals, tasks, and benefitsConsistently organized, complete, and clearUnderstood and agreed-to by both stakeholders and developersDiscussed extensively and collaboratively updatedUsed as a blueprint for code that meets or exceeds user expectationsTransformed into test cases that measure your successYou’ll learn how to create a series of Descriptions of user needs, requests, and dreamsA list of features that might satisfy those demandsAn overall vision for the proposed productA set of requirement statements, if you must (deprecated).A model diagramming all the possible use casesUse cases that make sense to both stakeholders and developersTest cases that prove that the code meets user goalsUser stories, for smaller, more agile projectsWhat’s included? Step-by-step instructions for creating each elementsExplanations of the why behind the how and the whatLots of yes-and-no examplesA formal architecture that works with structured writing tools and content management systemsAdvice and tips based on the experiences of many writers working with development teams on large and small projects for consumer, corporate, and government customersChecklists for heuristic evaluationsAn 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. Review in Technical "Technical communicators newly tasked with writing requirements will want to purchase Jonathan Reeve Price’s Write a Use Gathering Requirements that Users Can Understand to better comprehend their role in the process, avoid common mistakes like an overreliance on the development team driving requirements, and eliminate any second-guessing about exactly what they should be doing. This book is for writers. It helps writers create well-crafted requirements and a series of supporting artifacts as well as provides step-by-step instructions complete with examples….