Elicitation (BABOK KA)

A reader wrote to me with questions regarding a development project that he thought involved too many requirements and too little flexibility around requirement priorities. (You’ve never heard of such a thing before, right?) 

Imagine walking into a store and hearing your favorite song playing in the background. Instinctively, you feel more at ease, more inclined to browse, and perhaps even to buy something. This subtle influence on your behavior is no accident—it is an example of priming at work. Now, picture leveraging this same psychological phenomenon to enhance the effectiveness of business analysis. Welcome to the world of priming, where a well-placed word or image can shape perceptions, drive engagement, and ultimately lead to more successful projects.

Requirement elicitation, a critical part of project development, is often perceived as a purely technical process. However, this is not always the case. Effective requirement elicitation relies not only on technical acumen but also on an understanding of how human cognition, biases, and behaviors shape the process and what we can do to mitigate the negative influence of these inherent human factors. In this article, we selected three critical human factors: confirmation bias, the availability heuristic, and groupthink. These factors are commonly experienced in requirement elicitation activities. The article delves into the intricacies of these human aspects of requirement gathering and illustrates their impact using examples. We dissect the impact of these biases on requirement gathering, shedding light on the potential consequences that can arise when they go unchecked. Furthermore, we discuss strategies and techniques for mitigating these biases, emphasizing the role of requirements analysts as impartial facilitators.

There are several technological or stakeholder needs that are not officially listed but are of importance. Business analysts must identify the conditions necessary to access pertinent data; this is where elicitation techniques come into play.  Elicitation is the foundation of every project because it puts the project's requirements under the light. If elicitation is done wrong would lead to major failure and abandonment. Therefore, the elicitation process requires appropriate study and planning to prevent the likelihood of fatal errors impeding a project. But the question here is how can a business analyst gather requirements. In this article, we tell you the best elicitation techniques to collect information efficiently.

BABoK v3 techniques are a lot. There are not just 10, 20, or 30 techniques but 50 techniques, to be precise and that's not a small number!

The human mind can remember 5 to 7 elements at a time and anything more than that is hard to remember.

Then, how can one remember 50 techniques?

"Is it really possible to have a BABoK Techniques Mindmap?"

Many of you may wonder.

So, here's the Ultimate BABoK techniques mindmap which could save you 40 hours of your International Institute of Business Analysis (IIBA) exam preparation!

There are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.

Business knowledge is simply knowing your business—its facets, strengths, weaknesses, competition, challenges, positioning within the market, and readily available solutions to its daily problems. Strong business knowledge should inform everything you do.  So, what you learn and hear in discovery should be filtered through your business knowledge. What you define in your requirements should also be informed by your business knowledge. As one business analysis writer puts it, “I’ve always been of the opinion that I’d like to know as much as I can about whatever I can because you never know when something you learned may come in handy.”^[2] The following four areas are the ones, specifically, according to BABOK, that you’ll want to apply yourself to.

One of the biggest challenges now facing business analysts is this: how do we successfully engage with stakeholders, elicit requirements, and have productive workshops and meetings, without actually meeting in person? The tried-and-tested methods of getting together in a collaborative space, using sticky notes and whiteboards, and bribing attendees with baked goods, are no longer quite so straightforward in a world where some or all of the stakeholders are on the far end of an internet connection.

There are several factors to consider when moving out of the purely physical realm as a business analyst.

I was teaching a business analysis course recently and noted that few students had used a Fishbone Diagram along with the Five Whys for root cause analysis. This motivated me to write an article on root cause analysis using the combo method along with a short example.

What are the most common elicitation challenges? This is one of the most discussed topics from my business analysis training sessions. A business analyst extracts information in various forms, from various sources, and transforms those findings into requirements and design artifacts. Let’s take a look at some of the common challenges during the elicitation process and how to address them.

Integration requirements are critical for any Project’s success when Business Processes flow across multiple systems. As a Business Analyst it’s our responsibility to understand the end-to-end Business and Systems Process flow and document the hand off as part of the requirements gatherings process. A systematic approach to gather the requirements for integration between systems will ensure that there is a smooth interaction between the systems and hence the Business Process flow. The below Framework on Integration Requirements Analysis provides a systematic approach to document requirements for an Integration Project

The intention of this article is to identify and specify the artifacts listed in the BABOK. These artifacts are listed within the Outputs section of the BABOK tasks. Outputs are described by a paragraph of text within each task. In this article I attempted to expand on these descriptions by adding detail to their content.

It is assumed that each activity produces a tangible output^[2] which is consistent with the layout of the BABOK. Those outputs are classed as artifacts with attributes. Each artifact’s attribute description is taken from the element description of the tasks that output that artifact. The BABOK element descriptions provide guidelines for activity that produces the attribute, without necessarily defining the information contained in the attribute.That information has been derived from the element description.

Artifacts are derived from the BABOK Output sections. Artifact attributes are derived from the BABOK Element sections. A useful addition to the BABOK might be examples or templates of the outputs.

Business people call remote meetings virtual or on-line sessions, or simply conference calls. For many years we have been utilizing this form of communications to save time and money. Due to the global virus pandemic, remote meetings are now not just convenient, but a necessity for maintaining social distancing. Fortunately we have technology that assists us in managing these remote sessions to not only hear the stakeholders, but see them as well. However, remote stakeholder interviewing and meetings have their additional challenges beyond face-to-face encounters. Regardless of the technology used, we need to be keenly aware of these additional negative risks and pursue mitigations.

While the IIBA-AAC exam is not the most challenging exam that I've ever taken, it does require you to have a very specific type of understanding of the Agile Extension to the BABOK Guide. Though it's not a requirement, I recommend taking an exam prep course to increase your chances of passing the exam. Those who did not initially pass the exam reported that they underestimated the exam and figured that they would be able to rely on their agile experience to pass the exam. WRONG!! In fact, the exam doesn't focus much on the details of agile ceremonies or daily activities, but more so on the general principles of agile business analysis.

 “Clean Language” is a conversation technique developed by a psychotherapist, David Grove. It is a method of asking neutral questions to avoid influencing patient responses. Besides psychotherapy, clean language can be used in various fields for interviewing and facilitating meetings with stakeholders. This is particularly true for business analysis. The context of this article is interviewing and facilitating meeting with a focus on using clean language to ensure that stakeholder requirements are captured without the influence of the business analyst. In this article, you will note that I have cited several sidebar comments to help the reader connect the dots with various business analysis aspects.