1. 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).
1.1. BABOK v1.6 was published in 2006
1.2. BABOK v2 was published in 2009
2. Stakeholders
2.1. Business Analyst
2.2. Customer
2.3. Domain Subject Matter Expert (SME)
2.4. End User
2.5. Implementation Subject Matter Expert (SME)
2.5.1. Developer / Software Engineer
2.5.2. Organizational Change Management Professionals
2.5.3. System Architect
2.5.4. Trainer
2.5.5. Usability Professional
2.6. Operational Support
2.7. Project Manager
2.8. Regulator
2.9. Sponsor
2.10. Supplier
2.11. Tester
3. Techniques (34)
3.1. Acceptance and Evaluation Criteria Definition (9.1)
3.2. Benchmark (9.2)
3.3. Brainstorming (9.3)
3.4. Business Rules Analysis (9.4)
3.5. Data Dictionary and Glossary (9.5)
3.6. Data Flow Diagrams (9.6)
3.7. Data Modeling (9.7)
3.8. Decision Analysis (9.8)
3.9. Document Analysis (9.9)
3.10. Estimation (9.10)
3.11. Focus Groups (9.11)
3.12. Functional Decomposition (9.12)
3.13. Interface Analysis (9.13)
3.14. Interviews (9.14)
3.15. Lessons Learned Process (9.15)
3.16. Metrics and Key Performance Indicators (9.16)
3.17. Non-functional Requirements Analysis (9.17)
3.18. Observation (9.18)
3.19. Organization Modeling (9.19)
3.20. Problem Tracking (9.20)
3.21. Process Modeling (9.21)
3.22. Prototyping (9.22)
3.23. Requirements Workshops (9.23)
3.24. Risk Analysis (9.24)
3.25. Root Cause Analysis (9.25)
3.26. SWOT Analysis (9.32)
3.27. Scenarios and Use Cases (9.26)
3.28. Scope Modeling (9.27)
3.29. Sequence Diagrams (9.28)
3.30. State Diagrams (9.29)
3.31. Structured Walkthrough (9.30)
3.32. Survey / Questionnaire (9.31)
3.33. User Stories (9.33)
3.34. User Stories (9.33)
3.35. Vendor Assessment (9.34)
4. Knowledge Areas (6)
4.1. Business Analysis Planning and Monitoring (Chapter 2)
4.2. Elicitation (Chapter 3)
4.3. Requirements Management and Communication (Chapter 4)
4.4. Enterprise Analysis (Chapter 5)
4.5. Requirements Analysis (Chapter 6)
4.6. Solution Assessment and Validation (Chapter 7)
5. Tasks (32)
5.1. Task characteristics
5.1.1. Has a purpose
5.1.2. Has inputs
5.1.3. Is complete
5.1.4. Uses techniques
5.1.5. Involves stakeholders
5.1.6. Has outputs / results
5.1.7. Tasks may be performed formally or informally.
5.1.8. Tasks may be performed in any order.
5.2. Tasks are grouped into Knowledge Areas (6)
5.2.1. Business Analysis Planning and Monitoring (Chapter 2)
5.2.1.1. 2.1 Plan Business Analysis Approach
5.2.1.2. 2.2 Conduct Stakeholder Analysis
5.2.1.3. 2.3 Plan Business Analysis Activities
5.2.1.4. 2.4 Plan Business Analysis Communication
5.2.1.5. 2.5 Plan Requirements Management Process
5.2.1.6. 2.6 Manage Business Analysis Performance
5.2.2. Elicitation (Chapter 3)
5.2.2.1. 3.1 Prepare for Elicitation
5.2.2.2. 3.2 Conduct Elicitation Activity
5.2.2.3. 3.3 Document Elicitation Results
5.2.2.4. 3.4 Confirm Elicitation Results
5.2.3. Requirements Management and Communication (Chapter 4)
5.2.3.1. 4.1 Manage Solution Scope & Requirements
5.2.3.2. 4.2 Manage Requirements Traceability
5.2.3.3. 4.3 Maintain Requirements for Re-use
5.2.3.4. 4.4 Prepare Requirements Package
5.2.3.5. 4.5 Communicate Requirements
5.2.4. Enterprise Analysis (Chapter 5)
5.2.4.1. 5.1 Define Business Need
5.2.4.2. 5.2 Assess Capability Gaps
5.2.4.3. 5.3 Determine Solution Approach
5.2.4.4. 5.4 Define Solution Scope
5.2.4.5. 5.5 Define Business Case
5.2.5. Requirements Analysis (Chapter 6)
5.2.5.1. 6.1 Prioritize Requirements
5.2.5.2. 6.2 Organize Requirements
5.2.5.3. 6.3 Specify and Model Requirements
5.2.5.4. 6.4 Define Assumptions and Constraints
5.2.5.5. 6.5 Verify Requirements
5.2.5.6. 6.6 Validate Requirements
5.2.6. Solution Assessment and Validation (Chapter 7)
5.2.6.1. 7.1 Assess Proposed Solution
5.2.6.2. 7.2 Allocate Requirements
5.2.6.3. 7.3 Assess Organizational Readiness
5.2.6.4. 7.4 Define Transition Requirements
5.2.6.5. 7.5 Validate Solution
5.2.6.6. 7.6 Evaluate Solution Performance
6. Watch: What's new in the upcoming BABOK®3? 25.03.2014, IIBA Austria Chapter Meeting
7. Underlying Competencies of Business Analyst (6)
7.1. Analytical Thinking and Problem Solving
7.1.1. 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.
7.2. Behavioral Characteristics
7.2.1. support the development of effective working relationships with stakeholders and include qualities such as ethics, trustworthiness, and personal organization.
7.3. Business Knowledge
7.3.1. supports understanding of the environment in which business analysis is performed and knowledge of general business principles and available solutions.
7.4. Communication Skills
7.4.1. 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.
7.5. Interaction Skills
7.5.1. 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.
7.6. Software Applications
7.6.1. 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.
8. BABOK® Extensions
8.1. Agile Extension to the BABOK® Guide
8.1.1. v1, 2013
8.1.2. 136 pages
8.1.3. description
8.1.3.1. 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.
9. Interactive BABOK®2 Glossary
9.1. Interactive BABOK®2 Glossary
10. BABOK®2 consists of: 6 Knowledge Areas, 32 Tasks, 34 Techniques, 6 Underlying Competencies of Business Analyst.
10.1. Download BABOK®2 Knowledge Areas vs Techniques (PDF)
11. The 7 Mistakes of Business Analyst (by Dr Emma Langman)
11.1. 1. Not realising that a BA is an Internal Consultant
11.2. 2. Focusing too much or too little on people
11.3. 3. Not having the right strategic and commercial skills
11.4. 4. Not using the right project management and process skills at the right time
11.5. 5. Not focusing on your core responsibilities
11.6. 6. Not knowing where you are going
11.7. 7. Not using your ‘secret essence’
11.8. The 7 Mistakes Report
11.8.1. http://www.greatinsiders.com/mistakes-report/
12. Requirements Lifecycle according to BABOK®2
12.1. 1. Stated (Unconfirmed)
12.1.1. 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.
12.2. 2. (Stated) Confirmed
12.2.1. 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:
12.3. 3. Communicated
12.3.1. 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.
12.4. 4. Traced
12.4.1. 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.
12.5. 5. Approved
12.5.1. 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.
12.6. 6. Maintained & Re-usable
12.6.1. 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.
12.7. 7. Prioritized
12.7.1. 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.
12.8. 8. Analyzed
12.8.1. 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.
12.9. 9. Verified
12.9.1. 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.
12.10. 10. Validated
12.10.1. 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.
12.11. 11. Allocated
12.11.1. 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
12.12. source
12.12.1. http://www.masventa.eu/fileadmin/user_upload/media/pdf_en/Requirements-Lifecycle.pdf
13. Requirements Classification Schema
13.1. Business requirements
13.2. Stakeholder requirements
13.3. Solution requirements
13.4. Transition requirements
14. CBAP® Exams
14.1. http://www.thebacoach.com/five-ways-to-make-the-babok-an-irresistible-read/
14.2. 3rd party
14.2.1. professionaltestpro.com
14.2.1.1. http://my.professionaltestpro.com/freetest/learning/Certified%20Business%20Analyst%20Professional%20%28CBAP%29#
14.2.2. twpass.com
14.2.2.1. http://www.twpass.com/twpass.com/exam.aspx?eCode=CBAP&qno=1
14.2.3. CBAP+Master
14.2.3.1. http://www.slideshare.net/cbapmaster/cbapmaster-150-free-questions
15. 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!)
15.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website: www.miroslawdabrowski.com
15.1.1. http://www.miroslawdabrowski.com
15.1.2. http://www.linkedin.com/in/miroslawdabrowski
15.1.3. https://www.google.com/+MiroslawDabrowski
15.1.4. https://play.spotify.com/user/miroslawdabrowski/
15.1.5. https://twitter.com/mirodabrowski
15.1.6. miroslaw_dabrowski