Chapter 4: Elicitation and Collaboration


posted by Liliane Castano Marino

According to chapter 4 of the BABOK, the Elicitation and Collaboration knowledge area describes the work of business analysts to understand stakeholder needs, concerns and the environments in which they work or operate.  In this area of knowledge, the business analysts extracts the information necessary to assertively understand the change and what really needs to be done.  It is an ongoing work as long as business analysis work is occurring.

The Elicitation and Collaboration knowledge area is composed of the following tasks:

1)      Prepare for Elicitation
At this point, it is important to establish what information will be needed, which stakeholders will be involved, which work products will be produced and which techniques will be most appropriated to reach the required results.
The professional who does business analysis needs to go far beyond interviews and questionnaires. BABOK points out several of these techniques and concepts that increase elicitation and contribute to a significant gain in the quality of this work.

2)     Conduct Elicitation
The purpose of conducting elicitation is to identify information relevant to change.  This information will be reached using the three common types of elicitation:  collaborative, research and experiments.

3)     Confirm Elicitation Results
The information shared by the stakeholders during the elicitation must be organized before it can be reviewed and used. Reviewing them can identify errors, omissions and conflicts and, in this case, the business analyst should request further elicitation.

4)     Communicate Business Analysis Information
Business analysts must communicate appropriate information to stakeholders, and ensure they understand the information and gain agreement. The best format to be utilized is the one that best meet the stakeholders needs.

5)     Manage Stakeholder Collaboration
The main objective of this task is to encourage stakeholders to work towards a common goal.   It is an ongoing activity since new stakeholders may be identified throughout the initiative or their responsibilities may change over time.

Comments

  1. Paramjeet Kaur Toor11 February 2020 at 08:40

    These all knowledge areas are important as all of these areas provide useful knowledge to business analysts such as stakeholder's needs, production of products, gathering information etc. Different techniques are used for each of these tasks. In scotia bank, Business analysts also obtain information from stakeholder to confirm the results , by using these areas.

    ReplyDelete
  2. Harvinder Singh24 February 2020 at 15:30

    This concept is helpful for getting the knowledge about the external environment and the stakeholders needs. Elicitation of requirements with the stakeholder’s collaboration is the main responsibility of the Business Analyst and mainly in the Scotia bank the business analyst follow these steps. The main motive of this flow is to enhance the stakeholders attraction towards the company's common goals. As in the blog it is said that the Business analyst must clear all the information of business analysis that is also important aspect.

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 8 - Starting the Solution by Harvinder Singh

  Chapter 8 Starting the Solution We are transferring from an abstract global to the physical international, from policy to technology, from problem to solution; from purpose to design: we have reached the closing quadrant of the Brown Cow Model, in which will be determined how we are going to enforce the essential business. With a solid know-how of the essence of the business, which means that the real trouble to be solved, it’s time to determine which components of that problem would advantage from being automated. The commercial enterprise analyst juggles many factors to determine the most appropriate product to build. Iterative Development Iterative development is a way of breaking down the software improvement of a large application into smaller chunks. In iterative development, feature code is designed, developed and examined in repeated cycles. With each iteration, additional functions may be designed, advanced and examined till there is a com...
Read more

Chapter 4- Business Use Cases - posted by Chelsia Palta

Understanding the Work  The product you intend to build must improve its owner’s work; it will be installed in the owner’s area of business and will do part of the work. It does not matter which kind of work it is commercial, scientific, embedded real-time, manual, or automated you always have to understand it before you can decide which kind of product will best help with it. Use Cases and Their Scope The term "use case" was coined by Ivar Jacobson back in 1987 as a way to describe an interaction between a system and a user of that system. Jacobson needed to break the system into smaller units, as he felt that object models were not scalable. Thus, to conquer the complexity and largeness of modern systems, he said it was first necessary to partition them into convenient chunks, and that these chunks should be based on the user’s view of the system. The Outside World Adjacent systems behave like any other systems: They contain processes and consume and/or...
Read more

Chapter 11 Non-Functional Requirements by Hassan

Non-Functional Requirements Non-Functional Requirements can be generalized as "what a product/system is supposed to be. these requirements tend to be qualities that the product should have and they should specify how well the product does what it does. the requirements should either make the product usable, fast, reliable, attractive or safe and they should describe the character/ the way the functions should behave. Look and Feel Requirements the look and feel requirements are key to the non-functional requirements and as a BA one must consider them for every project. These requirements can describe how a product/system's desired appearance, mood, spirit or overall style/ appearance. The look and feel requirements can further specify what the product/system intends to appear as and is not a detailed design of the product/system itself. The typical look and feel requirement should be simple to use, professional looking, attractive to its market, consistent with previ...
Read more