Telling Stories: A Short Path to Writing Better Software Requirements
From System Designers to Top Management, Everyone loves a good story
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.
What people are saying - Write a review
The thesis is that there is an analogy between writing requirements and a story. The book is concise and readable and formalizes a requirements method. The instructions show how to illustrate dataflow and UML. There are outlines and a document template. The outline formats differentiate an Agile version from more robust. Scenarios are used to show the success and exception results of each application process. The latter word is used in several contexts such as for the requirements themselves, for the system, and for the software elements. It assumes that the review considers feasibility.
This title is a happy medium as an anecdote, however the full length treatment is full of caveats. A story is a narrative, where the requirements are more of an agreement. There are a lot of differences. The audience of designers, for example, will have an expectation that there is enough detail for them to do specifications. System analysts and testers will seek to itemize features and constraints so that they can be tracked throughout the development and validation processes. Perhaps the story explains the why’s, the requirements the what’s, and the designs do the how’s. It does list usability testing and brings up availability, for example.
In summary, marketing presentations might lean more heavily on the story side, and software on objectives. Other approaches along these lines have included object-oriented parsing of text to objects. Scenarios and scenes are also used in test descriptions, e.g. use cases. Analogies are used in technical documentation. Complementary approaches might also include user actions as problem-solving or decision trees.