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.
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.
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.
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.
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.
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?”
Project statistics state that most project rework/failure is due to incomplete/improper/unclear requirements, hence the role the Business Analyst becomes even more critical as they shoulder a huge responsibility of eliciting and collaborating with the stakeholders to obtain clear, concise and complete requirements. The elicitation and collaboration knowledge area focuses on drawing forth or receiving information from stakeholders and other sources by directly interacting with stakeholders, researching topics, experimenting or simply being handed information.
Chaos! Stress! Everyday mess! Isn’t this an everyday situation for a business analyst? If not, either you’ve job satisfaction or you’re not being introduced to the real world of business analysis.
A person might possess great skills, however, (s)he might not be able to utilize skills without the right mix of tools and environment. A toolbox enables a person to implement the skills in the most efficient way. Possessing necessary tools is just the one part of it. Another is the knowledge to utilize the right tools at the right time to cater the solution and ensure timely committed delivery.
What are these tools? How do we map the usage of tools to the given circumstance? How can we efficiently utilize the tool? Does it depend on the solution or the approach?
During a recent presentation to business analysts, I used one of my consulting projects as an example of how to apply an analysis technique we were discussing. A member of the audience asked, “What made this company hire you as a BA consultant to tackle this project, when they already have so many in-house product managers and business analysts on their teams?”
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: