Telling Stories
Once upon a time, it was well understood that stories teach better than plain facts. Why then are most software requirements documents a baffling hodge-podge of diagrams, data dictionaries, and bullet points, held together by little more than a name and a staple? Telling Stories teaches you to combine proven standards of requirements analysis with the most ancient and effective tool for sharing information: the narrative. Telling Stories simplifies and refines the classic methods of Structured Analysis, providing organization, design, and old-fashioned writing advice. Whether you're just getting started or an experienced requirements writer, Telling Stories can help you turn dull, detailed material into an engaging, logical, and readable story, a story that can make the difference for your project and your career.
- Learn why readers believe and remember what they learn from stories
- Work with team members to gather content, tell their stories, and win their support
- Use stories to find every requirement
- Create diagrams that almost tell the story on their own (while looking clear and professional)
- Explain everything important about a process
- Use precise language to remove the ambiguity from requirements
- Write a forceful executive summary that stands on its own and sells a project to senior management
- Summarize often to keep the reader focused on key issues
- Structure the document so every part has a clear place and purpose
Review By: Cathy Bell
08/19/2010Can writing software requirements really be as easy as telling a good story? The author believes it should be and explains how his process simplifies requirements gathering. He also provides tools for organization and design in addition to writing advice.
I feel this book was written for a nontechnical person, to assist them in understanding what writing requirements is all about. The author does not go into the gory details, but rather works on the premise that we all either know how to gather requirements or we can find training on the subject. His advice in this book is meant to make us better at the tasks involved. It will also be a good book for someone with a lot of experience in writing requirements who always wonders why others may not be able to follow what they have written. The story-telling method in this book can help a technical person learn how to dumb down their documents so nontechnical folks will understand.
As an example, think about teaching teenagers how to drive. You do not take them to the car and proceed to explain that when the key is turned it sends electricity to the starter solenoid and how the solenoid is really a relay to send power from the battery to the motor. By the time you finished explaining just the first small piece of this process, they would be lost. What good would that do because they most likely would not be able to relate what you just told them to the task at hand. What's the solution? We need to engage readers. To do this, we need to lay out a story that is easy to follow. As with teenagers who may never need to know all about the workings of an internal combustion engine, we have to tailor our story to our audience. He shows how story telling will guide those on the project in a logical, sequence of steps. The author also explains that we can use a simple diagram to illustrate the current state of the project and the final state of the project, sort of like a visual executive summary, with all the supporting documentation available for those who need to know the details.
The appendix, which is available for download on the publisher's site, is a high-level overview of the book’s contents. It is a useful quick reference guide that highlights the major points of the preceding chapters and directs the reader to the book for more detail.
The book is easy to read, and the authors argument for story telling being a valuable tool for software requirements is supported by the illustrations he gives through out. Some probably read this title and think the author is advocating burying folks in the proverbial bull dung, but throughout the book we are reminded that clarity, brevity, and precision are vital qualities of effective requirements. A good requirements document should be like a good book, clear to the reader and all points leading to a logical conclusion. We should always remember, as the author states at the end of the book, "long after team members have moved on, the requirements documents can (and will) tell the story of the project."