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….
As a journalist, I've enjoyed getting to know people in the worlds of art, computers, video, and the web.
As a conceptual artist and concrete poet, I absorbed a lot from brave audiences.
As a teacher, I've learned enormously from my students at NYU, Rutgers, the Shakespeare Institute, UC Berkeley, UC Santa Cruz, New Mexico Tech, UNM, and professional organizations such as the ACM, IEEE, and STC.
And as a writer, I've always gotten a kick out of working collaboratively with other writers.
I live in New Mexico, along the Rio Grande, with two dogs who chase away balloons during the annual fiesta.
My wife Lisa is a writer and retired director of operations at a call center.
My son Ben runs an insurance office here in town, and Noah is off in San Diego.
Me, I'm busy doing art pieces, fiction, and a bunch of writing about art on the web.
You can learn more about all of us in the books...and our blog: