Elicitation (BABOK KA)

Jun 12, 2022
10360 Views
9 Likes
0 Comments

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.

Jan 30, 2022
9857 Views
2 Likes
0 Comments

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.

Oct 10, 2021
12712 Views
13 Likes
0 Comments

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.

Sep 12, 2021
15504 Views
13 Likes
0 Comments

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.

May 19, 2021
11159 Views
1 Likes
1 Comments

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.

May 16, 2021
16254 Views
20 Likes
0 Comments

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

15860 Views
5 Likes
0 Comments

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.

10882 Views
6 Likes
0 Comments

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.

14834 Views
50 Likes
0 Comments
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.
9989 Views
36 Likes
0 Comments
 “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.
9910 Views
26 Likes
0 Comments

Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations.  There is incredible power in using inversion at the outset of a project to imagine ourselves in a future where the solution has not only been delivered, but is in the hands of end-users to get their job done. Rather than simply going through the typical project phases in forward motion, we can then look backward and gain additional perspective into what might go wrong so that preventive steps can be taken to avoid those bad outcomes.

15324 Views
30 Likes
0 Comments

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

19839 Views
34 Likes
3 Comments

Project Scope. We will see how scope statements, when making reference to business functionality, lead directly to High-Level requirements.  Gathering requirements for a business information system is most often done within the context of a project. Approval of a project includes its sponsors signing off on its scope. The scope for a business information system project is typically defined in functional terms. Items in scope make reference to (or should make reference to) business functions, processes and/or activities that are to be delivered.

17413 Views
33 Likes
1 Comments

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.

15085 Views
33 Likes
0 Comments

This article provides high-level steps for eliciting requirements when interviewing or holding a facilitated meeting with stakeholders; it was motivated by an attendee question at a recent Modern Analyst webinar: “Functional vs. Nonfunctional requirements.”  The question was, “Can a Business Analyst elicit functional and nonfunctional requirements in the same iteration?” 

Page 1 of 6First   Previous   [1]  2  3  4  5  6  Next   Last   

 



 




Copyright 2006-2022 by Modern Analyst Media LLC