Introduction to CCBA Tutorial

1.1 Introduction to CCBA

Hello and welcome to the first lesson of Certification of Competency in Business AnalysisTM or CCBA® (pronounce as C-C-B-A) Certification course offered by Simplilearn. This lesson will provide us a high-level overview of the CCBA® (pronounce as “C-C-B-A”) Certification exam. As we move through the course, we will progress from general requirements to specific techniques and analysis tools that represent the best practices as defined by the International Institute of Business Analysis or IIBA (read as: I-I-B-A). In the next slide, we will discuss the objectives of this lesson.

1.2 Objectives

After completing this lesson, you will be able to Discuss the key concepts of business analysis Identify the required knowledge area Explain the general analysis techniques Recognize the skills of a business analyst Let us start with the introduction to Business Analysis in the next slide.

1.3 Introduction to Business Analysis

Business analysis is the set of tasks and techniques that work as a liaison for stakeholders to understand the structure policies and operations of an organization and to recommend solutions that enable the organization to achieve its goals. Business analysts are people who perform business analysis activities, no matter what their job title or organizational role may be. BABOK® (pronounce as “ba-bok”) Guide is a globally recognized standard for the practice of business analysis. In the subsequent slide, we will introduce the functions of a business analyst.

1.4 Business Analyst

A professional business analyst is a catalyst for change. Often, an organization may not have the internal expertise for the proper implementation of new processes or applications. However, before changes can be made, a company needs to do an assessment of the existing situation and evaluate how the changes will affect the client company during and after the implementation of the changes. Moreover, as an independent assessor, the business analyst can help in identifying a company’s assets and capabilities that will facilitate the solution to business needs. Problems and politics can act as real obstacles for change within a company. An external, independent, and knowledgeable professional can help in breaking the deadlocks and taking constructive actions to fix problems. The analyst can overcome internal inertia against change as well as help to facilitate new solutions and applications. A business analyst creates a positive attitude of collaboration. A self-confident business analyst must be able to develop confidence and trust with clients rapidly by being an engineer of change. This happens when the business analyst is seen as a candid individual and not overly concerned with saying the right thing. The objective should be helping the client. Direct, unfiltered honesty and integrity are the keys to gaining trust. Being seen as an objective “truth teller” is essential in gaining trust. With the proper attitude, a competent business analyst can alter the fear of change into excitement for the challenge and rewards that a change can present. A business analyst needs to be a creative problem solver and should draw on knowledge and experience gained in other projects. However, a business analyst should never hazard a solution until all factors have been analyzed and client buy-in is a high probability. The business analyst must be able to provide leadership, excellent communications, and clear understanding of expectations and how those expectations align with the project deliverables. In the next slide, we will look into the key concepts of business analysis.

1.5 Key Concepts of Business Analysis

The BABOK®(pronounce as “ba-bok”) Guide discusses three key concepts of business analysis: A domain is the area undergoing analysis. It may correspond to the boundaries of an organization or organizational unit. It may also include the key stakeholders outside those boundaries and interactions with those stakeholders. A solution is a set of changes to the current state of an organization. These changes are made to enable that organization to meet a business need, solve a problem, or take advantage of an opportunity. The scope of the solution is usually narrower than the scope of the domain within which it is implemented. Most solutions are a system of interacting solution elements, each of which is potentially solutions in its own right. Examples of solutions and solution components include software applications, web services, business processes, business rules that govern a process, an information technology application, a revised organizational structure, outsourcing, insourcing, redefining job roles, or any other method of creating a capability needed by an organization. Business analysis helps organizations define the optimal solution for their needs, given the set of constraints like time, budget, regulations, and others, under which that organization operates. A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability must be met by or present in a solution or solution component to satisfy a contract, standard, specification, or other formally documented representation of a condition or capability. The next concept is the areas of knowledge.

1.6 Knowledge Areas Introduction

Knowledge areas define what a practitioner of business analysis needs to understand about the distinct phases in a project. As with a formalized quality control program like Six Sigma, the business analyst needs to prepare a plan, document the plan, and implement it. Within the range of the overall planning process, a cluster of activities and tasks that take place in the analysis. Depending on the types of projects a business analyst is accustomed to, each business analyst develops his own process flow as well as accompanying activities and tasks. For the purpose of CCBA® (pronounce as C-C-B-A) Certification exam, the candidate is not expected to know a specific methodology but only those best practices that are published in the BABOK® (pronounce as “ba-bok”) Guide. The candidate should understand the concepts and tools required to support those concepts. The exam looks for an understanding of the relationships between the areas of knowledge. The next slide provides a brief review of the specific areas of knowledge. If there is a need for more in-depth review, refer to the BABOK® (pronounce as “ba-bok”) Guide, published by the International Institute of business analysis.

1.7 Knowledge Areas

Business Analysis Planning and Monitoring is the knowledge area that covers how business analysts determine which activities are necessary to complete a business analysis effort. It covers identification of stakeholders, selection of business analysis techniques, and the process that will be used to manage requirements, and deciding how to assess the progress of the work. The tasks in this area of knowledge govern the performance of all other business analysis tasks. Elicitation describes how business analysts work with the stakeholders to identify and understand their needs and concerns, and understand the environment in which they work. The purpose of elicitation is to ensure that a stakeholder’s actual underlying needs are understood, rather than their stated or superficial desires. Requirements management and communication describes how business analysts manage conflicts, issues, and changes to ensure that stakeholders and the project team remain in agreement on the solution scope. It also describes how the requirements are communicated to stakeholders and how knowledge gained by the business analyst is maintained for future use. We will continue discussing knowledge areas in the next slide.

1.8 Knowledge Areas(contd.)

Enterprise analysis describes how business analysts identify a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business. This knowledge area defines and analyzes problems, business case development, feasibility studies, and the definition of a solution scope. Requirements analysis describes how business analysts prioritize and progressively elaborate the solution requirements. This is done to enable the project team to implement a solution that will meet the needs of the sponsoring organization and stakeholders. It involves analyzing stakeholders’ needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and verifying and validating the resulting requirements. Solution assessment and validation describes how business analysts assess suggested solutions to decide which solution best fits the business need, identify gaps and shortcomings in solutions, and determine necessary workarounds or changes to the solution. It also describes how business analysts assess the deployed solutions. It helps them see how well they have met the original need so that the sponsoring organization can assess the performance and effectiveness of the solution. In the next slide, we will understand relationships under knowledge areas.

1.9 Knowledge Areas Relationships

This schematic diagram demonstrates the interconnection of the various areas of knowledge that encompass all the process knowledge areas in a business analysis process. The cycle starts with elicitation, proceeds to requirements management and communication, and includes the overall business analysis planning and monitoring phase. This involves enterprise analysis, requirement analysis, and solution assessment and validation. In other words, the business analyst needs to gather facts from the entity and its employees to gather information about the business requirements. This helps the analyst to create the goals of the project or the deliverables. Once the deliverables are validated, the knowledge areas shift to the actual analysis process of forming solutions, task design, implementation, quality control, and validation measurements to make sure the business analyst is able to assess the success of the project. In the next slide, we will understand tasks under knowledge areas.

1.10 Knowledge Areas Tasks

The BABOK® (pronounce as “ba-bok”) Guide breaks each knowledge area down into several tasks, which we will be covering later in each separate unit. A task is an essential piece of work that must be performed as part of business analysis. As we have seen in the overview of the knowledge areas, each knowledge area describes the tasks performed by business analysts to accomplish the purpose of that knowledge area. A task should create value through an output for the organization. All the tasks within each knowledge area are necessary and part of a group of best practices in business analysis. In the next few slides, we will discuss general analysis techniques.

1.11 General Analysis Techniques

In almost every business analysis engagement, certain techniques are used to resolve problems or install new procedures that improve the business of the client. Some techniques are used throughout the analysis process and others are related to technical skills associated with a specific part of the project. Acceptance and evaluation criteria is a technique to help determine which requirements can be most effectively used as acceptance or evaluation criteria. Acceptance criteria describe the minimal set of requirements that must be met for a particular solution to be considered worth implementing. Evaluation criteria are the set of requirements that are used to choose an option from multiple solutions. Either acceptance or evaluation criteria may be used to determine if a solution or solution component can be used to meet a requirement objectively. Acceptance criteria are typically used when only one possible solution is being evaluated and are generally expressed as pass or fail. Evaluation criteria are used to compare multiple solutions or solution components and make allowances for a range of possible scores. Brainstorming is a technique intended to produce a broad or diverse set of options. Brainstorming helps answer specific questions such as, but not limited to, what options are available to resolve the issue at hand, what factors constrain the group from moving ahead with an approach or option, what could be causing a delay in activity ‘A’, what the group can do to solve problem ‘B,’ and similar kinds of questions. Brainstorming works by focusing on a topic or problem and then coming up with many possible solutions to it. This technique is best applied in a group as it draws on the experience and creativity of all members of the group. In the absence of a group, one could brainstorm on one’s own to generate new ideas. To heighten creativity, the participants are encouraged to employ new ways of looking at things and associate freely among themselves by generating spontaneous ideas in any direction. Facilitated properly, brainstorming can be fun, engaging, and productive. Business rules analysis directs and constrains the organization and the operation of an organization. A business policy is a directive that supports a business goal. A business rule is a specific, actionable directive that is under the control of an organization and that supports a business policy. Particularly complex rules, or rules with a number of interrelated dependencies, may be expressed as a decision table or decision tree that explains why a decision is made. A number of basic principles guide the business analyst when stating and managing business rules. The business rules should be stated in appropriate terminology to enable domain SMEs to validate the rules. They should be documented independently of how they will be enforced. They should be stated at the most basic level and in declarative format. They should also be separated from the processes they support or constrain. Finally, they should be maintained in a manner that enables the organization to monitor and adapt to the rules as business policies change. Data dictionaries and glossaries are used to formally identify and define all the terminologies used by the organization or organizational unit. For example, an organizational unit may differentiate between a client and a customer, where a client is a party with whom the business has an enforceable professional service agreement, whereas a customer may have a much more casual, transaction-based relationship with the business. In a healthcare organization, such as a hospital, the term patient may be used, along with its unique definition, rather than either client or customer. In the next slide, we will continue discussing general analysis techniques.

1.12 General Analysis Techniques(contd.)

Data flow diagrams help the business analyst to analyze information and process flow and to explain and demonstrate how data moves to clients when seeking stakeholder buy-in. The Data Flow Diagram or DFD (pronounce as D-F-D) provides a visual representation of how information moves through a system. It shows the external entities that provide data to a system or receive data from a system. It also shows the processes of the system that transform data, along with the data stores where the data is collected for some period. Finally, it shows the data flow where the data moves between external entities, processes, and data stores. Data modeling: Not all business analysts need a detailed knowledge of Data Modeling, but here is an idea of what it is. A data model usually takes the form of a diagram supported by textual descriptions. It visually represents the types of people, places, things, and concepts that are important to the business, attributes associated with them, and the significant business relationships among them. The two most widely used types of data models are the Entity-Relationship Diagram or ERD and the Class Diagram. However, there are other modeling notations, which remain in use. The notation used is often determined by the technology platform of the organization. ERDs are generally preferred when the model is used as the basis for a relational database, while class diagrams are preferred for supporting object-oriented development. Business analysts who may have to use these models should understand the unique characteristics of each type of data model. They serve similar purposes but have some important conceptual differences that emerge in practice. Decision analysis is an approach to decision-making that examines and models the possible consequences of different decisions. Decision analysis aids in making an optimal decision under uncertain conditions. Uncertainty may exist because of unknown factors that are relevant to the decision, such as the presence of too many possible interrelated factors to consider, conflicting perspectives on a situation, or tradeoffs between the different available options. Effective decision analysis requires that the analysts understand the values, goals, and objectives that are relevant to the decision problem, the nature of the decision that must be made, the areas of uncertainty that affect the decision, and the consequences of each possible decision. Document analysis may include the analysis of business plans, market studies, contracts, requests for proposal, statements of work, memos, existing guidelines, procedures, training guides, competing product literature, published comparative product reviews, problem reports, customer suggestion logs, and existing system specifications, among others. Identifying and consulting all likely sources of requirements will result in improved requirements coverage, assuming the documentation is up-to-date. Document analysis is used if the objective is to gather details of existing solutions, including business rules, entities, and attributes that need to be included in a new solution or need to be updated for the current solution. This technique also applies in situations where the subject matter experts for the existing solutions are no longer with the organization, or are not going to be available for the entire duration of the elicitation process. In the next slide, we will continue discussing general analysis techniques.

1.13 General Analysis Techniques(contd.)

In an interview, the interviewer formally or informally directs questions to a stakeholder to obtain answers that will be used to create formal requirements. One-on-one interviews are typically most common. In a group interview, with more than one interviewee in attendance, the interviewer must be careful to elicit responses from all attendees. For eliciting requirements, interviews are of two basic types: structured and unstructured. In structured interviews, the interviewer has a pre-defined set of questions and looks for answers. In unstructured interviews, without any pre-defined questions, the interviewer and interviewee discuss topics of interest in an open-ended way. Metrics and key performance indicators are used by an organization to measure progress. An indicator identifies a specific numerical measurement that represents the degree of progress toward achieving a goal, objective, output, activity, or further input. A key performance indicator measures progress toward a strategic goal or objective. Reporting is the process of informing the stakeholders of metrics of indicators in specified formats at specified intervals. Metrics and reporting are key components of monitoring and evaluation. Monitoring is a continuous process of collecting data to determine how well a solution has been implemented, compared to expected results. Evaluation is the systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over a period. It also identifies the ways to improve the solution so that it can meet the objectives better. The top priorities of a monitoring and evaluation system are the intended goals and effects of a solution, as well as the inputs, activities, and outputs. Non-functional requirements document the qualities of a system that are important to the user community and the development community. While qualities such as usability, learnability, reliability, etc., are important to the user community, qualities such as scalability, maintainability, reusability, etc., are important to the development community. Strictly speaking, the term “non-functional requirements” only applies when describing a software application. However, the various categories of non-functional requirements may be applicable to other solution components for which requirements can be developed. For example, reliability requirements for an organizational unit might include specified hours of service, and performance efficiency. A business process might include cycle time to deal with a customer request and may be captured in a service level agreement (SLA). In these cases, an alternative term such as “quality of service” requirements may be preferred. Organizational modeling defines how an organization or organizational unit is structured. Organizational units bring together a group of people to fulfill a common purpose or a goal. This purpose may be functional, that is, the people in question share a common set of skills and knowledge to serve a particular market. An organizational model will define the scope of the organizational unit, the formal relationships among the people who are members of the unit, the roles of those people, and the interfaces between that unit and other units of stakeholders. We will continue our discussion on general analysis techniques in the next slide.

1.14 General Analysis Techniques(contd.)

Problem analysis may include issues, questions, risks, defects, conflicts, or other concerns that need to be tracked to resolution. A problem tracking system ensures that issues are not simply neglected or lost. For each problem, the tracking tool may include the identification of the problem, status updates, assigning of related actions that are required to team members, tracking expected resolution dates, resolution results, actions and decisions taken, priority, and impact. The status of problems should be communicated to all relevant stakeholders. It is important to ensure that problem tracking leads to the resolution of problems in a timely manner. It should also address the issues of eliminating or minimizing the negative impacts, allocation of resources to resolve problems, and identification of root causes of problems. Process modeling describes how multiple people or groups collaborate over a period to work. Processes involve a number of activities that are linked in a sequence. A process is repeatable and may have multiple paths for completion. A process is initiated by an event in the business domain, such as a sale of a product to a customer, a request for information by a senior executive, or a failure to complete a transaction. Events may be triggered by actions taken by a person, rules that cause action to be taken, or simply the passage of time. The process model may involve manual activities, completely automated activities, or a combination of both. The process is complete when the objective or the goal of the process is completed. A process model is a visual representation of the sequential flow and control logic of a set of related activities or actions. Process modeling is used to obtain a graphical representation of a current or future process within an organization. A model may be used at its highest level to obtain a general understanding of a process, or at a lower level, as a basis for simulation so that the process can be made as efficient as possible. A requirements workshop is a highly productive and focused event, which is attended by carefully selected key stakeholders and subject matter experts for a short, but intensive, period, typically one or a few days. The workshop is facilitated by a team member or, ideally, by an experienced and neutral facilitator. A scribe, also known as a recorder, documents the requirements elicited as well as any outstanding issues. A business analyst may be the facilitator or the scribe in these workshops. In situations where the business analyst is a subject matter expert on the topic, he may serve as a workshop participant. However, this must be approached with caution as it can confuse others about the role of business analyst. In addition, there may be suspicion that the business analyst who is also a participant may unduly bias the requirements documentation toward his own viewpoints and priorities. A workshop may be used to generate ideas for new features or products, to reach consensus on a topic, or to review requirements. Other outcomes are often detailed requirements captured in models. While the terms scenario and use case are often used loosely, a scenario is generally understood to describe just one way that an actor can accomplish a particular goal. A use case, on the other hand, describes all the possible outcomes of an attempt to accomplish a particular goal that the solution will support. Scenarios are written as a series of steps performed by actors or the solution that enables an actor to achieve a goal. A use case describes several scenarios in the form of primary and alternate flows. The primary or basic flow represents the simplest way to accomplish the goal of the use case. Special circumstances and exceptions that result in a failure to complete the goal of the use case are documented in alternate flows. In the next slide, we will look into business analyst competencies.

1.15 Business Analyst Competencies

Depending on each business analyst’s experience and his or her familiarity with the industry, most business analysts may specialize in certain competencies. With respect to the exam, every CCBA® (pronounce as C-C-B-A) aspirant should be familiar with each of the competencies and the practical implication of these in business analysis. However, when it comes to software applications, the business analyst should understand the implications of process flow mapping and the general problems of integration with other applications. This does not mean that a business analyst should have programming skills. Instead, the business analyst should understand the needs and requirements. Analytical thinking and problem solving skills support the 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 on 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. Knowledge of general business principles and available case studies promotes better solutions. In the next slide, we will continue our discussion on the competencies required for a business analyst.

1.16 Business Analyst Competencies(contd.)

Communication skills support business analysts in eliciting and communicating requirements to stakeholders. Communication skills address the need to listen to the audience and understand clearly what is being said. They also help in understanding how an audience perceives the business analyst. Besides, they help in understanding the communications objectives, the message, and the most appropriate media and format for communication. Interaction skills support the business analyst while working with a large number of stakeholders. They involve the ability to work as part of a larger team and help it to 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 an 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 as well as 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 the tools. Now, let us go through a few questions to check your understanding of the concepts discussed.

1.18 Summary

In this lesson, we have learned that business analysis is the set of tasks and techniques used to work as a liaison among stakeholders to understand the structure policies and operations of an organization, and to recommend solutions that enable the organization to achieve its goals. The BABOK® (pronounce as “ba-bok”) Guide discusses three key concepts of business analysis: domain, solution, and requirement. Knowledge areas define what a practitioner of business analysis needs to understand about the distinct phases in a project. General analysis techniques are business analysis techniques used to resolve problems, or install new procedures that improve the business of the client.

1.19 Thank You

In the next lesson, we will discuss business analysis planning and monitoring.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy