In my previous post, I talked about how business analysts and product managers who are putting together requirements documentation can and should think of themselves as storytellers. By thinking of a Business Requirements Document (BRD) or a System Requirements Specification (SRS) as a narrative, with a beginning, middle and end, we can tell a story to our project team that helps make sense of the problem that our development project aims to tackle. My previous post talked about the importance of framing the narrative in the introduction, both for literary stories and in our requirements documentation. After framing the problem and providing the setting, it’s time for the action!
The Middle and The End
After providing the reader with sufficient context and explaining what the central problem or conflict in the story is, most authors begin the actual narrative of the story. This is where most of the excitement in a story lies. In the business analyst world this is also true! Requirements are the meat of any BRD or SRS, and these are where most of the actual action in our documents takes place. The sections of your document that contain the requirements can also tell a story.
At ArgonDigital, we like to introduce any group of requirements with a process flow or group of process flows. Process flows are like mini-stories, describing how a user accomplishes a task. They interact with other users, they are faced with decisions, and ultimately they succeed (or in some exception scenarios, they don’t). By presenting process flows before we dive in to the requirements, we can provide a narrative framework for the reader to understand a specific requirement.
We like to create explicit links between the requirement statement and a certain step in the process flow above so that the reader can contextualize the requirement in the larger story. The reader can start to see how requirements fit in to the larger picture of the end-to-end process being described in that section, and how that end-to-end process helps provide a solution to the problems we presented in the introduction.
At the end of a good story, there is some resolution. The characters overcame the obstacles that challenged them, they resolved their disputes, and they live happily ever after. And hopefully the reader finishes the book feeling satisfied. The goal of our requirements documents should be similar. After reading our document or finishing a review session, the consumers of the document should leave understanding how the business problems that we presented in the introduction will be resolved. Our readers should feel comfortable that the requirements we wrote will solve the issues they were intended to solve, because the structure of our document made the narrative easy to follow.
Obviously, there are major differences between a literary story and the story told through a requirements document. The major purpose of literary stories is to entertain, while the purpose of requirements documentation is to inform. By and large, literary stories flow all in one direction, from the storyteller or author to the reader; there is not usually dialog occurring between the reader and the narrator.
In requirements documentation, however, this is not the case. The consumers of the requirements documentation should provide feedback to the business analyst that created it. But I don’t think these differences matter too much. On the contrary, thinking about your requirements documents as a narrative helps to provide the context that the consumers of the documentation need to understand the requirements. If they understand the requirements, they will be much more likely to provide feedback, and the feedback they provide will be more valuable.
Have you ever thought about requirements documentation as a story? If so, what techniques do you use to tell it?
