Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

BABOK®2 Guide study guide mind map by Mind Map: BABOK®2 Guide study guide mind
map
5.0 stars - 45 reviews range from 0 to 5

BABOK®2 Guide study guide mind map

IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. Trademarks are properties of the holders, who are not affiliated with mind map author.

Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. The set of tasks and techniques that are used to perform business analysis are defined in A Guide to the Business Analysis Body of Knowledge® (BABOK®Guide).

BABOK v1.6 was published in 2006

BABOK v2 was published in 2009

Stakeholders

Business Analyst

Customer

Domain Subject Matter Expert (SME)

End User

Implementation Subject Matter Expert (SME)

Developer / Software Engineer

Organizational Change Management Professionals

System Architect

Trainer

Usability Professional

Operational Support

Project Manager

Regulator

Sponsor

Supplier

Tester

Techniques (34)

Acceptance and Evaluation Criteria Definition (9.1)

Benchmark (9.2)

Brainstorming (9.3)

Business Rules Analysis (9.4)

Data Dictionary and Glossary (9.5)

Data Flow Diagrams (9.6)

Data Modeling (9.7)

Decision Analysis (9.8)

Document Analysis (9.9)

Estimation (9.10)

Focus Groups (9.11)

Functional Decomposition (9.12)

Interface Analysis (9.13)

Interviews (9.14)

Lessons Learned Process (9.15)

Metrics and Key Performance Indicators (9.16)

Non-functional Requirements Analysis (9.17)

Observation (9.18)

Organization Modeling (9.19)

Problem Tracking (9.20)

Process Modeling (9.21)

Prototyping (9.22)

Requirements Workshops (9.23)

Risk Analysis (9.24)

Root Cause Analysis (9.25)

SWOT Analysis (9.32)

Scenarios and Use Cases (9.26)

Scope Modeling (9.27)

Sequence Diagrams (9.28)

State Diagrams (9.29)

Structured Walkthrough (9.30)

Survey / Questionnaire (9.31)

User Stories (9.33)

User Stories (9.33)

Vendor Assessment (9.34)

Knowledge Areas (6)

Business Analysis Planning and Monitoring (Chapter 2)

Elicitation (Chapter 3)

Requirements Management and Communication (Chapter 4)

Enterprise Analysis (Chapter 5)

Requirements Analysis (Chapter 6)

Solution Assessment and Validation (Chapter 7)

Tasks (32)

Task characteristics

Has a purpose

Has inputs

Is complete

Uses techniques

Involves stakeholders

Has outputs / results

Tasks may be performed formally or informally.

Tasks may be performed in any order.

Tasks are grouped into Knowledge Areas (6)

Business Analysis Planning and Monitoring (Chapter 2), 2.1 Plan Business Analysis Approach, 2.2 Conduct Stakeholder Analysis, 2.3 Plan Business Analysis Activities, 2.4 Plan Business Analysis Communication, 2.5 Plan Requirements Management Process, 2.6 Manage Business Analysis Performance

Elicitation (Chapter 3), 3.1 Prepare for Elicitation, 3.2 Conduct Elicitation Activity, 3.3 Document Elicitation Results, 3.4 Confirm Elicitation Results

Requirements Management and Communication (Chapter 4), 4.1 Manage Solution Scope & Requirements, 4.2 Manage Requirements Traceability, 4.3 Maintain Requirements for Re-use, 4.4 Prepare Requirements Package, 4.5 Communicate Requirements

Enterprise Analysis (Chapter 5), 5.1 Define Business Need, 5.2 Assess Capability Gaps, 5.3 Determine Solution Approach, 5.4 Define Solution Scope, 5.5 Define Business Case

Requirements Analysis (Chapter 6), 6.1 Prioritize Requirements, 6.2 Organize Requirements, 6.3 Specify and Model Requirements, 6.4 Define Assumptions and Constraints, 6.5 Verify Requirements, 6.6 Validate Requirements

Solution Assessment and Validation (Chapter 7), 7.1 Assess Proposed Solution, 7.2 Allocate Requirements, 7.3 Assess Organizational Readiness, 7.4 Define Transition Requirements, 7.5 Validate Solution, 7.6 Evaluate Solution Performance

Watch: What's new in the upcoming BABOK®3? 25.03.2014, IIBA Austria Chapter Meeting

Underlying Competencies of Business Analyst (6)

Analytical Thinking and Problem Solving

supports effective identification of business problems, assessment of proposed solutions to those problems, and understanding of the needs of stakeholders. Analytical thinking and problem solving involves assessing a situation, understanding it as fully as possible, and making judgments about possible solutions to a problem.

Behavioral Characteristics

support the development of effective working relationships with stakeholders and include qualities such as ethics, trustworthiness, and personal organization.

Business Knowledge

supports understanding of the environment in which business analysis is performed and knowledge of general business principles and available solutions.

Communication Skills

support business analysts in eliciting and communicating requirements among stakeholders. Communication skills address the need to listen to and understand the audience, understanding how an audience perceives the business analyst, understanding of the communications objective(s), the message itself, and the most appropriate media and format for communication.

Interaction Skills

support the business analyst when working with large numbers of stakeholders, and involve both the ability to work as part of a larger team and to help that team reach decisions. While most of the work of business analysis involves identifying and describing a desired future state, the business analyst must also be able to help the organization reach agreement that the future state in question is desired through a combination of leadership and facilitation.

Software Applications

are used to facilitate the collaborative development, recording and distribution of requirements to stakeholders. Business analysts should be skilled users of the tools used in their organization and must understand the strengths and weaknesses of each.

BABOK® Extensions

Agile Extension to the BABOK® Guide

v1, 2013

136 pages

description, The Agile Extension to the BABOK® Guide is a resource for business analysts, those who are practicing business analysis, as well as product owners, business owners and corporations who are working on agile projects. The Agile Extension to the BABOK® Guide is aligned with the Business Analysis Body of Knowledge (BABOK®) and has been developed in collaboration with the Agile Alliance. The Agile Extension to the BABOK® Guide provides business analysts with the tools and techniques they need to be extremely effective in their position on Agile teams. The Agile Extension to the BABOK Guide® provides 7 key guidelines for the practice of business analysis within an agile environment. These guidelines are supported by a Discovery Framework and a Delivery Framework that articulate specific techniques that have proven to be successful for agile teams in delivery value.

Interactive BABOK®2 Glossary

Interactive BABOK®2 Glossary

BABOK®2 consists of: 6 Knowledge Areas, 32 Tasks, 34 Techniques, 6 Underlying Competencies of Business Analyst.

Download BABOK®2 Knowledge Areas vs Techniques (PDF)

The 7 Mistakes of Business Analyst (by Dr Emma Langman)

1. Not realising that a BA is an Internal Consultant

2. Focusing too much or too little on people

3. Not having the right strategic and commercial skills

4. Not using the right project management and process skills at the right time

5. Not focusing on your core responsibilities

6. Not knowing where you are going

7. Not using your ‘secret essence’

The 7 Mistakes Report

http://www.greatinsiders.com/mistakes-report/

Requirements Lifecycle according to BABOK®2

1. Stated (Unconfirmed)

A Requirement starts to live with its first state called Stated (Unconfirmed) after it has been documented as a result of an elicitation activity. Such requirements describe the stakeholder’s need from the stakeholder’s perspective. A Stated (Unconfirmed) requirement can be input for several Tasks like Communicate Requirements, Prioritize Requirements, Specify and Model Requirements, Manage Requirements Traceability or Maintain Requirements for Re-use. But mostly, a Stated (Unconfirmed) requirement needs first to be confirmed in order to validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder’s needs. See next state.

2. (Stated) Confirmed

By interviewing or observing the stakeholders (both Techniques according to BABOK®), the BA shall confirm whether his or her understanding conforms to the actual desires or intentions of the stakeholder. Stated (Confirmed) requirements can as well be used as input for the same Tasks mentioned above with Stated (Unconfirmed) requirements and – furthermore – they can be verified (see below under Verified). While the Tasks Document Elicitation Results and Confirm Elicitation Results belong to the Knowledge Area Elicitation, the Task Verify Requirements belongs to Requirements Analysis. Before we go into this Knowledge Area we will first understand the next four States and their related Tasks out of the Knowledge Area Requirements Management and Communication:

3. Communicated

The Task Communicate Requirements is a very essential task which a BA should pay much attention on. This Task helps to bring stakeholder to a common understanding of the requirements by having conversations, discussions and presentations, both, formally and informally. Once achieved a common understanding of the requirements, conflicts between stakeholders are less likely, of course. Requirements for which a common understanding has been achieved can be considered Communicated. Whenever requirements, constraints, assumptions or risk change, Communicate Requirements shall start again, necessary to once again achieve a common understanding in the light of the changed environment. Requirements of any state can be Communicated.

4. Traced

The Task Communicate Requirements is a very essential task which a BA should pay much attention on. This Task helps to bring stakeholder to a common understanding of the requirements by having conversations, discussions and presentations, both, formally and informally. Once achieved a common understanding of the requirements, conflicts between stakeholders are less likely, of course. Requirements for which a common understanding has been achieved can be considered Communicated. Whenever requirements, constraints, assumptions or risk change, Communicate Requirements shall start again, necessary to once again achieve a common understanding in the light of the changed environment. Requirements of any state can be Communicated.

5. Approved

The status Approved can only be achieved through sign-off by authorized stakeholders, the related BABOK® task is called Manage Solution Scope and Requirements. A sign-off can be done informally by confirmation/approval mail or more formally by hand-signing a printed representation of the requirements specification (package), depending on the Organizational Process Assets and/or regulatory reasons. It goes without saying that requirements can only be presented for sign-off after they have been communicated sufficiently. Furthermore relationships to other requirements must have been clarified and captured as well as backward tracing to Business requirements, both by utilizing a so-called Coverage Matrix (see above). Therefore only requirements which have been Communicated and Traced can undergo a sign-off procedure, i.e., an approval process. After approval requirements may be baselined in order to compare later changes against this baseline.

6. Maintained & Re-usable

The status Approved can only be achieved through sign-off by authorized stakeholders, the related BABOK® task is called Manage Solution Scope and Requirements. A sign-off can be done informally by confirmation/approval mail or more formally by hand-signing a printed representation of the requirements specification (package), depending on the Organizational Process Assets and/or regulatory reasons. It goes without saying that requirements can only be presented for sign-off after they have been communicated sufficiently. Furthermore relationships to other requirements must have been clarified and captured as well as backward tracing to Business requirements, both by utilizing a so-called Coverage Matrix (see above). Therefore only requirements which have been Communicated and Traced can undergo a sign-off procedure, i.e., an approval process. After approval requirements may be baselined in order to compare later changes against this baseline.

7. Prioritized

This status can be explained straight-forward: The related task is Prioritize Requirements (Knowledge Area Requirements Analysis) and this name more or less speaks for itself. Depending on the value the requirement delivers to Business, the risk, the difficulty and the urgency a requirement may get a higher or lower priority. The more the majority of the stakeholders agree on the priority of a requirement, the higher the priority automatically gets. Common Techniques used to figure out the priorities of requirements are Decision Analysis, Risk Analysis and MoSCoW Analysis. The later divides the requirements in four categories: Must, Should, Could, and Won’t. Another criteria prioritizing requirements can be Timeboxing/Budgeting. Here, requirements are prioritized according to the amount of work a team is able to perform in a given period of time, e.g. releases or other time constraints which may exist.

8. Analyzed

I am not quite sure whether the authors of the BABOK® consider this state. Although this state is explicitly mentioned in chapter 6.3.7. as output of the task Specify and Model Requirements, it cannot be found in the related I/O diagram of this task as all other requirements states. Let’s wait for the next BABOK® release; it will for sure address such things. In the BABOK®, the analysis of requirements strongly goes along with modeling. Therefore the Techniques bound to this Task are manifold. Many kinds of modeling like Data Modeling, Organization Modeling, Process Modeling and the commonly used diagram methodologies found in UML and others are BABOK®. Although the BA does not need to know each methodology in detail, he should at least purposes he should use which approach.

9. Verified

Verify Requirements ensures that requirements are of a sufficient quality to be processed further. Requirements which do not provide enough information to be reasonably reviewed and validated by the due to lack of quality. Further processing of such requirements does not make sense that is why they should be refined or dropped, alternatively. To mention only one of the quality criteria, I would like to emphasize that a requirement must be testable in order to prove that a requirements of the Business.

10. Validated

he Task Validate Requirement ts needs Verified requirements as input in order to validate their Business value. Validated means that the requirements’ value can be demonstrated to the Business stakeholders and that they aligned with the goals and objectives of the Business.

11. Allocated

This state can only be reached if the requirement has been Prioritized and Approved beforehand. By performing the task Allocate Requirements out of the Knowledge Area Solution Assessment and Validation, the implementation and/or deployment of requirements in terms of point in time is fixed. This may depend on release cycles, on available resources or on other constrai innts

source

http://www.masventa.eu/fileadmin/user_upload/media/pdf_en/Requirements-Lifecycle.pdf

Requirements Classification Schema

Business requirements

Stakeholder requirements

Solution requirements

Transition requirements

CBAP® Exams

http://www.thebacoach.com/five-ways-to-make-the-babok-an-irresistible-read/

3rd party

professionaltestpro.com, http://my.professionaltestpro.com/freetest/learning/Certified%20Business%20Analyst%20Professional%20%28CBAP%29#

twpass.com, http://www.twpass.com/twpass.com/exam.aspx?eCode=CBAP&qno=1

CBAP+Master, http://www.slideshare.net/cbapmaster/cbapmaster-150-free-questions

This freeware mind map (aligned with the version 2 of BABOK®) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the BABOK® and business analysis profession and as a learning tool for candidates wanting to gain CBAP® qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.

http://www.miroslawdabrowski.com

http://www.linkedin.com/in/miroslawdabrowski

https://www.google.com/+MiroslawDabrowski

https://play.spotify.com/user/miroslawdabrowski/

https://twitter.com/mirodabrowski

miroslaw_dabrowski