A story is defined as a narrative or tale, true or imaginary. Each story has a moral hidden in it. A story writer won't directly say that hard work and patience is the key to success. Instead the writer came up with a story of Hare and Tortoise. And if we observe carefully, stories are everywhere; we ask a friend about her love story, we watch a prime time news story, we ask a new friend about his life's story, the movie I watched the other day had a good story.
Stories are everywhere and our minds are conditioned to listen to them and learn from them. When we listen stories, we imagine them and try to visualize them. We associate ourselves with the actors and events and we try to fill in the gaps that are left out. We are more likely to remember things when we make a connection with them. For instance, if we want to remember and recollect the word "Mango", we are more likely to recollect it if we imagine holding a big ripe mango, its aroma and exquisite taste. The more connections with make with the story, the more human senses (touch, feel, smell, taste and see) we use to associate with the story - the more likely we are to remember the story.
The main skill of a Business Analyst is to equate requirements as stories. Every story consists of 3 main parts: Characters, Setting, and Plot.
Characters are the people in the story. These are the actors in our requirements. Just like a story has primary and secondary actors, requirements also have primary (generally humans) and secondary actors (generally the external systems or programs). Actors drive the story.
Setting deals with the time - past, present or the future - when the story takes place. This is analogous to documenting a system that is already built (or documenting an old legacy system), documenting the present system (AS-IS) and documenting the future system (TO-BE). Setting also includes the general background and the overview of the problem we are trying to solve. Plot deals with the events and actions that happen in the story.
Plot is analogous to processes in the business requirements. The processes happen in a specific order to reach the desired outcome, the interdependency among the processes and how one process triggers the next forms the plot in business requirements. Models and process diagrams go hand in hand with the plot. Use Cases, flowcharts and swim-lanes, BPMNs effectively describe the plot of the requirements.
Apart from the above 3 parts, requirement documents have certain characteristics which may or may not be applicable to stories. Using clear, concise and a simple language to write requirement documents. Although stories like Interstellar and Inception are massive hit with the audiences, I am pretty sure requirement documents written in such a style would make the readers desperate. People reading the requirements expect a structured and clear description of each process and a summary at the end that links everything together.
This article is based on the book "Telling Stories: A Short Path to Writing Better Software Requirements" by Ben Rinzler.
Author: Saurabh Shah