Write a Use Case: Gathering Requirements that Users Understand - Softcover

Price, Jonathan Reeve

 
9780971995451: Write a Use Case: Gathering Requirements that Users Understand

Synopsis

Quick: 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 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.

"synopsis" may belong to another edition of this title.

About the Author

I regularly work as a writer and consultant in high-tech environments, gathering requirements for hardware and software projects.  My clients include an A to Z of computer companies, national laboratories, and universities. I coach writers, business analysts, and developers as we build use cases, test cases, procedures, user stories, training materials, and information architectures.
Q: What's your background?
I spent four years as a Senior Technical Writer at Apple Computer, which was a little like being in graduate school: lots of intense, very bright people obsessing about obscure subjects (like laser printers, Chinese fonts, hypertext, and operating systems). I wrote a styleguide for the technical writers, called How to Write an Apple Manual, which morphed into How to Write a Computer Manual, which became, with the help of Henry Korman, Mick Renner, Linda Urban, and Adam Rochmes, How to Communicate Technical Information.
After graduating from Apple, I wrote a lot of help systems, and consulted with a wide range of high-tech firms on customer assistance, first within apps, then in the cloud. Along the way, I've gathered functional requirements for small, medium, and large projects in high tech corporations and national labs.
And through workshops and online classes at universities such as the University of California Extension at Santa Cruz, I've trained more than a thousand writers, business analysts, and programmers in crafting use cases, test cases, user stories, and good old-fashioned task topics.  
The folks I've worked with have all contributed to this book.  They asked questions, and I've added the answers.  They talked about what made requirements useful for developers, and they shared horror stories of projects that failed because of requirements that were inconsistent, incomplete, inaccurate, ambiguous, or worse. Together, we learned to avoid most of these pitfalls, while serving both stakeholders and the development team.

"About this title" may belong to another edition of this title.