Requirement Elicitation: Stories Are Not Requirements

Introduction

Requirements Elicitation is not an exact science. The International Institute of Business Analysis (IIBA) defines ‘requirement’ as follows:

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met of possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability, as in 1 or 2.

The BABOK definition has been crafted to ascertain that what is verbally expressed does not arbitrarily limit the true definition of a requirement predicated on poor notions about the problem domain. Further, a requirement can be defined at any level of detail or depth that is obligatory in order to accurately convey the condition or capability. For example, it can be defined at an enterprise level, a divisional level, a process level, an activity level, a task level, and so on.

One of the three activities encompassed under Requirements Analysis is the process of ‘ Requirements elicitation’. IIBA’s definition of ‘elicitation’ is “An activity within requirements development that identifies sources for requirements and then uses elicitation techniques to gather requirements from those sources.”

However, this definition appears incomplete from an analyst’s point of view as it relies solely on the assumption that one can come up with requirements only by running elicitation techniques; however, the process of elicitation is not as simple and straightforward as it seems. Let’s see why.

Requirements Elicitation Techniques

Numerous requirements elicitation techniques have been identified and documented extensively in the business analysis literature. Some of them are listed below:

1. Workshops
2. Interviews
3. Focus Groups
4. Brainstorming
5. Document Analysis

As explained above, requirements elicitation is non-trivial because one can never be sure of getting all the requirements from the user and customer just by asking them what the system should or should not do. This process is not an exact science, and there are endless scenarios where this process takes place. A complete requirements elicitation process involves an analysis that kicks off once the necessary data has been elicited. Once you start off with the hands-on technique, you realize that it’s quite arduous to do as a stand-alone activity. For this very reason, most business analysts prefer to use a combination of two or more of these techniques.

These techniques are human interactions where ‘anything can go wrong’! Human interactions basically involve communication, either verbal or non-verbal. All communication has two components: a sender and a receiver. The sender has a message he or she intends to convey which she or he can put in words such that it best reflects what she or he is pondering over. But numerous obstacles can get in the way, thereby preventing the intended message from being received accurately. For example, a verbal communication can totally change the interpretation of the message just by the tone of the speaker. Even a mundane interaction may involve faulty communication, but it is the conflict that works out to worsen the problem. When two people have conflicting ideas, they often make negative remarks about each other. Consequently, a verbalization that might have seemed innocuous when two parties were friends might seem truculent or threatening when the same parties are in conflict.

The information exchanged between humans is raw, imperfect, and sometimes biased.

End Users Are Storytellers

I have observed that during requirements elicitation activities, the participants tend to tell stories rather than requirements; it is human nature. For most people, storytelling implies sharing their own experiences and allowing others to be enlightened through them or sharing what they have learned. For others, storytelling is edifying and relating to others.

Research has shown that stakeholders prefer telling stories rather than coming straight to the point. This is because we relish the opportunity to be acknowledged and understood.

Where are the ‘requirements’ in the story?

When the requirements are elicited, do the users provide details? They tell story, not concept. Jonathan Gottschall, author of The Storytelling Animal, says science backs up the long-held belief that story is the most powerful means of communicating a message. People tell stories because it is a part of human nature; we like to tell stories, read books, dramatize TV, cinema, etc.

In the requirements elicitation context, business users tell stories because they like to be heard and understood. They also try to detail out the things that they do as a part of their daily routine, which may at times involve sharing of vivid experiences, their pain, highs and lows in life, etc. Story, they believe, is the most suitable medium to make one understand their plight.

However, stories can have both germane and impertinent facts and often are too detailed. ‘Conceptualization’ is converting the story into an abstract statement using the relevant information. From the story abstract, analysis can be carried out to derive the problems that need to be addressed.

Stories are factual and a great source of information; however, they are unstructured. The narrative aspect of the story sometimes makes it long. However, people have different storytelling styles; for example, some will get right to the point of the story, making the life of a business analyst easy, while others may go on unendingly.

Let’s use this analogy to put this theory into perspective. Sherlock Holmes walks into a crime scene—

1. He makes some observations and takes down notes.
2. He interviews the witnesses, who tell him their stories. (What have they seen? What do they know? What do they think? Etc.)

Now what has Sherlock been able to extract at this stage of intelligence gathering? Two things basically: a) stories as narrated by the witnesses he questioned; and b) some other facts obtained from the crime scene. He still has a long way to go. He needs some serious backward reasoning; additional facts to discover, synthesize, and analyse from the whole scene; and the stories before he gets to the question of “What has transpired?”

This is one of the major drawbacks of BABOK illustration. It assumes that elicitation techniques will produce requirements on their own. We are called ‘analysts’ for a reason! Relying on inputs from elicitation techniques to deduce requirements is not ‘analysing’. Then what is ‘analysing’ or ‘analysis’?

Analysis involves a step-by-step breakdown of the phases in which a process has occurred that conveys the inputs, outputs, and operations that took place during each phase. A process analysis can be used to improve understanding of how the process operates or has operated in the near past and to determine potential targets for process improvement through abstracting waste and incrementing efficiency.

Conclusion

We are called ‘analysts’ for a reason! We don’t merely hear stories and convert them into ‘requirements’. Our integrated value lies in going above and beyond the story and expanding beyond engendering deliverables. We coalesce critical thinking and intellectual curiosity to transform stories into abstracts and to propose the needs as well as what the problem really is.

Author: Adam Alami, PhD Fellow, IT University of Copenhagen

Adam Alami is a PhD fellow at the IT University of Copenhagen. Adam has a wealth of experience in information technology practices. He started his career as a software developer, then moved to business analysis and project management. His 20 years’ experience revolves around major business transformation projects and process improvement. He accumulated a wealth of cross industry experience in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.