Storytelling Techniques for Capturing Effective Requirements!

By M. Duvernet

Since the beginning of time mankind has enjoyed a good storyteller. A story that is simple and compelling can change lives and offer new perspectives on solving problems that the listener, or reader, may never have otherwise considered.  Stories provide a view of someone else’s challenges and ways in which a series of events can either make for a tragic end, or show how certain choices can make things right. Telling a good story is the best way to convey a message to inspire. So, as a business analyst what does the process of building a narrative do when trying to put a voice to the business needs as requirements are captured and documented?

Just like the abilities of a capable business analyst, the power of a good narrative is not something to underestimate. The fully competent business analyst understands their role and the importance of providing everything the project stakeholders are expecting, even if the stakeholders don’t know what that is. It is a discovery process sometimes for everyone, as believe it or not, many organizations lack the leadership to be responsible to the business.

According to an article entitled “The Power of the Narrative” by “” this lack of responsibility is an inherent problem for many companies as sometimes middle management does not have the vision that those at the executive level might. Often times business analysts are faced with businesses that do not even know what their processes are. In this type of situation the requirements effort can end tragically, going millions over budget, or facing failure…or in the hands of a competent analyst the effort can realize success and thus, a happy ending.

In the American Heritage Dictionary, the term “Requirement” is defined as “something that is required; necessary, obligatory; prerequisite.” However, getting at the requirements does not always render a solution. There is so much more that has to be managed, from communication channels to realistic estimates and deadlines.

The same “” article declares that as we all are consumers of information and as we have become more inundated with information, we have also become more inattentive. This is somewhat alarming, as throughout history people have always been interested in becoming more knowledgeable. So, how is it, that in an age when we have information at our fingertips we make a conscious decision to “neglect” the information? Perhaps it is because we have become confused about all that information, confused about what to believe and what not to believe. As business analysts it is part of our role to filter through all that information and hopefully find the “root cause,” the “source system of truth” or just the plain old truth; as expected in a good story.

But, getting at that truth is what inspires! If there is any sort of truth to the opportunities of doing more business, it is management’s objective to provide a vision to show the way, which will foster pride in the workplace, improve moral, and create optimism for growth. Good leaders know the power of the narrative, the power of storytelling.

As business analysts we can easily consider ourselves storytellers, for telling a story is a sure way to grab everyone’s attention. So let’s take a look at how to leverage the structure of storytelling to reinforce capturing and documenting requirements.

First one needs to understand the four steps involved in eliciting and capturing requirements:

Step 1: Business Case – Stakeholders create the business case, making a case will enable the business to improve organizational value.
Step 2: Elicitation – Often begins with stakeholder conversations in regard to the business needs (doing some research regarding the organization’s products and/or services is important to good elicitation.)
Step 3: Analyzing Requirements – Prioritization and organization of requirements as they are documented help to specify certain details and remove any ambiguity as completion deadlines loom.
Step 4: Verification and Validation – Making sure that the requirements map to the business needs and they can be traced toward valued results and back to initial business needs as approved by the stakeholders.

As for the basic story structure there are also four parts:

Part 1: The Beginning – Map out the story line by setting the stage and introducing the characters (The story line has scope, goals, and objectives pertaining to “the story value/concept”, while the characters are the stakeholders and their business processes and/or systems have assumptions and risks that add suspense.)
Part 2: The Body – Where there is suspense, there is conflict. What are the problem(s) and the opportunities? (The needs are defined, requirements begin to take shape.)
Part 3: The Climax – There is a point where the story builds in intensity toward a solution. (The business rules are described in detail along with any data attributes toward prescribing what data or results will prove the “value” essential to success.)
Part 4: The Resolution – Solution to the conflict, end of story. (The solution is described in detail, the results are traceable and viable, approvers have signed off, and end results fit the business needs.)

Using the structural story arch to simplify the task of writing requirements can be fun! The complexity and chances of getting “lost in the weeds” that are present with any project, fall by the wayside. Being able to simplify the task of capturing requirements offers an opportunity to strip away that complexity. Even if the requirements are epic in proportion thinking about the four major parts of story structure can aide in constructing the requirements documentation that will be most useful, gleaning only those necessary business needs in a clear, concise, and consistent manner.

As business analysts, we all know the importance of ensuring that our requirements be verifiable, clear, concise, complete, consistent, traceable, viable, and necessary, we also know that this never happens all at once. It takes several drafts to reach a state where all the stakeholders could confirm that the requirements documentation is indeed complete. The only thing any analyst can do is try to make sure that no useful information is neglected and that all the stakeholders remain “attentive.”


  1. I agree, stories are powerful tools we need to use more often. In fact, I often talk about the power of stories inside each requirement. Why use dull, uninspiring language (“The system shall …”) when we can use tiny stories that engage our users, stakeholders, and teams.

    Great topic, thanks for sharing!

  2. I must verify with you here. Which isn’t one thing I usually do! I take pleasure in studying a submit that will make folks think. Additionally, thanks for allowing me to remark!

Speak Your Mind