BABOK Flash Cards
1. Planning Approach
2. Formality and Level of Detail
3. Business Analysis Activities
4. Timing of BA Work
5. Complexity and Risk
6. Acceptance
Plan Business Analysis Governance
1. Decision Making
2. Change Control Process
3. Plan Prioritization Approach
4. Plan for Approvals
Acceptance Criteria
Criteria associated with requirements, products, or the delivery cycle that must be met in order to achieve stakeholder acceptance.
Actor (BA)
A human, device, or system that plays some specified role in interacting with a solution.
Adaptive Approach
An approach where the solution evolves based on a cycle of learning and discovery, with feedback loops which encourage making decisions as late as possible.
Predictive Approach
Defined before implementation to maximize control and minimize risk.
Artifact (BA)
Any solution-relevant object that is created as part of business analysis efforts.
Vertical
A prototype is used to drill down into a proposed solution to uncover requirements and design considerations through multiple layers
Prioritization
The process of determining the relative importance of a set of terms in order to determine the order which they will be addressed.
Solution Assessment is defined as:
Tasks a BA performs to assess the performance and value delivered by a solution.
Solution Requirements
The capabilities and qualities of a solution that meet stakeholder requirements.
Operational Support
Involved in monitoring day-to-day management and maintenance of a system
Evolutionary
A prototype created, reviewed with stakeholders, then modified, then reviewed and modified again
Document Analysis
Elicitation Technique most ideal if the objective is to gather details of the existing solution
Requirements Package
A set of requirements grouped together in a document or presentation for communication to stakeholders.
Business Case
Define the business need & recommend a solution
Business need is composed of Strategic and Tactical business needs
Requirements Sign off is the formal approval of a set of requirements by a sponsor or other decision maker
The business case articulates the projected cost benefit and risk assessment, but most importantly defines: How the cost/benefit will be measured
Business Analyst, as a change enabler, does certain activities during pre-project and continues to contribute even after the project is over.
A set of reasons for the change is called rationale.
Business Analysis:
Pre Project:
Performing needs assessment, creating business case to justify the reason for initiating a project & preparing benefits management plan.
During Project:
Handling the scope part of a project / requirements & designs (Specify & model,verify & validate), allocating the requirements to solution and recommending the best option.
Post Project:
Evaluating the solution for value realization, analyzing the factors preventing and providing recommendations to increase the potential value
If there is no standard, business analyst needs to collaborate with right stakeholders to define the approach (Plan Business Analysis Approach).
In projects, the approach (Plan Business Analysis Approach) can be developed during planning phase.
Document Analysis used to review existing organizational assets that might assist in planning the approach.
Stability indicates the maturity of the requirement. a changing requirements is not stable.
Information Management Approach: It includes the defined approach for how business analysis information will be stored, accessed, and utilized during the change and after the change is complete.
Business Analysis Approach:
The business analyst determines which approach is suitable for the initiative (Predictive / Adaptive), what is the formality or level of details needs to be captured, when the activities are supposed to be performed (In specific phases / iteratively), what activities are part of it, the size of the change and how complex it is and finally getting the consensus of key stakeholders to obtain sign-off.
Stakeholder Engagement Approach:
Business analysts identifies and performs the stakeholder analysis to prepare effective communication and collaboration approach to be followed throughout the initiative.
Governance Approach:
the business analyst determines the suitable governance approach and steps for various decision-making processes including change control, prioritization and approvals.
Information Management Approach:
the business analyst determines the storage and access part of Business Analysis Information including the attributes, level of detail and maintaining it for long term use.
Business Analysis Performance Assessment:
The focus is to understand whether business analysis activities are effectively performed and finding out ways to improve the performance to set guidelines for effective performance.
Understand the Scope of Elicitation:
Business Analyst should be able to recognize and respond if the elicitation activity strays
from the intended scope.
Elicitation Results (confirmed):
Integrated output that the business analyst and other stakeholders agree correctly reflects captured information and confirms that it is relevant and useful as an input to further work.
To summarize, Business analyst verifies the information for correctness to avoid conflicts.
Determine Objectives and Format of Communication
The reason for preparing Business Analyst Information package: communication of requirements and designs to stakeholders, early assessment of quality and planning, evaluation of possible alternatives, formal reviews and approvals, inputs to solution design, conformance to contractual and regulatory obligations, and maintenance for reuse.
Stakeholder Engagement:
Willingness from stakeholders to engage in business analysis activities and interact with the business analyst when necessary.
Prepare for Elicitation:
To understand the scope of the elicitation activity, select appropriate techniques, and plan for (or procure) appropriate supporting materials and resources.
Conduct Elicitation:
To draw out, explore, and identify information relevant to the change.
There are three common types of elicitation:
Collaborative: involves direct interaction with stakeholders, and relies on their experiences, expertise, and judgment.
Research: involves systematically discovering and studying information from materials or sources that are not directly known by stakeholders involved in the change.
Experiments: involves identifying information that could not be known without some sort of controlled test. Some information cannot be drawn from people or documents—because it is unknown. Experiments include observational studies, proofs of concept, and prototypes.
Confirm Elicitation Results:
To check the information gathered during an elicitation session for accuracy and consistency with other information.
Communicate Business Analysis Information:
To ensure stakeholders have a shared understanding of business analysis information.
Manage Stakeholder Collaboration:
To encourage stakeholders to work towards a common goal
Level of Formality:
The effort to trace requirements grows significantly when the number of requirements or level of formality increases.
Maintain Attributes:
An attribute may change even though the requirement does not.
Penalty:
Consequences that result from not implementing a given requirement.
Cost:
Effort and resources needed to implement the requirement. Information about cost typically comes from the implementation team or the vendor. Customers may change the priority of a requirement after learning the cost.
A proof of concept may be developed to establish that high risk options are possible.
Dependencies are identified as part of the task Trace Requirements.
Time Sensitivity:
The 'best before' date of the requirement, refer to seasonal functionality that only has value at a specific time of year.
Prioritization is an assessment of relative value.
Business analysts also ensure each proposed change can be traced back to a need.
Validate:
Relationship between a requirement and a test case or other element that can determine whether a solution fulfills the requirement.
Stability:
The likelihood that the requirement will change, either because it requires further analysis or because stakeholders have not reached a consensus about it. If a requirement is not stable, it may have a lower priority in order to minimize unanticipated rework and wasted effort.
Verify Requirements is for Quality
Validate Requirements is for alignment with business processes
Business Analyst Value Spectrum
Strategy Analysis focuses on Need and Solution Scope
Requirements Analysis & Design Definition (also known as delivery phase) Requirements (needs) and Design(solution)
Solution Evaluation focuses on PoC/Prototype, Pilot/Beta, Operating releases.
Task : Verify Requirements
The requirements and designs are ready for validation, and provides the information needed for further work to be performed.
Identify Assumptions:
Assumptions are identified and defined so that associated risks can be managed.
Define Measurable Evaluation Criteria:
To evaluate how successful the change has been after the solution is implemented.
Validate Performance Measures
Decisions about which measures are used to evaluate solution performance often reside with the sponsor, but may be made by any stakeholder with decision-making authority.
Performance measures themselves rarely trigger a decision about the value of a solution.
Requirements are focused on the need; designs are focused on the solution
Pre Project:
Performing needs assessment, creating business case to justify the reason for initiating a project & preparing benefits management plan.
During Project:
Handling the scope part of a project / requirements & designs (Specify & model,verify & validate), allocating the requirements to solution and recommending the best option.
Post Project:
Evaluating the solution for value realization, analyzing the factors preventing and providing recommendations to increase the potential value
If there is no standard, business analyst needs to collaborate with right stakeholders to define the approach (Plan Business Analysis Approach).
In projects, the approach (Plan Business Analysis Approach) can be developed during planning phase.
Document Analysis used to review existing organizational assets that might assist in planning the approach.
Stability indicates the maturity of the requirement. a changing requirements is not stable.
Information Management Approach: It includes the defined approach for how business analysis information will be stored, accessed, and utilized during the change and after the change is complete.
Business Analysis Approach:
The business analyst determines which approach is suitable for the initiative (Predictive / Adaptive), what is the formality or level of details needs to be captured, when the activities are supposed to be performed (In specific phases / iteratively), what activities are part of it, the size of the change and how complex it is and finally getting the consensus of key stakeholders to obtain sign-off.
Stakeholder Engagement Approach:
Business analysts identifies and performs the stakeholder analysis to prepare effective communication and collaboration approach to be followed throughout the initiative.
Governance Approach:
the business analyst determines the suitable governance approach and steps for various decision-making processes including change control, prioritization and approvals.
Information Management Approach:
the business analyst determines the storage and access part of Business Analysis Information including the attributes, level of detail and maintaining it for long term use.
Business Analysis Performance Assessment:
The focus is to understand whether business analysis activities are effectively performed and finding out ways to improve the performance to set guidelines for effective performance.
Understand the Scope of Elicitation:
Business Analyst should be able to recognize and respond if the elicitation activity strays
from the intended scope.
Elicitation Results (confirmed):
Integrated output that the business analyst and other stakeholders agree correctly reflects captured information and confirms that it is relevant and useful as an input to further work.
To summarize, Business analyst verifies the information for correctness to avoid conflicts.
Determine Objectives and Format of Communication
The reason for preparing Business Analyst Information package: communication of requirements and designs to stakeholders, early assessment of quality and planning, evaluation of possible alternatives, formal reviews and approvals, inputs to solution design, conformance to contractual and regulatory obligations, and maintenance for reuse.
Stakeholder Engagement:
Willingness from stakeholders to engage in business analysis activities and interact with the business analyst when necessary.
Prepare for Elicitation:
To understand the scope of the elicitation activity, select appropriate techniques, and plan for (or procure) appropriate supporting materials and resources.
Conduct Elicitation:
To draw out, explore, and identify information relevant to the change.
There are three common types of elicitation:
Collaborative: involves direct interaction with stakeholders, and relies on their experiences, expertise, and judgment.
Research: involves systematically discovering and studying information from materials or sources that are not directly known by stakeholders involved in the change.
Experiments: involves identifying information that could not be known without some sort of controlled test. Some information cannot be drawn from people or documents—because it is unknown. Experiments include observational studies, proofs of concept, and prototypes.
Confirm Elicitation Results:
To check the information gathered during an elicitation session for accuracy and consistency with other information.
Communicate Business Analysis Information:
To ensure stakeholders have a shared understanding of business analysis information.
Manage Stakeholder Collaboration:
To encourage stakeholders to work towards a common goal
Level of Formality:
The effort to trace requirements grows significantly when the number of requirements or level of formality increases.
Maintain Attributes:
An attribute may change even though the requirement does not.
Penalty:
Consequences that result from not implementing a given requirement.
Cost:
Effort and resources needed to implement the requirement. Information about cost typically comes from the implementation team or the vendor. Customers may change the priority of a requirement after learning the cost.
A proof of concept may be developed to establish that high risk options are possible.
Dependencies are identified as part of the task Trace Requirements.
Time Sensitivity:
The 'best before' date of the requirement, refer to seasonal functionality that only has value at a specific time of year.
Prioritization is an assessment of relative value.
Business analysts also ensure each proposed change can be traced back to a need.
Validate:
Relationship between a requirement and a test case or other element that can determine whether a solution fulfills the requirement.
Stability:
The likelihood that the requirement will change, either because it requires further analysis or because stakeholders have not reached a consensus about it. If a requirement is not stable, it may have a lower priority in order to minimize unanticipated rework and wasted effort.
Verify Requirements is for Quality
Validate Requirements is for alignment with business processes
Business Analyst Value Spectrum
Strategy Analysis focuses on Need and Solution Scope
Requirements Analysis & Design Definition (also known as delivery phase) Requirements (needs) and Design(solution)
Solution Evaluation focuses on PoC/Prototype, Pilot/Beta, Operating releases.
Task : Verify Requirements
The requirements and designs are ready for validation, and provides the information needed for further work to be performed.
Identify Assumptions:
Assumptions are identified and defined so that associated risks can be managed.
Define Measurable Evaluation Criteria:
To evaluate how successful the change has been after the solution is implemented.
Validate Performance Measures
Decisions about which measures are used to evaluate solution performance often reside with the sponsor, but may be made by any stakeholder with decision-making authority.
Performance measures themselves rarely trigger a decision about the value of a solution.
Requirements are focused on the need; designs are focused on the solution
