BABOK Guide v3 PDF

v3 A G U I D E T O T H E B U S I N E S S A N A LY S I S B O DY O F K N O W L ED GE ® BABOK ® v3 A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE® International Institute of Business Analysis, Toronto, Ontario, Canada. ©2005, 2...

v3 A G U I D E T O T H E B U S I N E S S A N A LY S I S B O DY O F K N O W L ED GE ® BABOK ® v3 A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE® International Institute of Business Analysis, Toronto, Ontario, Canada. ©2005, 2006, 2008, 2009, 2015 International Institute of Business Analysis. All rights reserved. Version 1.0 and 1.4 published 2005. Version 1.6 Draft published 2006. Version 1.6 Final published 2008. Version 2.0 published 2009. Version 3.0 published 2015. ISBN-13: 978-1-927584-03-3 Permission is granted to reproduce this document for your own personal, professional, or educational use. If you have purchased a license to use this document from IIBA®, you may transfer ownership to a third party. IIBA® members may not transfer ownership of their complimentary copy. Complimentary IIBA® Member Copy. Not for Distribution or Resale. This document is provided to the business analysis community for educational purposes. IIBA® does not warrant that it is suitable for any other purpose and makes no expressed or implied warranty of any kind and assumes no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information contained herein. IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. CBAP® is a registered certification mark owned by International Institute of Business Analysis. Certified Business Analysis Professional, EEP and the EEP logo are trademarks owned by International Institute of Business Analysis. Archimate® is a registered trademark of The Open Group in the US and other countries. Business Model Canvas is copyrighted by BusinessModelGeneration.com and released under Creative Commons license. CMMI® is a registered trademark of Carnegie Mellon University. COBIT® is a trademark of the Information Systems Audit and Control Association and the IT Governance Institute. Mind Map® is a registered trademark of the Buzan Organization. Scaled Agile Framework® and SAFe™ are trademarks of Scaled Agile, Inc. TOGAF® is a registered trademark of The Open Group in the US and other countries. Unified Modelling Language™ and UML® are trademarks of the Object Management Group. Zachman Framework for Enterprise Architecture is a trademark of the Zachman Institute for Framework Advancement. No challenge to the status or ownership of these or any other trademarked terms contained herein is intended by the International Institute of Business Analysis. Any inquiries regarding this publication, requests for usage rights for the material included herein, or corrections should be sent by email to [email protected].  Table of Contents Complimentary IIBA® Member Copy. Not for Distribution or Resale. Chapter 1: Introduction 1.1 Purpose of the BABOK® Guide 1 1.2 What is Business Analysis? 2 1.3 Who is a Business Analyst? 2 1.4 Structure of the BABOK® Guide 3 Chapter 2: Business Analysis Key Concepts 2.1 The Business Analysis Core Concept Model™ 12 2.2 Key Terms 14 2.3 Requirements Classification Schema 16 2.4 Stakeholders 16 2.5 Requirements and Designs 19 Chapter 3: Business Analysis Planning and Monitoring 3.1 Plan Business Analysis Approach 24 3.2 Plan Stakeholder Engagement 31 3.3 Plan Business Analysis Governance 37 3.4 Plan Business Analysis Information Management 42 3.5 Identify Business Analysis Performance Improvements 47 i  Table of Contents Chapter 4: Elicitation and Collaboration 4.1 Prepare for Elicitation 56 4.2 Conduct Elicitation 61 4.3 Confirm Elicitation Results 65 4.4 Communicate Business Analysis Information 67 4.5 Manage Stakeholder Collaboration 71 Chapter 5: Requirements Life Cycle Management 5.1 Trace Requirements 79 5.2 Maintain Requirements 83 5.3 Prioritize Requirements 86 Complimentary IIBA® Member Copy. Not for Distribution or Resale. 5.4 Assess Requirements Changes 91 5.5 Approve Requirements 95 Chapter 6: Strategy Analysis 6.1 Analyze Current State 103 6.2 Define Future State 110 6.3 Assess Risks 120 6.4 Define Change Strategy 124 Chapter 7: Requirements Analysis and Design Definition 7.1 Specify and Model Requirements 136 7.2 Verify Requirements 141 7.3 Validate Requirements 144 7.4 Define Requirements Architecture 148 7.5 Define Design Options 152 7.6 Analyze Potential Value and Recommend Solution 157 Chapter 8: Solution Evaluation 8.1 Measure Solution Performance 166 8.2 Analyze Performance Measures 170 8.3 Assess Solution Limitations 173 8.4 Assess Enterprise Limitations 177 8.5 Recommend Actions to Increase Solution Value 182 Chapter 9: Underlying Competencies 9.1 Analytical Thinking and Problem Solving 188 ii Table of Contents 9.2 Behavioural Characteristics 194 9.3 Business Knowledge 199 9.4 Communication Skills 203 9.5 Interaction Skills 207 9.6 Tools and Technology 211 Chapter 10: Techniques 10.1 Acceptance and Evaluation Criteria 217 10.2 Backlog Management 220 10.3 Balanced Scorecard 223 10.4 Benchmarking and Market Analysis 226 Complimentary IIBA® Member Copy. Not for Distribution or Resale. 10.5 Brainstorming 227 10.6 Business Capability Analysis 230 10.7 Business Cases 234 10.8 Business Model Canvas 236 10.9 Business Rules Analysis 240 10.10 Collaborative Games 243 10.11 Concept Modelling 245 10.12 Data Dictionary 247 10.13 Data Flow Diagrams 250 10.14 Data Mining 253 10.15 Data Modelling 256 10.16 Decision Analysis 261 10.17 Decision Modelling 265 10.18 Document Analysis 269 10.19 Estimation 271 10.20 Financial Analysis 274 10.21 Focus Groups 279 10.22 Functional Decomposition 283 10.23 Glossary 286 10.24 Interface Analysis 287 10.25 Interviews 290 10.26 Item Tracking 294 10.27 Lessons Learned 296 10.28 Metrics and Key Performance Indicators (KPIs) 297 10.29 Mind Mapping 299 10.30 Non-Functional Requirements Analysis 302 10.31 Observation 305 10.32 Organizational Modelling 308 iii  Table of Contents 10.33 Prioritization 311 10.34 Process Analysis 314 10.35 Process Modelling 318 10.36 Prototyping 323 10.37 Reviews 326 10.38 Risk Analysis and Management 329 10.39 Roles and Permissions Matrix 333 10.40 Root Cause Analysis 335 10.41 Scope Modelling 338 10.42 Sequence Diagrams 341 10.43 Stakeholder List, Map, or Personas 344 10.44 State Modelling 348 Complimentary IIBA® Member Copy. Not for Distribution or Resale. 10.45 Survey or Questionnaire 350 10.46 SWOT Analysis 353 10.47 Use Cases and Scenarios 356 10.48 User Stories 359 10.49 Vendor Assessment 361 10.50 Workshops 363 Chapter 11: Perspectives 11.1 The Agile Perspective 368 11.2 The Business Intelligence Perspective 381 11.3 The Information Technology Perspective 394 11.4 The Business Architecture Perspective 408 11.5 The Business Process Management Perspective 424 Appendix A: Glossary 441 Appendix B: Techniques to Task Mapping 457 Appendix C: Contributors 473 Appendix D: Summary of Changes from BABOK® Guide v 2.0 483 iv Preface IIBA® was founded in Toronto, Canada in October of 2003 to support the business analysis community by: creating and developing awareness and recognition of the value and contribution of the business analyst, defining the Business Analysis Body of Knowledge® (BABOK®), providing a forum for knowledge sharing and contribution to the business analysis profession, and publicly recognizing and certifying qualified practitioners through an internationally Complimentary IIBA® Member Copy. Not for Distribution or Resale. acknowledged certification program. The Body of Knowledge Committee was formed in October of 2004 to define and draft a global standard for the practice of business analysis. In January of 2005, IIBA released version 1.0 of A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) for feedback and comment. That version included an outline of the proposed content and some key definitions. Version 1.4 was released in October of 2005, with draft content in some knowledge areas. Version 1.6, which included detailed information regarding most of the knowledge areas, was published in draft form in June of 2006 and updated to incorporate errata in October of 2008. The Body of Knowledge Committee developed version 2.0 of A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) with the guidance of expert writing teams, and feedback garnered from expert, practitioner, and public reviews. Version 2.0 introduced such concepts as the Requirements Classification Schema and the Input/Output models. Version 2.0 was published in 2009 and became the globally recognized standard for the practice of business analysis. Following the publication of version 2.0, IIBA sought out a number of recognized experts in business analysis and related fields and solicited their feedback on the content of that edition. The Body of Knowledge Committee used these comments to plan the vision and scope of this revision. The Body of Knowledge Committee worked with teams of expert writers to revise and update the content. The revised draft of A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) was reviewed by teams of both expert and practitioner reviewers. The Body of Knowledge Committee used the feedback provided to further enhance and refine the text and then made the content available to the business analysis community for review in 2014. The thousands of items of feedback from this public review were used to further revise the text to form A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) version 3.0. The goal of this revision was to: incorporate new concepts and practices in use since the last revision, address the broadening and evolving scope of the profession, incorporate lessons learned from practitioners who have worked with the current version, improve the readability and usability of the guide, improve the consistency and quality of text and illustrations, and improve consistency with other generally accepted standards relating to the practice of business analysis. v  The major changes in this release include: the inclusion of the Business Analysis Core Concept Model™ (BACCM™), the expanded scope of the role of business analysis in creating better business outcomes, the inclusion of Perspectives which describe specialized ways in which business analysis professionals provide unique value to the enterprise, new and expanded Underlying Competencies to better reflect the diverse skill sets of the business analyst, and new techniques that have emerged in the practice of business analysis. This publication supersedes A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) version 2.0. The BABOK® Guide contains a description of generally accepted practices in the field of business Complimentary IIBA® Member Copy. Not for Distribution or Resale. analysis. The content included in this release has been verified through reviews by practitioners, surveys of the business analysis community, and consultations with recognized experts in the field. The data available to IIBA demonstrates that the tasks and techniques described in this publication are in use by a majority of business analysis practitioners. As a result, we can have confidence that the tasks and techniques described in the BABOK® Guide should be applicable in most contexts where business analysis is performed, most of the time. The BABOK® Guide should not be construed to mandate that the practices described in this publication should be followed under all circumstances. Any set of practices must be tailored to the specific conditions under which business analysis is being performed. In addition, practices which are not generally accepted by the business analysis community at the time of publication may be equally effective, or more effective, than the practices described in the BABOK® Guide. As such practices become generally accepted, and as data is collected to verify their effectiveness, they will be incorporated into future editions of this publication. IIBA encourages all practitioners of business analysis to be open to new approaches and new ideas, and wishes to encourage innovation in the practice of business analysis. IIBA would like to extend its thanks and the thanks of the business analysis community to all those who volunteered their time and effort to the development of this revision, as well as those who provided informal feedback to us in other ways. vi  1 Introduction Complimentary IIBA® Member Copy. Not for Distribution or Resale. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is the globally recognized standard for the practice of business analysis. The BABOK® Guide describes business analysis knowledge areas, tasks, underlying competencies, techniques and perspectives on how to approach business analysis. 1.1 Purpose of the BABOK® Guide The primary purpose of the BABOK® Guide is to define the profession of business analysis and provide a set of commonly accepted practices. It helps practitioners discuss and define the skills necessary to effectively perform business analysis work. The BABOK® Guide also helps people who work with and employ business analysts to understand the skills and knowledge they should expect from a skilled practitioner. Business analysis is a broad profession in which business analysts might perform work for many different types of initiatives across an enterprise. Practitioners may employ different competencies, knowledge, skills, terminology, and attitudes that they use when performing business analysis tasks. The BABOK® Guide is a common framework for all perspectives, describing business analysis tasks that are performed to properly analyze a change or evaluate the necessity for a change. Tasks may vary in form, order, or importance for individual business analysts or for various initiatives. The six knowledge areas of the BABOK® Guide (Business Analysis Planning and Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management, Strategy Analysis, Requirements Analysis and Design Definition (RADD), and 1  What is Business Analysis? Introduction Solution Evaluation) describe the practice of business analysis as it is applied within the boundaries of a project or throughout enterprise evolution and continuous improvement. The following image shows how three of the knowledge areas support the delivery of business value before, during, and after the life cycle of a project. Figure 1.1.1: Business Analysis Beyond Projects Project Pre-Project Project Post-Project Rationale Delivery Benefits Complimentary IIBA® Member Copy. Not for Distribution or Resale. Strategy Analysis RADD Solution Evaluation 1.2 What is Business Analysis? Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value. Business analysis is performed on a variety of initiatives within an enterprise. Initiatives may be strategic, tactical, or operational. Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement. It can be used to understand the current state, to define the future state, and to determine the activities required to move from the current to the future state. Business analysis can be performed from a diverse array of perspectives. The BABOK® Guide describes several of these perspectives: agile, business intelligence, information technology, business architecture, and business process management. A perspective can be thought of as a lens through which the business analysis practitioner views their work activities based on the current context. One or many perspectives may apply to an initiative, and the perspectives outlined in the BABOK® Guide do not represent all the contexts for business analysis or the complete set of business analysis disciplines. 1.3 Who is a Business Analyst? A business analyst is any person who performs business analysis tasks described in the BABOK® Guide, no matter their job title or organizational role. Business analysts are responsible for discovering, synthesizing, and analyzing information 2 Introduction Structure of the BABOK® Guide from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes. Business analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders. The activities that business analysts perform include: understanding enterprise problems and goals, analyzing needs and solutions, devising strategies, driving change, and facilitating stakeholder collaboration. Complimentary IIBA® Member Copy. Not for Distribution or Resale. Other common job titles for people who perform business analysis include: business architect, business systems analyst, data analyst, enterprise analyst, management consultant, process analyst, product manager, product owner, requirements engineer, and systems analyst. 1.4 Structure of the BABOK® Guide The core content of the BABOK® Guide is composed of business analysis tasks organized into knowledge areas. Knowledge areas are a collection of logically (but not sequentially) related tasks. These tasks describe specific activities that accomplish the purpose of their associated knowledge area. The Business Analysis Key Concepts, Underlying Competencies, Techniques, and Perspectives sections form the extended content in the BABOK® Guide that helps guide business analysts to better perform business analysis tasks. Business Analysis Key Concepts: define the key terms needed to understand all other content, concepts, and ideas within the BABOK® Guide. Underlying Competencies: provide a description of the behaviours, characteristics, knowledge, and personal qualities that support the effective practice of business analysis. 3  Structure of the BABOK® Guide Introduction Techniques: provide a means to perform business analysis tasks. The techniques described in the BABOK® Guide are intended to cover the most common and widespread techniques practiced within the business analysis community. Perspectives: describe various views of business analysis. Perspectives help business analysts working from various points of view to better perform business analysis tasks, given the context of the initiative. 1.4.1 Key Concepts The Business Analysis Key Concepts chapter provides a basic understanding of the central ideas necessary for understanding the BABOK® Guide. This chapter consists of: Complimentary IIBA® Member Copy. Not for Distribution or Resale. Business Analysis Core Concept Model™ (BACCM™) Key Terms Requirements Classification Schema Stakeholders Requirements and Design 1.4.2 Knowledge Areas Knowledge areas represent areas of specific business analysis expertise that encompass several tasks. The six knowledge areas are: Each knowledge Business Analysis Planning and Monitoring: describes the tasks that area includes a business analysts perform to organize and coordinate the efforts of visual business analysts and stakeholders. These tasks produce outputs that are representation of used as key inputs and guidelines for the other tasks throughout the its inputs and BABOK® Guide. outputs. Elicitation and Collaboration: describes the tasks that business analysts perform to prepare for and conduct elicitation activities and confirm the results obtained. It also describes the communication with stakeholders once the business analysis information is assembled and the ongoing collaboration with them throughout the business analysis activities. Requirements Life Cycle Management: describes the tasks that business analysts perform in order to manage and maintain requirements and design information from inception to retirement. These tasks describe establishing meaningful relationships between related requirements and designs, and assessing, analyzing and gaining consensus on proposed changes to requirements and designs. Strategy Analysis: describes the business analysis work that must be performed to collaborate with stakeholders in order to identify a need of strategic or tactical importance (the business need), enable the enterprise to 4 Introduction Structure of the BABOK® Guide address that need, and align the resulting strategy for the change with higher- and lower-level strategies. Requirements Analysis and Design Definition: describes the tasks that business analysts perform to structure and organize requirements discovered during elicitation activities, specify and model requirements and designs, validate and verify information, identify solution options that meet business needs, and estimate the potential value that could be realized for each solution option. This knowledge area covers the incremental and iterative activities ranging from the initial concept and exploration of the need through the transformation of those needs into a particular recommended solution. Solution Evaluation: describes the tasks that business analysts perform to assess the performance of and value delivered by a solution in use by the Complimentary IIBA® Member Copy. Not for Distribution or Resale. enterprise, and to recommend removal of barriers or constraints that prevent the full realization of the value. The following diagram shows a general relationship between the knowledge areas. Figure 1.4.1: Relationships Between Knowledge Areas Business Analysis Planning and Monitoring Requirements Strategy Analysis Analysis and Design Definition Elicitation and Requirements Life Collaboration Cycle Management Solution Evaluation 1.4.3 Tasks A task is a discrete piece of work that may be performed formally or informally as part of business analysis. The BABOK® Guide defines a list of business analysis tasks. The definition of a given task is universally applicable to business analysis efforts, independent of the initiative type. A business analyst may perform other 5  Structure of the BABOK® Guide Introduction activities as assigned by their organization, but these additional activities are not considered to be part of the business analysis profession. Tasks are grouped into knowledge areas. Business analysts perform tasks from all knowledge areas sequentially, iteratively, or simultaneously. The BABOK® Guide does not prescribe a process or an order in which tasks are performed. Tasks may be performed in any order, as long as the necessary inputs to a task are present. A business analysis initiative may start with any task, although likely candidates are Analyze Current State (p. 103) or Measure Solution Performance (p. 166). Each task in the BABOK® Guide is presented in the following format: Purpose Description Inputs Complimentary IIBA® Member Copy. Not for Distribution or Resale. Elements Guidelines/Tools Techniques Stakeholders Outputs.1 Purpose The Purpose section provides a short description of the reason for a business analyst to perform the task, and the value created through performing the task..2 Description The Description section explains in greater detail what the task is, why it is performed, and what it should accomplish..3 Inputs The Inputs section lists the inputs for the task. Inputs are information consumed or transformed to produce an output, and represent the information necessary for a task to begin. They may be explicitly generated outside the scope of business analysis or generated by a business analysis task. Inputs that are generated outside of the business analysis efforts are identified with the qualifier '(external)' in the input list. There is no assumption that the presence of an input means that the associated deliverable is complete or in its final state. The input only needs to be sufficiently complete to allow successive work to begin. Any number of instances of an input may exist during the life cycle of an initiative. The Inputs section includes a visual representation of the inputs and outputs, the other tasks that use the outputs, as well as the guidelines and tools listed in the task. 6 Introduction Structure of the BABOK® Guide.4 Elements The Elements section describes the key concepts that are needed to understand how to perform the task. Elements are not mandatory as part of performing a task, and their usage might depend upon the business analysis approach..5 Guidelines and Tools The Guidelines and Tools section lists resources that are required to transform the input into an output. A guideline provides instructions or descriptions on why or how to undertake a task. A tool is something used to undertake a task. Guidelines and tools can include outputs of other tasks..6 Techniques The Techniques section lists the techniques that can be used to perform the Complimentary IIBA® Member Copy. Not for Distribution or Resale. business analysis task..7 Stakeholders The Stakeholders section is composed of a generic list of stakeholders who are likely to participate in performing that task or who will be affected by it. The BABOK® Guide does not mandate that these roles be filled for any given initiative..8 Outputs The Outputs section describes the results produced by performing the task. Outputs are created, transformed, or changed in state as a result of the successful completion of a task. An output may be a deliverable or be a part of a larger deliverable. The form of an output is dependent on the type of initiative underway, standards adopted by the organization, and best judgment of the business analyst as to an appropriate way to address the information needs of key stakeholders. As with inputs, an instance of a task may be completed without an output being in its final state. Tasks that use a specific output do not necessarily have to wait for its completion for work within the task to begin. 1.4.4 Underlying Competencies Underlying competencies reflect knowledge, skills, behaviours, characteristics, and personal qualities that help one successfully perform the role of the business analyst. These underlying competencies are not unique to the business analysis profession. However, successful execution of tasks and techniques is often dependent on proficiency in one or more underlying competencies. Underlying competencies have the following structure: Purpose Definition Effectiveness Measures 7  Structure of the BABOK® Guide Introduction.1 Purpose The Purpose section describes why it is beneficial for business analysts to have this underlying competency..2 Definition The Definition section describes the skills and expertise involved in the application of this competency..3 Effectiveness Measures The Effectiveness Measures section describes how to determine whether a person is demonstrating skills in this underlying competency. 1.4.5 Techniques Complimentary IIBA® Member Copy. Not for Distribution or Resale. Techniques provide additional information on ways that a task may be performed. The list of techniques included in the BABOK® Guide is not exhaustive. There are multiple techniques that may be applied alternatively or in conjunction with other techniques to accomplish a task. Business analysts are encouraged to modify existing techniques or engineer new ones to best suit their situation and the goals of the tasks they perform. Techniques have the following structure: Purpose Description Elements Usage Considerations.1 Purpose The Purpose section describes what the technique is used for and the circumstances under which it is most likely to be applicable..2 Description The Description section describes what the technique is and how it is used..3 Elements The Elements section describes key concepts that are needed to understand how to use the technique..4 Usage Considerations The Usage Considerations section describes the conditions under which the technique may be more or less effective. 8 Introduction Structure of the BABOK® Guide 1.4.6 Perspectives Perspectives are used within business analysis work to provide focus to tasks and techniques specific to the context of the initiative. Most initiatives are likely to engage one or more perspectives. The perspectives included in the BABOK® Guide are: Agile Business Intelligence Information Technology Business Architecture Business Process Management These perspectives do not presume to represent all the possible perspectives from Complimentary IIBA® Member Copy. Not for Distribution or Resale. which business analysis is practiced. The perspectives discussed in the BABOK® Guide represent some of the more common views of business analysis at the time of writing. Perspectives are not mutually exclusive, in that a given initiative might employ more than one perspective. Perspectives have the following structure: Change Scope Business Analysis Scope Methodologies, Approaches, and Techniques Underlying Competencies Impact on Knowledge Areas.1 Change Scope The Change Scope section describes what parts of the enterprise the change encompasses when viewed from this perspective and to what extent it impacts both the objectives and operations of the enterprise. The change scope also identifies the type of problems solved, the nature of the solutions being sought, and the approach to delivering these solutions and measuring their value..2 Business Analysis Scope The Business Analysis Scope section describes the key stakeholders, including a profile of the likely types of sponsors, the target stakeholders, and the business analyst's role within an initiative. It also defines likely outcomes that would be expected from business analysis work in this perspective..3 Methodologies, Approaches, and Techniques The composition of this section is unique to each perspective. In each case it describes the methodologies, approaches, or techniques that are common and specific to the application of business analysis in the perspective. Methodologies 9  Structure of the BABOK® Guide Introduction and approaches are specialized ways of undertaking the business analysis work. The techniques included in this section are techniques that are not included in the Techniques chapter of the BABOK® Guide but are especially relevant to the perspective. In the Business Architecture perspective, reference models are listed instead of methodologies or approaches. In the Business Process Management perspective, frameworks are listed instead of approaches..4 Underlying Competencies The Underlying Competencies section describes the competencies that are most prevalent in the perspective..5 Impact on Knowledge Areas Complimentary IIBA® Member Copy. Not for Distribution or Resale. The Impact on Knowledge Areas section describes how knowledge areas are applied or modified. It also explains how specific activities within a perspective are mapped to tasks in the BABOK® Guide. 10 2 Business Analysis Key Concepts Complimentary IIBA® Member Copy. Not for Distribution or Resale. The Business Analysis Key Concepts chapter includes information that provides a foundation for all other content, concepts, and ideas within the BABOK® Guide. It provides business analysts with a basic understanding of the central ideas necessary for understanding and employing the BABOK® Guide in their daily practice of business analysis. This chapter consists of: Business Analysis Core Concept Model™ (BACCM™): defines a conceptual framework for the business analysis profession. Key Terms: provides definitions of essential concepts, which are highlighted because of their importance to the BABOK® Guide. Requirements Classification Schema: identifies levels or types of requirements that assist the business analyst and other stakeholders in categorizing requirements. Stakeholders: defines roles, and characteristics of groups or individuals participating in or affected by the business analysis activities within a change. Requirements and Designs: describes the distinction between—and the importance of—requirements and designs as they relate to business analysis. 11  The Business Analysis Core Concept Model™ Business Analysis Key Concepts 2.1 The Business Analysis Core Concept Model™ The Business Analysis Core Concept Model™ (BACCM™) is a conceptual framework for business analysis. It encompasses what business analysis is and what it means to those performing business analysis tasks regardless of perspective, industry, methodology, or level in the organization. It is composed of six terms that have a common meaning to all business analysts and helps them discuss both business analysis and its relationships with common terminology. Each of these terms is considered to be a core concept. The six core concepts in the BACCM are: Change, Need, Solution, Stakeholder, Value, and Context. Each core concept is an idea fundamental to the practice of business analysis, and all the concepts are equal and necessary. Each core concept is defined by the other five core concepts and cannot be fully understood until all the concepts are understood. No single concept holds greater importance or Complimentary IIBA® Member Copy. Not for Distribution or Resale. significance over any other concept. These concepts are instrumental to understanding the type of information elicited, analyzed, or managed in business analysis tasks. The BACCM can be used to: describe the profession and domain of business analysis, communicate about business analysis with a common terminology, evaluate the relationships of key concepts in business analysis, perform better business analysis by holistically evaluating the relationships among these six concepts, and evaluate the impact of these concepts and relationships at any point during a work effort in order to establish both a foundation and a path forward. Table 2.1.1: The BACCM Core Concept Description Change The act of transformation in response to a need. Change works to improve the performance of an enterprise. These improvements are deliberate and controlled through business analysis activities. Need A problem or opportunity to be addressed. Needs can cause changes by motivating stakeholders to act. Changes can also cause needs by eroding or enhancing the value delivered by existing solutions. Solution A specific way of satisfying one or more needs in a context. A solution satisfies a need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage of an opportunity. 12 Business Analysis Key Concepts The Business Analysis Core Concept Model™ Table 2.1.1: The BACCM (Continued) Core Concept Description Stakeholder A group or individual with a relationship to the change, the need, or the solution. Stakeholders are often defined in terms of interest in, impact on, and influence over the change. Stakeholders are grouped based on their relationship to the needs, changes, and solutions. Value The worth, importance, or usefulness of something to a stakeholder within a context. Value can be seen as potential or realized returns, gains, and improvements. It is also possible to have a decrease in value Complimentary IIBA® Member Copy. Not for Distribution or Resale. in the form of losses, risks, and costs. Value can be tangible or intangible. Tangible value is directly measurable. Tangible value often has a significant monetary component. Intangible value is measured indirectly. Intangible value often has a significant motivational component, such as a company's reputation or employee morale. In some cases, value can be assessed in absolute terms, but in many cases is assessed in relative terms: one solution option is more valuable than another from the perspective of a given set of stakeholders. Context The circumstances that influence, are influenced by, and provide understanding of the change. Changes occur within a context. The context is everything relevant to the change that is within the environment. Context may include attitudes, behaviours, beliefs, competitors, culture, demographics, goals, governments, infrastructure, languages, losses, processes, products, projects, sales, seasons, terminology, technology, weather, and any other element meeting the definition. The core concepts can be used by business analysts to consider the quality and completeness of the work being done. Within each knowledge area description there are examples of how the core concepts may be used and/or applied during the tasks within the knowledge area. While planning or performing a task or technique, business analysts can consider how each core concept is addressed by asking questions such as: What are the kinds of changes we are doing? What are the needs we are trying to satisfy? What are the solutions we are creating or changing? 13  Key Terms Business Analysis Key Concepts Who are the stakeholders involved? What do stakeholders consider to be of value? What are the contexts that we and the solution are in? If any of the core concepts experience a change, it should cause us to re-evaluate these core concepts and their relationships to value delivery. Figure 2.1.1: The BACCM Changes Complimentary IIBA® Member Copy. Not for Distribution or Resale. Needs Solutions Stakeholders Contexts Value 2.2 Key Terms Business Analysis The BABOK® Guide describes and defines business analysis as the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business Analysis Information Business analysis information refers to the broad and diverse sets of information that business analysts analyze, transform, and report. It is information of any 14 Business Analysis Key Concepts Key Terms kind—at any level of detail—that is used as an input to, or is an output of, business analysis work. Examples of business analysis information include elicitation results, requirements, designs, solution options, solution scope, and change strategy. It is essential to expand the object of many business analysis activities from 'requirements' to 'information' to ensure that all inputs and outputs of business analysis are subject to the tasks and activities described in the BABOK® Guide. For example, when performing 'Plan Business Analysis Information Management' it includes all the examples listed above. If the BABOK® Guide described 'Plan Requirements Management', it would exclude important outputs like elicitation results, solution options, and change strategy. Design Complimentary IIBA® Member Copy. Not for Distribution or Resale. A design is a usable representation of a solution. Design focuses on understanding how value might be realized by a solution if it is built. The nature of the representation may be a document (or set of documents) and can vary widely depending on the circumstances. Enterprise An enterprise is a system of one or more organizations and the solutions they use to pursue a shared set of common goals. These solutions (also referred to as organizational capabilities) can be processes, tools or information. For the purpose of business analysis, enterprise boundaries can be defined relative to the change and need not be constrained by the boundaries of a legal entity, organization, or organizational unit. An enterprise may include any number of business, government, or any other type of organization. Organization An autonomous group of people under the management of a single individual or board, that works towards common goals and objectives. Organizations often have a clearly defined boundary and operate on a continuous basis, as opposed to an initiative or project team, which may be disbanded once its objectives are achieved. Plan A plan is a proposal for doing or achieving something. Plans describe a set of events, the dependencies among the events, the expected sequence, the schedule, the results or outcomes, the materials and resources needed, and the stakeholders involved. Requirement A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled. The nature of the representation may be a document (or set of documents), but can vary widely depending on the circumstances. 15  Requirements Classification Schema Business Analysis Key Concepts Risk Risk is the effect of uncertainty on the value of a change, a solution, or the enterprise. Business analysts collaborate with other stakeholders to identify, assess, and prioritize risks, and to deal with those risks by altering the likelihood of the conditions or events that lead to the uncertainty: mitigating the consequences, removing the source of the risk, avoiding the risk altogether by deciding not to start or continue with an activity that leads to the risk, sharing the risk with other parties, or accepting or even increasing the risk to deal with an opportunity. 2.3 Requirements Classification Schema For the purposes of the BABOK® Guide, the following classification schema Complimentary IIBA® Member Copy. Not for Distribution or Resale. describes requirements: Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative. Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements. Solution requirements: describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories: functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage, and non-functional requirements or quality of service requirements: do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have. Transition requirements: describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity. 2.4 Stakeholders Each task includes a list of stakeholders who are likely to participate in the execution of that task or who will be affected by it. A stakeholder is an individual or group that a business analyst is likely to interact with directly or indirectly. The 16 Business Analysis Key Concepts Stakeholders BABOK® Guide does not mandate that these roles be filled for any given initiative. Any stakeholder can be a source of requirements, assumptions, or constraints. This list is not intended to be an exhaustive list of all possible stakeholder classifications. Some additional examples of people who fit into each of these generic roles are listed in the definitions below. In most cases there will be multiple stakeholder roles found within each category. Similarly, a single individual may fill more than one role. For the purpose of the BABOK® Guide, the generic list of stakeholders includes the following roles: business analyst, operational support, customer, project manager, regulator, Complimentary IIBA® Member Copy. Not for Distribution or Resale. domain subject matter expert, end user, sponsor, implementation subject matter supplier, and expert, tester. 2.4.1 Business Analyst The business analyst is inherently a stakeholder in all business analysis activities. The BABOK® Guide presumes that the business analyst is responsible and accountable for the execution of these activities. In some cases the business analyst may also be responsible for performing activities that fall under another stakeholder role. 2.4.2 Customer A customer uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet. 2.4.3 Domain Subject Matter Expert A domain subject matter expert is any individual with in-depth knowledge of a topic relevant to the business need or solution scope. This role is often filled by people who may be end users or people who have in-depth knowledge of the solution such as managers, process owners, legal staff, consultants, and others. 2.4.4 End User End users are stakeholders who directly interact with the solution. End users can include all participants in a business process, or who use the product or solution. 2.4.5 Implementation Subject Matter Expert An implementation subject matter expert is any stakeholder who has specialized knowledge regarding the implementation of one or more solution components. 17  Stakeholders Business Analysis Key Concepts While it is not possible to define a listing of implementation subject matter expert roles that are appropriate for all initiatives, some of the most common roles are: project librarian, change manager, configuration manager, solution architect, developer, database administrator, information architect, usability analyst, trainer, and organizational change consultant. 2.4.6 Operational Support Operational support is responsible for the day-to-day management and maintenance of a system or product. While it is not possible to define a listing of operational support roles that are appropriate for all initiatives, some of the most common roles are: operations analyst, product analyst, help desk, and release manager. Complimentary IIBA® Member Copy. Not for Distribution or Resale. 2.4.7 Project Manager Project managers are responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project's objectives are met while balancing the project factors including scope, budget, schedule, resources, quality, and risk. While it is not possible to completely define a listing of project management roles that are appropriate for all initiatives, some of the most common roles are: project lead, technical lead, product manager, and team leader. 2.4.8 Regulator Regulators are responsible for the definition and enforcement of standards. Standards can be imposed on the solution by regulators through legislation, corporate governance standards, audit standards, or standards defined by organizational centers of competency. Alternate roles are government, regulatory bodies, and auditor. 2.4.9 Sponsor Sponsors are responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed, and control the budget and scope for the initiative. Alternate roles are executive and project sponsor. 2.4.10 Supplier A supplier is a stakeholder outside the boundary of a given organization or organizational unit. Suppliers provide products or services to the organization and may have contractual or moral rights and obligations that must be considered. Alternate roles are providers, vendors, and consultants. 18 Business Analysis Key Concepts Requirements and Designs 2.4.11 Tester Testers are responsible for determining how to verify that the solution meets the requirements defined by the business analyst, as well as conducting the verification process. Testers also seek to ensure that the solution meets applicable quality standards, and that the risk of defects or failures is understood and minimized. An alternate role is quality assurance analyst. 2.5 Requirements and Designs Eliciting, analyzing, validating, and managing requirements have consistently been recognized as key activities of business analysis. However, it is important to recognize that business analysts are also responsible for the definition of design, at some level, in an initiative. The level of responsibility for design varies based on Complimentary IIBA® Member Copy. Not for Distribution or Resale. the perspective within which a business analyst is working. Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. The shift in focus is often subtle. The classification as a requirement or a design may become less significant as the business analyst's work progresses to a greater understanding of and eventual fulfillment of the need. The tasks in the BABOK® Guide such as Trace Requirements (p. 79) or Specify and Model Requirements (p. 136) may refer to requirements, but the intent is to include designs as well. Business analysis can be complex and recursive. A requirement (or set of requirements) may be used to define a design. That design may then be used to elicit additional requirements that are used to define more detailed designs. The business analyst may hand off requirements and designs to other stakeholders who may further elaborate on the designs. Whether it is the business analyst or some other role that completes the designs, the business analyst often reviews the final designs to ensure that they align with the requirements. The following table provides some basic examples of how information may be viewed as either a requirement or a design. Table 2.5.1: Requirements and Design Requirement Design View six months sales data across multiple A sketch of a dashboard. organizational units in a single view. Reduce amount of time required to pick Process model. and pack a customer order. Record and access a medical patient’s Screen mock-up showing specific history. data fields. 19  Requirements and Designs Business Analysis Key Concepts Table 2.5.1: Requirements and Design (Continued) Requirement Design Develop business strategy, goals, and Business Capability Model. objectives for a new business. Provide information in English and French. Prototype with text displayed in English and French. Stakeholders may present a need or a solution to an assumed need. A business analyst uses activities found in Elicitation and Collaboration (p. 53), Strategy Analysis (p. 99), Requirements Analysis and Design Definition (p. 133), and Solution Evaluation (p. 163) to transform that request into a requirement or design. Regardless of the focus of the stakeholder, the importance of the role of the business analyst lies in continuously asking the question ‘why?’. For example, Complimentary IIBA® Member Copy. Not for Distribution or Resale. “Why is either the requirement or design necessary to provide value to an enterprise and to facilitate the realization of an enterprise’s goals and objectives?”