Business Analysis Book of Knowledge

BUSINESS ANALYSIS PLANNING & MONITORING BABOK V2.
TOPICS COVERED IN THIS MODULE:

 Plan Business Analysis Approach
 Conduct Stakeholder Analysis
 Plan Business Analysis Activities
 Plan Business Analysis Communication
 Plan Requirements Management Process
 Manage Business Analysis Performance
INTRODUCTION:
The Business Analysis Planning and Monitoring Knowledge area defines the tasks associated with the
planning and monitoring analysis activities.
PLAN BUSINESS ANALYSIS APPROACH:
PURPOSE:
 To describe:
o How to select an approach to performing business analysis?
o Which stakeholders need to be involved in the decision?
o Who will be consulted regarding and informed of the approach?
o The rationale for using the approach.
INPUTS:
 Business Need: Defines the problem or opportunity faced by the organization, risk associated
with it, timeframe in which the need must be addressed and how well the need is understood.
 Expert Judgment: Used to determine optimal business analysis approach. May be provided by
stakeholders in the initiative, organizational Centers of Competency, consultants, or associations
and industry groups. Consider prior experience of business analysts and stakeholders while
selecting or modifying an approach.
 Organizational Process Assets: Organizational process assets that may be useful in defining the
business analysis approach include; methodologies for process change or software development,
tools or techniques that are in use or understood by stakeholders, corporate governance
standards and templates for deliverables. In addition to these general standards, the organization
may have guidelines in place for tailoring the process to fit a specific initiative.
Page 1 of 8
BUSINESS ANALYSIS PLANNING & MONITORING BABOK V2.0
ELEMENTS:
All methodologies fit somewhere in the spectrum between plan-driven & change-driven approaches.
Plan-driven approaches focus on minimizing uncertainty and ensuring that the solution is fully
understood before implementation begins. These approaches are preferred when requirements can
effectively be defined in advance of implementation, the risk of an incorrect implementation is
unacceptably high or when managing stakeholder interactions presents significant challenges.
Waterfall method of software engineering and business process re-engineering are examples of plan
driven approaches.
Change-driven approaches focus on rapid delivery of business value in short iterations. These
approaches are preferred when taking an exploratory approach to finding the best solution or for
incremental improvement of an existing solution. Agile methods of software development and
continuous improvement projects are examples of change-driven approaches.
 Timing of Business Analysis Work: Determining when the business analysis efforts should occur,
and if the level of business analysis effort will need to vary over time. This includes determining
whether enterprise analysis, requirements analysis and solution assessment and validation
activities will be performed in phases or iteratively over the course of initiative.
 Formality and Level of Detail of Business Analysis Deliverables: Determine whether requirements
will be delivered as formal documentation or through informal communication, and the level that
should be contained in those documents.
 Requirements Prioritization: Determine how requirements will be prioritized and how those
priorities will be used to define the solution scope.
 Change Management: Consider the expected likelihood and frequency of change.
 Business Analysis Planning Process: Determine the process that will be followed to plan business
analysis activities. In most cases, this process will be integrated into a larger project plan.
 Communication with Stakeholders: Communication may written or verbal, formal or informal.
Plan-driven approach use more formal communication. Change-driven approach relies more on
frequency of communication than on formal documentation.
 Requirements Analysis and Management Tool: Identify business analysis and management tools.
These may shape the selection of business analysis techniques, notations to be used, and the
way that requirements will be packaged.
 Project Complexity: The complexity of the project, the nature of the deliverables, and the overall
risk to the business needs to be taken into consideration. The factors listed below, among others,
increase the complexity of business analysis efforts as they increase:
o Number of stakeholders
o Number of business areas affected
o Number of business systems affected
o Amount and nature of risk
o Uniqueness of requirements
o Number of technical resources required
TECHNIQUES:
 Decision Analysis
 Process Modeling
 Structured Walkthrough
STAKEHOLDERS:
 Customer, Domain SME, End User or Supplier: Depend on their availability and involvement.
 Implementation SME: To be compatible with the implementation lifecycle.
 Tester: The business analysis approach must facilitate appropriate testing activities.
 Project Manager: The business analysis approach to be compatible with other project activities.
 Regulator: Decisions made in tailoring process may require approval.
 Sponsor: Depend on their availability and involvement.
OUTPUT:
 Business Analysis Approach
Page 2 of 8
CONDUCT STAKEHOLDER ANALYSIS:
PURPOSE:
 Identification of stakeholders who may be affected by a proposed initiative.
 Identification of stakeholders who share a common business need.
 Identifying appropriate stakeholders for the project or project phase.
 Determining stakeholder influence/authority regarding the approval of project deliverables.
INPUT:
 Business Need: Identify and analyze position of stakeholders or how their position may change.
 Enterprise Architecture: Describes organizational units and their interactions.
 Organizational Process Assets: Policies, procedures, suggested/prescribed methodologies,
templates and guidelines.
ELEMENTS:
 Identification: Understanding who the stakeholders are and impact of proposed changes on them.
 Complexity of stakeholder groups: The complexity of interactions with a stakeholder group may
be affected by number and variety of direct end users and/or number of interfacing business
processes and automated systems.
 Attitude and Influence: Assess stakeholder attitude and influence over the initiative.
Attitude of stakeholders towards
o The business goals, objectives, and solution approach
o Attitude towards business analysis
o Attitude towards collaboration
o Attitude towards the sponsor
o Attitude towards team members
Influence of stakeholders
o Influence on the project
o Influence in the organization
o Influence needed for the good of the project
o Influence with other stakeholders
 Authority Levels For Business Analysis Work: Identify stakeholders who have authority to
approve deliverables, review and approve documents, request and approve changes, approve the
requirements process that will be used, review and approve the traceability structure and veto
proposed requirements or solution
TECHNIQUES:
 Acceptance and Evaluation Criteria
 Brainstorming
 Interviews
 Organization Modeling
 Requirements Workshops
 Risk Analysis
 Scenarios and Use Cases and User Stories
 Scope Modeling
 Survey/Questionnaire
Page 3 of 8
In addition to general techniques RACI Matrix is prepared, which describes the roles of those
involved in business analysis activities.
o [R] Responsible - does the work
o [A] Accountable - is the decision maker (only one)
o [C] Consulted - must be consulted prior to the work and gives input
o [I] Informed - means that they must be notified of the outcome
Stakeholder Maps are visual diagrams that depict the relationship of stakeholders to the solution
and on another. There are many forms but two are most common:
 A matrix mapping the level of stakeholder influence against the level of stakeholder interest.
 An onion diagram indicating how involved the stakeholder is with the solution.
STAKEHOLDERS:
 Domain SME
 Implementation SME
 Project Manager
 Tester
 Sponsor
 Regulator
OUTPUT:
 Stakeholder List, Roles, and Responsibilities: The information may include:
o List of required roles
o Names and titles of stakeholders
o Category of stakeholders
o Location of stakeholders
o Special needs of stakeholders
o Number of individuals in a stakeholder role
o Influence and interest of stakeholders
o Stakeholder authority levels
PLAN BUSINESS ANALYSIS ACTIVITIES:
PURPOSE:
 Determine which activities the business analyst will perform and when.
 Identify business analysis deliverables.
 Determine the scope of work for the business analysis activities.
 Develop efforts and estimates for business analysis work.
 Identify the management tools required to measure progress of business analysis activities.
INPUT:
 Business Analysis Performance Assessment
 Organizational Process Assets
 Stakeholder List, Roles, and Responsibilities
Page 4 of 8
ELEMENTS:
 Geographic Distribution of Stakeholders: Business analyst must consider the physical location of
key stakeholders. Stakeholders may be collocated or dispersed.
 Type of Project or Initiative: The type of project or initiative may have impact on activities that
needs to be performed. E.g. in a project to purchase a new software package the work will be
different from an effort to develop a new business process. Different kinds of business analysis
initiatives include:
o Feasibility studies
o Process improvement
o Organizational change
o New software development (in-house)
o Outsourced new software development
o Software maintenance or enhancement
o Software package selection
 Business Analysis Deliverables: A list of deliverables is useful as a basis for activity identification.
 Determine Business Analysis Activities: An important tool in defining scope and estimates is
WBS. It defines all the activities to be performed. The elements identified for each activity include:
o Unique Number
o Activity Description
o Assumptions
o Dependencies
o Milestones
TECHNIQUES:
 Estimation
 Functional Decomposition
 Risk Analysis
STAKEHOLDERS:
 Customer, Domain SME, End User, and Supplier: Sources of requirements.
 Implementation SME, Project Manager, Tester: Uses BA deliverables as inputs.
 Operational Support: use business analysis deliverables as a basis for planning operational
support activities or developing appropriate documentation.
 Sponsor: Approval of business analysis deliverables.
OUTPUT:
 Business Analysis Plan(s)
PLAN BUSINESS ANALYSIS COMMUNICATION:
PURPOSE:
A business analysis communications plan describes the proposed structure and schedule for
communications regarding business analysis activities.
INPUT:
 Stakeholder List, Roles, and Responsibilities
Page 5 of 8
ELEMENTS:
 Geography: Collocated or dispersed
 Culture:
o Language
o Relationship to time
o Relationship to task completion
o Relationship to contracts
o Relationship to formal and informal authority
 Project Type: Different types of project will necessitate different deliverables and extent of
documentation will vary. Some examples are:
o A new, customized in-house software development project
o Upgrading the technology or infrastructure of a current system
o Change in a business process or new data for an existing application
o Purchase of a software package
o Short, focused, agile style iterations of software development
 Communication Frequency: Frequency required by various stakeholders.
 Communications Formality: Level of formality required.
TECHNIQUES:
STAKEHOLDERS:
 Customer and supplier
 Domain SME
 End User
 Operational Support
 Project Manager
 Tester
 Regulator
 Sponsor
OUTPUT:
 Business Analysis Communication Plan
PLAN REQUIREMENTS MANAGEMENT PROCESS:
PURPOSE:
 Define the process that will be used to approve requirements for implementation and manage
changes to the solution or requirements scope.
INPUT:
Page 6 of 8
ELEMENTS:
 Repository
 Traceability
 Select Requirements Attributes
 Requirements Prioritization Process
 Change Management
 Tailoring the Requirements Management Process
TECHNIQUES:
 Decision Analysis: Can be used to assess the possible value delivered by a change and assess
areas of uncertainty.
 Problem Tracking: Used to track possible changes and ensure that a decision is reached.
 Risk Analysis: Identify possible risks associated with the change management process and
possible risks associated with making or choosing not to make the change.
STAKEHOLDERS:
 Domain SME, End User: Consulted to assess the importance of requirements and corresponding
value of change requests.
 Implementation SME: To determine the difficulty of implementing a change.
 Operational Support: Informed of changes to ensure solution can operate effectively.
 Project Manager: Changes to the solution and requirements scope are almost certain to impact
the project scope and Solution/requirements scope in turn.
 Tester: To ensure test plans are effective.
 Sponsor: Accountable for the solution scope and must approve prioritization of requirements and
changes to requirements.
OUTPUT:
 Requirements Management Plan
MANAGE BUSINESS ANALYSIS PERFORMANCE:
PURPOSE:
 To manage the performance of business analysis activities to ensure that they are executed as
effectively as possible.
INPUT:
 Business Analysis Performance Metrics
 Organizational Performance Standards
ELEMENTS:
 Performance Measures:
 Performance Reporting
 Preventive And Corrective Action
Page 7 of 8
TECHNIQUES:
 Interviews
 Lessons Learned Process
 Metrics and Key Performance Indicators
 Problem Tracking
 Root Cause Analysis
 Survey/ Questionnaire
In addition to general techniques Variance Analysis is performed. The purpose of this technique is to
analyze discrepancies between planned and actual performance, determine the magnitude of those
discrepancies, causes and recommend corrective and preventive action as required. Variances can be
related to planned versus actual estimates, cost, scope or product expectations.
STAKEHOLDERS:
 Domain SME and End User: To set expectations for their involvement.
 Implementation SME, Operational Support, and Tester: Dependent on the effective performance
of business analysis activities, should be consulted for assessment of activities.
 Project Manager: To keep informed. Project manager must be consulted before changes are
implemented to assess whether those changes will have an impact on the project.
 Sponsor: May require reports on business analysis performance to address problems as they are
identified.
OUTPUT:
 Business Analysis Performance Assessment
 Business Analysis Process Assets
Page 8 of 8
ELICITATION BABOK V2.0

 Prepare for Elicitation
 Conduct Elicitation Activity
 Document elicitation Results
 Confirm Elicitation Results
INTRODUCTION:
Eliciting requirements is a key task in business analysis. Because the requirements serve as the
foundation for the solution to the business needs it is essential that the requirements be complete,
clear, correct, and consistent. The definition of elicitation is:
1. To draw forth or bring out (something latent or potential)
2. To call forth or draw out (as information or a response)
These definitions highlight the need to actively engage the stakeholders in defining requirements.
PREPARE FOR ELICITATION:
PURPOSE:
 Ensure all needed resources are organized and scheduled for conducting the elicitation activities.
INPUT:
 Business Need: Required to understand what information should be elicited? This input is used
when eliciting business requirements.
 Solution Scope and Business Case: Required to understand what information should be elicited?
These inputs are used when eliciting stakeholder, solution, and transition requirements.
 Stakeholder List, Roles, and Responsibilities: Who should participate in elicitation activities?
ELEMENTS:
 Clarify the specific scope for the selected elicitation technique
 Gather any necessary supporting materials.
 Schedule all resources (people, facilities, equipment).
 Notify appropriate parties of the plan.
For group based elicitation (brainstorming, focus group, interview, observation, prototyping etc.)
group rules must be established. Agreement should be reached to the form and frequency of
feedback and mechanism for verification and sign-off.
Page 1 of 4
TECHNIQUES:
• Brainstorming
• Document Analysis
• Focus Groups
• Interface Analysis
• Interviews
• Observation
• Prototyping
• Requirements Workshops
• Survey/Questionnaire
STAKEHOLDERS:
• All: Depending on requirements of elicitation activity.
• Project Manager: Ensures required resources are available.
OUTPUT:
• Scheduled resources
• Supporting Materials
CONDUCT ELICITATION ACTIVITY:
PURPOSE:
 Meet with stakeholder(s) to elicit information regarding their needs and perform elicitation.
INPUT:
 Business Need
 Solution Scope and Business Case
 Organizational Process Assets: Templates and standard processes.
 Requirements Management plan: Determines what information and attributes of requirements
needs to be extracted, tracked.
 Scheduled resources: Relevant stakeholders, locations etc. must be available.
 Supporting Materials: Whiteboards, flipcharts, documents etc. must be available.
ELEMENTS:
• Capturing requirements attributes
• Tracing requirements: Guard against scope creep. Trace requirements back to the business
goals/objectives.
• Metrics: Tracking the elicitation participants and actual time spent in eliciting.
Page 2 of 4
TECHNIQUES:
• Data Dictionary and Glossary
• Brainstorming
• Focus Groups
• Interviews
• Observation
• Prototyping
STAKEHOLDERS:
• Customer, Domain SME, End User, Supplier and Sponsor: Source or requirements.
• Implementation SME, Operational Support, Project Manager, Supplier and Tester: To improve
their understanding and to aid stakeholders in understanding tradeoffs faced by project team.
• Regulator
OUTPUT:
 Elicitation Results
DOCUMENT ELICITATION RESULTS:
PURPOSE:
 Record the information (including issues) provided by stakeholders for use in analysis.
INPUT:
 Elicitation Results
ELEMENTS:
• The technique used for elicitation, as well as the business analysis approach, will determine what
kind of documentation is possible and desirable.
• The documentation can take a number of forms:
o Written documents describing the outcomes, such as meeting minutes.
o Visual or audio recordings.
o Whiteboards (either actual or virtual).
TECHNIQUES:
• Brainstorming
• Focus Groups
• Interviews
• Observation
• Problem Tracking
• Prototyping
STAKEHOLDERS:
 Business Analyst
Page 3 of 4
OUTPUT:
• Requirements [Stated]
• Stakeholder Concerns
CONFIRM ELICITATION RESULTS:
PURPOSE:
 Validate that the stated requirements expressed by the stakeholder match the stakeholder’s
understanding of the problem and the stakeholder’s needs.
INPUT:
 Requirements [Stated, Unconfirmed]: BA’s understanding on stakeholder’s intention.
 Stakeholder Concerns [Unconfirmed]: BA’s understanding on stakeholder’s concerns & issues.
ELEMENTS:
 Vary as per Interviews and observation.
TECHNIQUES:
• Interviews
• Observations
STAKEHOLDERS:
 Anyone who has participated in other elicitation tasks can participate in this task.
OUTPUT:
• Requirements [Stated, Confirmed]
• Stakeholder Concerns [Confirmed]
Page 4 of 4
REQUIREMENTS MANAGEMENT & COMMUNICATION BABOK V2.0

 Manage Solution Scope & Requirements
 Manage Requirements Traceability
 Manage Requirements for Re-use
 Prepare Requirements Package
 Communicate Requirements
INTRODUCTION:
The Requirements Management and Communication Knowledge Area describes the activities and
considerations for managing and expressing requirements to a broad and diverse audience. This
helps to bring the stakeholders to a common understanding of the requirements and the solution.
MANAGE SOLUTION SCOPE & REQUIREMENTS:
PURPOSE:
 Obtain and maintain consensus among key stakeholders regarding the overall solution scope and
the requirements that will be implemented.
 Requirements are baselines after approval. Any change to requirements after base lining need to
be permitted by Change control board except when the project is change driven.
 The solution scope is required as a basis for requirements management and is used to determine
whether a proposed requirement supports the business goals and objectives.
INPUT:
 Requirements Management plan: Defines the process to be followed.
 Solution scope: Requirements must support the solution scope in order to be approved.
 Stakeholder List, Roles, and Responsibilities: Involves reviewers and approvers.
 Stakeholder, Solution, or Transition Requirements [Communicated or Traced].
ELEMENTS:
 Solution Scope Management: Assess all stakeholder and solution requirements to ensure that
they fall within solution scope.
 Conflict and issue management: Conflicts can arise due to difference in perspective/ priorities of
stakeholders and must be resolved before formal approval.
 Presenting Requirements for Review: Determine if the presentation will be formal or informal. The
formal presentation is time taking while during informal presentation there is risk of key
stakeholders missing information or of increased ambiguity.
 Approval: A record of the decision may be kept.
Page 1 of 6
TECHNIQUES:
 Problem tracking
 Base-lining
 Signoff
o Requirements signoff formalizes agreement by stakeholders on accuracy and completeness of
requirements.
o Approval may be verbal or be recorded either physically or electronically.
o If one stakeholder has authority to approve only a subset of requirements then make sure
that each individual requirement must be signed off by at least one appropriate stakeholder.
STAKEHOLDERS:
 Domain SME: May be involved in the review and approval of requirements.
 Implementation SME: May be involved to check feasibility for implementation.
 Project Manager
 Sponsor: Acts as a reviewer and approver of requirements and solution scope.
OUTPUT:
 Requirements [Approved]
MANAGE REQUIREMENTS TRACEABILITY:
PURPOSE:
 Create and maintain relationships between business objectives, requirements, other team
deliverables, and solution components to support business analysis or other activities.
 Identifies and documents the lineage of each requirement, including its backward traceability
(derivation) and forward traceability (Allocation).
 Traceability assists in scope and change management, risk management, time management, cost
management, and communication management.
 Individual requirements almost always have dependencies and interrelationships. There are
several reasons for creating these relationships:
o Impact Analysis
o Requirements Coverage
o Requirements Allocation
INPUT:
 Requirements
ELEMENTS:
 Relationships: Knowing the dependencies and relationships between requirements helps in
determining the sequence of requirements to be addressed. Common relationships include:
o Necessity
o Effort
o Subset
o Cover
o Value
 Impact analysis: Traceability is a useful tool for performing impact analysis.
 Configuration Management System: A specialized requirements management tool is generally
needed to trace large numbers of requirements.
Page 2 of 6
TECHNIQUES:
 Coverage Matrix: A coverage matrix is a table or spreadsheet used to manage tracing. It is
typically used when there are relatively few requirements or when tracing is limited to high-level
requirements (e.g. features or models).
STAKEHOLDERS:
 Implementation SME: Link requirements to the solution.
 Project Manager
 Tester: Traceability of test cases with requirements.
OUTPUT:
 Requirements [Traced]
MANAGE REQUIREMENTS FOR RE-USE:
PURPOSE:
 To manage knowledge of requirements following their implementation.
 Requirements must be clearly named & defined and easily available for other analysts for re-use.
INPUT:
 Requirements
ELEMENTS:
 Ongoing Requirements
 Satisfied Requirements
TECHNIQUES:
 None
STAKEHOLDERS:
 Business Analyst
 Domain SME: Used as references.
 Implementation SME: Used for development of regression tests and impact analysis.
OUTPUT:
 Requirements [Maintained and Reusable]
PREPARE REQUIREMENTS PACKAGE:
Page 3 of 6
PURPOSE:
 To select and structure a set of requirements in an appropriate fashion to ensure that the
requirements are effectively communicated to, understood by, and usable by a stakeholder group
or groups.
 Reasons for preparing a Requirements package includes but not limited to:
o Early assessment of quality and planning
o Evaluation of possible alternatives
o Formal reviews and approvals
o Inputs to solution design
o Conformance to contractual and regulatory obligations
o Maintenance for re-use
 Forms of requirements Package:
o Formal documentation: It is usually based on a template given by organization such as vision
document or requirements specification document.
o Presentation: Delivers a high level overview of the functionality delivered by the solution.
o Models: May be presented in the form of models such as process maps or on a whiteboard.
INPUT:
 Business Analysis Communication Plan
 Requirements
 Requirements Structure
ELEMENTS:
 Work Products and Deliverables:
o Work Product: A document or collection of notes or diagrams used by the business analyst
during the requirements development process. It may or may not become a deliverable but
business analyst may need to share this with stakeholders to clarify requirements, elicit
additional requirements, or assess the feasibility of the solution approach. Examples of work
products include Meeting agendas and minutes, Interview questions and notes, Facilitation
session agendas and notes, Issues log, Work plan, status reports, Presentation slides used
during the project, Traceability matrices.
o Deliverables: A deliverable is a specific output of the business analysis process that the
business analyst has agreed to produce.
 Format:
o The best format choice is the one that best communicates the specific content of the
requirement to the audience who participate in review process.
o Occurrence of more than one audience may lead to creation of more than one requirements
package.
TECHNIQUES:
 Requirements Documentation: Some of the most common types of requirements documents
include-
o Business Requirements Document - includes stakeholder requirements.
o Product roadmap.
o Software/ system Requirements Specification.
o Supplementary Requirements Specifications.
o Vision Document.
 Requirements for Vendor Selection:
If the solution team thinks that a potential solution is available from an outside party, the
business analyst may capture the requirements in the form of a Request for Information (RFI),
Request for Quote (RFQ), or Request for Proposal (RFP). While these terms are sometimes used
interchangeably, they are intended to reflect differing levels of formality in the vendor selection
process.
Page 4 of 6
o An RFI (Request for Information) is generally used when the issuing organization is open to a
number of alternative solutions and is seeking information to evaluate possible options.
o An RFQ (Request for Quote) or RFP (Request for Proposal) is used when the issuing
organization understands the nature of the solution options available to it and is seeking
vendors who can implement an option.
 An RFQ generally follows a less formal review and selection process than an RFP.
 Business analysts must develop evaluation criteria based on the business requirements.
STAKEHOLDERS:
 Domain SMEs and End Users: Need to ensure that all requirements given to the business analyst
has been included in the requirements package.
 Implementation SMEs: Need to obtain an understanding of the requirements.
 Project Manager: The deliverable acts as a “contract” for the project defining the agreed upon
work.
 Regulators
 Sponsors: Their primary goal is to understand that the solution will meet the return on
investment expectations in accordance with their business plan, and to minimize the time
required for them to make an effective decision.
 Testers: They must acquire a thorough understanding of the functional and non-functional
requirements in order to build an effective testing strategy.
OUTPUT:
 Requirements Package
COMMUNICATE REQUIREMENTS:
PURPOSE:
 Communicating requirements is essential for bringing stakeholders to a common understanding
of requirements.
INPUT:
 Business Analysis Communication: Defines what, when, how and to whom.
 Requirements
 Requirements Package
ELEMENTS:
 General Communication: Requirements communication is performed iteratively and in
conjunction with most of the tasks in the other knowledge areas. In many cases,
requirements communication may lead to elicitation of additional requirements.
 Presentations: A presentation may be used:
o To ensure that internal project quality standards have been adhered to
o To obtain business acceptance and sign-off
o To obtain delivery team sign-off
o To obtain testing team sign-off
o As a precursor to delivery
o To prioritize a set of requirements before proceeding to next project stage
o To make decisions regarding solution scope
o To ensure cross-functional fit with other business process areas within same project
Page 5 of 6
o Formal Presentation: Formal presentations typically disseminate information in a well-

organized, structured format. Audience members may be given supporting materials
before or during the presentation. Audience participation/questions may be encouraged.
o In Formal Presentation: It is used as an informal status check of requirements (e.g.
completeness, correctness, impact on other areas). It is used to communicate
requirements to the delivery team or testing team to ensure there is no ambiguity. It is
used to communicate requirements to affected business areas. It is also used to
communicate requirements to other project teams as a facilitation exercise to enhance
requirement clarity.
TECHNIQUES:
 Requirements Workshops
 Structured walkthrough
STAKEHOLDERS:
 All
OUTPUT:
 Communicated Requirements
Page 6 of 6
ENTERPRISE ANALYSIS BABOK V2.0

 Define Business Need
 Assess Capability Gaps
 Determine Solution Approach
 Define Solution Approach
 Define Business Case
INTRODUCTION:
The Enterprise Analysis Knowledge Area describes the business analysis activities which include:
 Analyze business problems and opportunities.
 Assess the current capabilities and required capability to meet business needs and achieve goals.
 Determine most feasible business solution approach.
 Define the solution scope and develop the business case to justify the investment.
 Define and document business requirements (including business need and business case).
DEFINE BUSINESS NEED:
PURPOSE:
 Identify and define why a change to organizational systems or capabilities is required.
New Business needs can be generated in several different ways:

 From the top down: The need to achieve a strategic goal.
 From the bottom up: A problem with the current state of a process, function or system. A
customer complaint or loss of revenue.
 From middle management: A manager needs additional information to make sound decisions.
 From external drivers: Driven by customer demands or competition in market.
INPUT:
 Business Goals and Objectives
 Requirements [Stated]
Page 1 of 6
ELEMENTS:
 Business Goals and Objectives: Goals are longer-term, ongoing, and qualitative statements of a
state or condition that the organization is seeking to establish and maintain. High-level goals can
be decomposed to break down the general strategy into distinct focus areas that may lead to
desired results. As goals are analyzed they are converted into more descriptive, granular and
specific objectives. Objectives must be SMART - Specific, Measurable, Achievable, Relevant,
Time-bounded.
 Business Problem or Opportunity: An issue must be investigated to ensure that there is an
opportunity for improvement when it is resolved. The factors that can be analyzed:
o Adverse impacts the problems are causing and quantify those impacts.
o Expected benefits from any potential solution.
o How quickly can the problem be resolved and cost of doing nothing.
o Underlying source of the problem.
 Desired outcomes:
o Describes the business benefits that will result from meeting business need.
o Proposed solutions must be evaluated against desired outcomes.
TECHNIQUES:
 Benchmarking
 Brainstorming
 Business Rules analysis
 Focus Groups
STAKEHOLDERS:
 Customer or Supplier: Needs of customer or supplier. New Opportunities.
 Domain SME and End user: Likely to be aware of problems or limitations of current system.
 Implementation SME: May be aware of additional capabilities in existing systems.
 Regulators
 Sponsor
OUTPUT:
 Business Need
ASSESS CAPABILITY GAPS:
PURPOSE:
 To identify new capabilities required by enterprise to meet business need.
INPUT:
 Business Need: Assessment is done against business need.
 Enterprise Architecture: Defines current capabilities.
 Solution Performance Assessment: Identifies shortcomings, problems and limitations of existing
solution.
ELEMENTS:
 Current Capability Analysis
 Assessment of new capabilities Requirements
 Assumptions
Page 2 of 6
TECHNIQUES:
 Document Analysis
 SWOT Analysis
STAKEHOLDERS:
 Customer and Supplier
 Domain SME, End user, Implementation SME and Sponsor: Provides inputs on the strengths and
weaknesses of current capabilities.
OUTPUT:
 Required Capabilities
DETERMINE SOLUTION APPROACH:
PURPOSE:
 To determine the most viable solution approach to meet the business need in enough detail to
allow for definition of solution scope and prepare the business case.
INPUT:
 Business Need
ELEMENTS:
 Alternative Generation
 Assumptions and Constraints
 Ranking and Selection of Approaches
TECHNIQUES:
 Benchmarking
 Brainstorming
 Estimation
 SWOT Analysis
In addition to standard techniques Feasibility Analysis can also be performed.
STAKEHOLDERS:
 Customer, Domain SME, End User and Supplier: Can provide suggestions, identify assumptions
and constraints.
 Implementation SME: Needed to assess feasibility of possible approaches.
 Sponsor: May be source of constraints and will likely approve recommended approach.
OUTPUT:
 Solution Approach
Page 3 of 6
DEFINE SOLUTION APPROACH:
PURPOSE:
 To define which new capabilities a project or iteration will deliver.
Solution Scope includes:

 The scope of analysis.
 The capabilities supported by the solution components.
 The capabilities to be supported by individual releases or iterations.
 The enabling capabilities that are required in order for organization develop the capabilities to
meet business need.
INPUT:
 Business Need
 Solution Approach
ELEMENTS:
 Solution Scope Definition: The solution is described in terms of major features and functions to
be included, and the interactions that solution will have with other people and systems. State in-
scope and out-of-scope components.
 Implementation Approach: Describes how the chosen approach will deliver the solution scope.
 Dependencies: Define major technical and business dependencies between solution components.
TECHNIQUES:
 Functional decomposition
 Interface Analysis
 Scope Modeling
 User Stories
In addition to standard techniques Problem or Vision Statement is analyzed.
STAKEHOLDERS:
 Domain SME: Identify affected organizational units, participate in scope modeling and determine
the relative priorities.
 Implementation SME: Allocation of capabilities to solution components and determining time and
effort for deliver new capabilities.
 Project Manager: Defines project scope.
 Sponsor: For setting priorities and approving the solution scope.
OUTPUT:
 Solution Scope
DEFINE BUSINESS CASE:
Page 4 of 6
PURPOSE:
 To determine if an organization can justify the investment required to deliver a proposed solution.
The business case may also include qualitative and quantitative benefits, estimates of cost and
time to break even, profit expectations and follow on opportunities.
INPUT:
 Business Need
 Solution Scope
 Stakeholder Concerns
ELEMENTS:
 Benefits
 Costs
 Risk Assessment
 Results Measurement
TECHNIQUES:
 Decision Analysis: Cost Benefit Analysis.
 Estimation: Forecast the size of investment required.
 Metrics and KPIs: Assessed to support benefit management, measurement and reporting.
 Risk Analysis
 SWOT analysis
 Vendor Assessment
STAKEHOLDERS:
 Sponsor: Approves business case and funding.
 Domain SME: Assists in estimating business benefits expected from the new initiative.
 Implementation SME: Assists in estimating cost projections for the technology needed.
 Project Manager: The project manager will use the business case as an input for a project
charter.
OUTPUT:
 Business Case
Page 5 of 6
Page 6 of 6
REQUIREMENT ANALYSIS BABOK V2.0

 Prioritize Requirements
 Organize Requirements
 Specify and Model Requirements
 Define Assumptions and Constraints
 Verify Requirements
 Validate Requirements
INTRODUCTION:
The Requirements Analysis Knowledge Area describes the tasks and techniques used by a business
analyst to analyze stated requirements in order to define the required capabilities of a potential
solution that fulfill stakeholder needs.
PRIORITIZE REQUIREMENTS:
PURPOSE:
 To determine which requirements should be analyzed further or implemented first. The
importance of requirements may be based on their relative value, risk, difficulty of
implementation etc.
INPUTS:
 Business Case: States the key goals and measures for success of an organization.
 Business Need: Alternative to Business case.
 Requirements
 Requirements Management Plan: Defines criteria of prioritization.
 Stakeholder List, Roles, and Responsibilities: To determine which stakeholder needs to
participate in prioritization process.
Page 1 of 8
ELEMENTS:
Basis for prioritization:
 Business Value: Based on Cost-Benefit analysis. The most valuable is targeted first. This
technique is mostly used in enhancements and agile delivery model.
 Business or Technical Risk: Requirements with highest risk of project failure are done first.
 Implementation Difficulty: Easiest to implement requirements; often selected during pilot of a
new development process.
 Likelihood of Success: Requirements with quick and relatively certain success. Preferred for
controversial projects that needs earlier signs of progress.
 Regulatory or Policy Compliance
 Relationship to Other Requirements: Supports other high priority requirements.

 Stakeholder Agreement: Based on Stakeholders consensus; used in combination with other
approaches.
 Urgency: Time Sensitivity.
Challenges:
 Non-negotiable Demands: Stakeholders avoid difficult choices, fail to recognize the necessity for
making tradeoffs, or desire to rank all as high priority.
 Unrealistic Tradeoffs: Solution development team may try to influence by overestimating the
difficulty or complexity of implementation.
TECHNIQUES:
 Risk Analysis
In addition to general techniques there are some specific techniques used in Requirement Analysis:
1. MoSCoW Analysis:
 Must: Must be satisfied in final solution for the solution to be considered success.
 Should: Represents high priority items that should be included if possible. These are often
critical requirement but can be satisfied in other ways if strictly necessary.
 Could: Desirable but not necessary; include if time/ source permits.
 Won't: Not to be included in present release, can be considered for future.
2. Timeboxing/ Budgeting:
Timeboxing: Used when project team has fixed amount of time and resources.
Budgeting: Used when project team has fixed amount of money.
There are a number of approaches that can be taken to determine which requirements can be
included in timeboxed iteration:
All in: Begin with all requirements and remove in order to meet calendar date or budget limit.
All out: Add requirements one by one to meet the limits.
Selective: Begin with high priority items; add or remove to meet limits.
3. Voting:
 Allocates a fixed amount of resources (votes, play money, other tokens) to each participant to
distribute among the listed requirements. A requirement with most resources takes priority.
STAKEHOLDERS:
 Domain SME: To assess the relative business need and to negotiate their importance.
 Implementation SME: To assess the relative complexity or risk associated with implementation.
 Project Manager: Will implement the requirements and prepare the project plan.
 Sponsor: Ultimately accountable for business solution/ major project.
OUTPUT:
 Requirements [Prioritized]
Page 2 of 8
ORGANIZE REQUIREMENTS:
PURPOSE:
 Identify appropriate models for the business domain and solution scope.
 Organize requirements to clearly depict the inherent relationships and dependencies between
requirements.
INPUT:
 Organizational Process Assets: Structure and types of requirements expected by Stakeholders.
 Solution Scope: Requirements model must be sufficient to fully describe solution scope from all
perspectives.
ELEMENTS:
 Follow Organizational standards; if none exist then BA must select appropriate set of techniques.
 Use simple and consistent definition using enterprise prevalent terminology.
 Document dependencies and interrelationships among requirements.
 Produce a consistent set of models and templates to document requirements.
 Levels of Abstraction: Requirements are described as needing to say "What" needs to be done and
not "How" to do it. Align the perspective with business stakeholders as the decision statement on
solution may be “what” for one audience and “how” for the other.
 Model Selection: The business analyst must determine which types of models will be required to
describe the solution scope. There are a number of modeling concepts:
o User Classes, Profiles, or Roles: These models categorize and describe the people who directly
interact with a solution. These are usually identified by performing Stakeholder Analysis, and
are used in a number of models like Organizational models, Process models and use cases.
o Concepts and Relationships: Concepts correspond to something in real world; a person/
place/ thing/ Organization. They define the objects. Usually described with Data Models.
o Events: A request to business system or organization to do something can be described as an
event. Events can serve as basis for scope model, and may be described in process models,
state diagrams and/or use cases.
o Processes: Processes are sequences of repeatable activities executed within an Organization.
Described in process models, organization models, state diagrams and use cases.
o Rules: Business rules are described as such but may be embedded in process models, state
diagrams and use cases.
TECHNIQUES:
 Business Rules Analysis
 Data Flow Diagrams
 Data Modeling
 Scenarios and Use Cases
 Scope Modeling
 User Stories
Page 3 of 8
STAKEHOLDERS:
 Domain SME, End User, Implementation SME and Sponsor: The models used must be
understandable by these for validation and verification.
 Project Manager: Uses to verify scope and assess the work that needs to be done in the project.
OUTPUT:
SPECIFY AND MODEL REQUIREMENTS:
PURPOSE:
 To analyze expressed stakeholder desires and/or the current state of organization using a
combination of textual statements, matrices, diagrams and formal models.
INPUT:
ELEMENTS:
1. Text:
 Express one and only one requirement at a time.
 Avoid complex conditional clause.
 Do not assume that reader has domain knowledge.
 Use consistent terminologies and that are familiar to stakeholders.
 Express requirements as verb or verb phrase.
 Write in active voice mentioning who or what is responsible for fulfilling the requirement.
2. Matrix Documentation:
 More structured presentation for complex and uniform requirements.
 More often used to express Data dictionary and requirements attributes in tabular form.
 Maintains traceability of requirements to each other, to test cases and for gap analysis.
3. Models:
A model is any simplified representation of a complex reality. Models may be either textual or
graphical or combination of both. Models can:
 Describe a situation or define a problem.
 Define boundaries for business domains and sub-domains.
 Describe though processes and action flows.
 Categorize and create hierarchies of items.
 Show components and their relationships.
 Show business logic.
4. Capture Requirements Attributes:

 As described in Requirements management process.
Page 4 of 8
5. Improvement opportunities:
Analyst should work to identify opportunities to improve the operation of the business.
 Automate or simplify the work people perform.
 Improve access to information.
 Reduce complexities of interfaces.
 Increase consistency of behavior.
 Eliminate redundancy.
TECHNIQUES:
 Acceptance and Evaluation Criteria Definition
 Data Dictionary and Glossary
 Data Flow Diagrams
 Data Modeling
 Interface Analysis
 Non-functional Requirements Analysis
 Prototyping
 Sequence Diagrams
 State Diagrams
 User Stories
STAKEHOLDERS:
 Any
OUTPUT:
 Requirements [Analyzed]
DEFINE ASSUMPTIONS AND CONSTRAINTS:
PURPOSE:
 Identify factors other than requirements that may affect which solutions are viable.
 To document Assumptions and constraints associated with requirements and their attributes.
INPUT:
 Stakeholder Concerns: Identified through elicitation from Stakeholders.
ELEMENTS:
 Assumption
 Business Constraints
 Technical constraints
TECHNIQUES:
 Risk Analysis
Page 5 of 8
STAKEHOLDERS:
 All: Involved in decisions and identifications.
 Implementation SME: Must take these into account when designing solutions.
 Project Manager: Must assess to identify potential risks that may impact delivery attributes.
OUTPUT:
VERIFY REQUIREMENTS:
PURPOSE:
To determine if the requirements:
 Are ready for formal review and validation by customers and users.
 Provide all information required to process requirements further.
Verification is a quality check performed after analysis of a requirement.
INPUT:
 Requirements [Any Except stated]
ELEMENTS:
 Characteristics for requirements quality:
 Cohesive: A cohesive set of requirements relates to only one thing.
 Complete: Each requirement is self-contained without any missing information.
 Consistent: No contraction or duplicity in requirements.
 Correct: Free of defects.
 Feasible: Must be implementable in given resources.
 Modifiable: Logically grouped for modification if required.
 Unambiguous: Individual requirement must never be unclear.
 Testable: There must be a way to prove that requirement has been fulfilled.
 Verification activities: Performed iteratively throughout the requirements analysis process.
 Check for completeness.
 Compare requirements models with each other for missing components/ triggers/ outcomes.
 Make sure all variations have been identified and documented. Pay attention to branching
logics. E.g. "none found", "one and only one found", "more than one found" etc.
 Ensure that all the triggers and outcomes have been accounted in all variations.
 Ensure the terminology used is consistent and understood by all stakeholders.
 Add examples wherever appropriate for clarification.
TECHNIQUES:
STAKEHOLDERS:
 All
OUTPUT:
 Requirements [Verified]
Page 6 of 8
VALIDATE REQUIREMENTS:
PURPOSE:
 Assess alignment with business need, goals & objectives and stakeholder's needs & expectations.
INPUT:
 Business Case
 Stakeholder, Solution, or Transition Requirements [Verified]
ELEMENTS:
 Identify Assumptions.
 Define Measurable Evaluation criteria.
 Determine Business value.
 Determine dependencies for Benefits Realization.
 Evaluate Alignment with Business Case and Opportunity Cost.
TECHNIQUES:
 Prototyping
 Risk Analysis
STAKEHOLDERS:
 All
OUTPUT:
 Requirements [Validated]
Page 7 of 8
Page 8 of 8
SOLUTION ASSESSMENT & VALIDATION BABOK V2.0

 Assess Proposed Solution
 Allocate Requirements
 Assess Organizational Readiness
 Define Transition Requirements
 Validate Solution
 Evaluate Solution Performance
INTRODUCTION:
The Solution Assessment and Validation Knowledge area describes the tasks that are performed in
order to ensure that solutions meet the business need and to facilitate their successful
implementation.
ASSESS PROPOSED SOLUTION:
PURPOSE:
 To assess if the proposed solution delivers enough business value and requirements.
 In case of multiple possible solutions, arrive at the best one. Needs an understanding of
advantages and disadvantages of each.
INPUTS:
 Requirements [Prioritized and Approved]
 Solution Options
ELEMENTS:
 Ranking of solution options
 Identification of additional potential capabilities: Additional capabilities available with one of the
solutions that can be valuable for organization in future.
TECHNIQUES:
 Acceptance and Evaluation criteria definition
 Vendor Assessment
Page 1 of 6
STAKEHOLDERS:
 Domain SME: Provides feedback during selection process and participate in assessment.
 Operational Support: Provide information on technical constraints.
 Project Manager
 Supplier: Provides information on capabilities of solution being provided by him.
 Sponsor
OUTPUT:
 Assessment of Proposed Solution: Arrive at best solution or recommend for termination if no
solution delivers enough value.
ALLOCATE REQUIREMENTS:
PURPOSE:
 Allocation of requirements to solution components and project releases.
 Can be allocated between Organizational units, job functions, and people and software
applications.
 Continues through design and development of a solution, till all requirements are allocated.
INPUT:
 Requirements [Prioritized and Approved]
 Solution [designed]: Defined set of solution components along with cost and effort.
 Solution Scope: Allocation of requirements as per the scope of each release.
ELEMENTS:
 Solution Components: Solution components may include following.
o Business policies and rules.
o Business processes to be performed or managed.
o People who operate and maintain the solution including their responsibilities.
o Software applications and application components used in the solution.
o Structure of the organization, interactions inside and with its customer and suppliers.
Sometimes allocation might need tradeoffs to be effective which may be based on:
o Available resources: BA may need to prepare a business case to justify additional resources.
o Constraints on Solution: prioritized by regulatory or business decisions.
o Dependencies between requirements.
 Release Planning: Distribute requirements into releases and phases based on:
o Overall project budget.
o Time bound implementation of a particular solution.
o Resource constraints/ training schedule.
o Ability of business to absorb changes defined within a defined timeframe.
o Organizational restraints and polices.
o BA ensures that all stakeholders understand various factors and allocate the best set of
requirements.
Page 2 of 6
TECHNIQUES:
STAKEHOLDERS:
 Customers and Suppliers
 Domain SME
 End User
 Project Manager
 Tester
 Sponsor
OUTPUT:
 Requirements [Allocated]
ASSESS ORGANIZATIONAL READINESS:
PURPOSE:
 Understanding effect of new solution and assessing if the organization is prepared for it.
 Plan training and transition programs.
INPUT:
 Enterprise Architecture
 Solution Scope
 Solution [Designed]
 Stakeholders Concern
ELEMENTS:
 Cultural Assessment: Assess the beliefs and attitude of key stakeholders towards the changes.
 Operational or Technical Assessment: Determine if the training programs, supporting policies or
procedures are in place.
 Stakeholder Impact Analysis: Understand how the key stakeholders will be actually affected by
the change based on functions (process and applications), location, tasks and concerns
(proficiency, risk to job, work satisfaction).
TECHNIQUES:
 Data Flow Diagrams and Process Models
 Focus Groups, Interviews, Survey/Questionnaire: Stakeholders concerns/issues.
 Organization Modeling: Identify stakeholders impacted.
 Problem Tracking: Ensure the issues are resolved.
 Risk Analysis
 SWOT Analysis
Page 3 of 6
In addition to general techniques Force Field Analysis is also done.

•Step1. Identify forces for and against the change. Assign "strength" to each of the forces.
•Step2. Look for ways to strengthen forces that support the business outcome
STAKEHOLDERS:
 Domain SME: Provides information on likely impact on stakeholders.
 Implementation SME (Organizational change management SMEs, Usability SMEs, Training
SMEs).
 Project Manager: Assess if some additional work is required to make implementation successful.
 Sponsor: Quick resolution of issues.
OUTPUT:
 Organizational Readiness Assessment
DEFINE TRANSITION REQUIREMENTS:
PURPOSE:
 To define requirements for capabilities needed to transition from an existing system to a new
solution.
 What will be the transition period when both current and new solution will work in parallel?
 Relevant only during transition period. These cannot be defined until solution has been defined.
 If the new solution is adding an entirely new capability, not extending or changing an existing
solution, transition requirements are not required.
INPUT:
 Organizational Readiness Assessment
 Solution [Deployed
 Solution [Designed]
ELEMENTS:
 Data
 Ongoing work
 Organizational change: BA may be involved in developing a process to manage the organizational
change related to the solution.
TECHNIQUES:
 Data Flow Diagrams, Process Modeling & Organization Modeling
 Data Modeling
STAKEHOLDERS:
 Customer: May be negatively affected if transition is done incorrectly.
 Domain SME: Provides information on existing solution and assists in verification and validation
of transition requirements.
 End User: If existing and new solution are both in use, they need to know how to co-ordinate
between them.
 Implementation SME: Will be source of many transition requirements.
Page 4 of 6
 Operational Support: May be to operate two solutions simultaneously.

 Project Manager
 Regulator
 Tester: Verifies if transition has been performed correctly.
 Sponsor: Needs to be informed of potential effects of transition on costs and benefits.
OUTPUT:
 Transition Requirements
VALIDATE SOLUTION:
PURPOSE:
 Determine if delivered solution meets business needs on an on-going basis.
 Determine appropriate actions for issues/ defects.
INPUT:
 Solution [Constructed]
 Requirements [Prioritized and validated]
ELEMENTS:
 Investigate Defective Solution Outputs:
o Identify cases with below acceptable level of quality.
o RCA must be done. Involve Implementation SME if required.
 Assess Defects and Issues:
o Severity of defect(s), probability of occurrence of defect(s).
o Severity of business impact and capacity of business to absorb the impact. Identify the
defects that can be mitigated using work around, those that must be resolved and ones which
need to be delayed till resources are available to address those.
TECHNIQUES:
STAKEHOLDERS:
 Domain SME: Will provide input into the development of acceptance and evaluation criteria.
 End User: May assist in the development of acceptance and evaluation criteria and participate in
acceptance testing.
 Implementation SME: Will support the validation process, investigate defects, correct identified
defects, and participate in the defect prioritization and resolution process.
 Operational Support: Will support the deployment of defect resolutions.
 Project Manager: Responsible for co-ordination of work between the parties involved in the
validation process.
 Tester: Solution verification is the responsibility of the tester.
 Regulator: May review the results of acceptance testing and require that records be kept
regarding the process and outcomes.
 Sponsor: The sponsor (or designate) must accept the solution.
Page 5 of 6
OUTPUT:
 Identified defects
 Mitigating Actions
 Solution Assessment and Validation
EVALUATE SOLUTION PERFORMANCE:
PURPOSE:
 Evaluate functioning solutions to understand the value they deliver and identify opportunities for
improvements.
 Post implementation assessment covering both the negative and positive effect of the solution.
 Understand when, where and why these changes have been implemented and the benefits to the
organization from these.
INPUT:
 Business Requirements
 Identified defects
 Solution performance metrics
 Solution [deployed]
ELEMENTS:
 Understand value delivered by the solution:
o Compare actual and target values of metrics.
o Analyze both under and over performance.
 Validate Solution metrics: Validate the solution metrics for alignment with business goals and
objectives
 Solution replacement or Elimination: Issues that may influence:
o Ongoing Cost of solution versus Initial Investment of alternatives.
o Opportunity Cost.
o Necessity: The lifespan is over.
o Sunk Cost: Decisions should be based on the future investment required and the future
benefits that can be gained.
TECHNIQUES:
 Decision Analysis: Cost/ Benefit Analysis.
 Focus Groups
 Observation
 Survey/Questionnaire
STAKEHOLDERS:
 Customer, Domain SME, and Supplier: Recommendations for improvements.
 End User: problems/ defects.
 Operational Support: Monitoring the performance and effectiveness.
 Regulator
 Sponsor
OUTPUT:
 Solution Performance Assessment
Page 6 of 6
UNDERLYING COMPETENCIES BABOK V2.0

 Analytical Thinking and Problem Solving
 Behavioral Characteristics
 Business Knowledge
 Communication Skills
 Interaction Skills
 Software Applications
INTRODUCTION:
The Underlying Competencies Knowledge area provides a description of behavior, characteristics,
knowledge and personal qualities that support the practice of business analysis.
ANALYTICAL THINKING AND PROBLEM SOLVING:
CREATIVE THINKING:
The business analyst must be effective in generating new ideas for approaches to problem solving
and in generating alternative solutions.
Effectiveness Measures:
 The successful generation and productive consideration of new ideas.
 Application of new ideas to resolve existing problems.
 Willingness of stakeholders to accept new approaches.
DECISION MAKING:
The business analyst must be effective in understanding the criteria involved in making a
decision and assisting others make better decisions.
 Confidence of the participants in the decision-analysis process that a decision is correct.
 New information or alternatives that cause a decision to be revisited are genuinely new.
 Decisions are effective in addressing the underlying problem.
 Impact of uncertainty & new information in making decisions can be effectively addressed.
LEARNING:
The business analyst must be effective at learning business domains and how they function and
then translate that learning into an understanding of how to benefit an organization.
 Agreement by stakeholders that analysis models effectively & completely the describe domain.
 Identification of related problems or issues from multiple areas in the domain.
 Rapid absorption of new information or new domain.
PROBLEM SOLVING:
The business analyst must be effective at defining and solving problems in order to ensure that
the real problem is understood and solutions actually address that problem.
 Confidence of the participants in the problem-analysis process that the selected solution is
correct.
 New solution options can be evaluated effectively using the problem solving framework.
 Selected solutions meet the defined objectives and solve the underlying problem.
 The problem-solving process avoids making decisions based on preconceived notions,
organizational politics etc.
Page 1 of 6
SYSTEMS THINKING:
The business analyst must be effective at understanding how the people, processes and
technology interact.
 Understanding of how a change to a component affects the system as a whole.
 Identification of reinforcing and compensating feedback loops.
 Understanding of how systems adapt to external pressures and changes.
BEHAVIOURAL CHARACTERISTICS:
ETHICS:
The business analyst must be able to behave ethically in order to earn the trust and respect of
stakeholders.
 Decisions are made with due consideration to the interest of all stakeholders.
 Reasons for a decision are clearly articulated and understood.
 Prompt and full disclosure of potential conflicts of interest.
 Honesty regarding one’s abilities, performance and accepting responsibility for failures.
PERSONAL ORGANIZATION:
The business analyst must be able to manage tasks and information effectively.
 The ability to find information quickly.
 Regular on-time completion of tasks.
 Efficiency in the completion of work.
 The ability to identify all outstanding work and status of each work item.
ETHICS:
The business analyst must be effective earning trust of stakeholders which help him to be able to
elicit requirement around sensitive issues more effectively.
 Stakeholders involving business analyst in decision-making.
 Stakeholder acceptance of the business analyst’s recommendations.
 Willingness of stakeholders to discuss controversial topics with the business analyst.
 Willingness of stakeholders to support or defend the business analyst when problems occur.
BUSINESS KNOWLEDGE:
BUSINESS PRINCIPLES AND PRACTICES:

The business analyst must understand the fundamental business principles and best practices
to ensure that they are incorporated into and supported by the solutions.
 Understanding of relevant regulatory, compliance and governance frameworks.
 Understanding of auditing and security issues.
 Understanding of business environments, operations, processes and practices relating to:
o Typical organization structures, job functions and work activities
o Complex business functions and operations
o Common business management concepts, principles activities and practices
Page 2 of 6
INDUSTRY KNOWLEDGE:
The business analyst should have understanding of industry.
 Understanding of industry related material.
 The ability to identify key trends shaping the industry.
 Knowledge of major competitors and partners for the organization.
 Knowledge of major customer segments.
 Knowledge of common products and product types.
 Knowledge of sources of information about the industry.
 Understanding of industry-specific resource and process documents.
 Understanding of industry standard processes and methodologies.
 Understanding of the industry regulatory environment.
ORGANIZATION KNOWLEDGE:
The business analyst should have understanding of organization for which he is performing.
 Understanding of terminology or jargon used.
 Understanding of the products or services offered.
 Ability to identify SMEs in the organization.
 Organizational relationships and politics.
SOLUTION KNOWLEDGE:
The business analysts can use their understanding of existing solutions to identify the most
effective solution/means for implementation of a change.
 Reduced time and cost to implement a required change.
 Shortened time on requirements analysis and/or solution design.
 Understanding when a larger change is justified based on business design.
 Understanding how additional capabilities present in a solution can be deployed to provide
business value.
COMMUNICATION SKILLS:
ORAL COMMUNICATION:
Oral communication skills enable business analyst to effectively express ideas in ways that are
appropriate to the target audience.
 Effectively paraphrasing statements to ensure understanding.
 Effectively facilitating sessions ensuring success through preparedness & co-ordination.
 Developing and delivering powerful presentations by positioning content and objectives
appropriately.
 Can communicate the criticality and urgency in a clam, rational manner with solutions.
TEACHING:
Business analyst must be able to effectively communicate issues and requirements.
 Verify that learners have acquired information that has been imparted to them.
 Ability of learners to use new skills or demonstrate new knowledge.
Page 3 of 6
WRITTEN COMMUNICATION:
These are necessary for business analyst to document elicitation results, requirements and other
information in an effective manner for which medium-to-long term records are required.
 Ability to adjust the style of writing for the needs of the audience.
 Proper use of grammar and style.
 Appropriate choice of words.
 Ability of the reader to paraphrase and describe the content of written communication.
INTERACTION SKILLS:
FACILITATION AND NEGOTIATION:

Business analysts facilitate interactions between stakeholders in order to help them resolve
disagreements regarding priority and nature of requirements.
 Ensuring that participants in discussion correctly understand one another’s positions.
 Use of meeting management skills and tools.
 Preventing discussion from being sidetracked into irrelevant topics.
 Identifying common areas of agreement.
 Effective use of different negotiation skills.
 Ability to identify important issues.
 Understanding and considering all parties’ interests, motivation and objectives.
 Encouraging stakeholders to reach win/win outcomes.
 Understanding the impact of time and timing on negotiations.
 Understanding of political implications in conflicts and negotiates in politically manner.
LEADERSHIP AND INFLUENCING:

Business analyst need to be able to be effective in formal and informal leadership roles, in order
to guide others investigating requirements and to help encourage stakeholder support for a
necessary change.
 Reduced resistance to necessary changes.
 Articulation of a clear and inspiring vision of a desired future state.
 Team members and stakeholders demonstrating a willingness to set aside personal objectives
when necessary.
TEAMWORK:
Business analyst must be able to work closely with other team members to effectively support
their work so that solutions can be effectively implemented.
 Fostering a collaborative working environment.
 Effective resolution of conflict.
 Developing trust among team members.
 Support the team for shared high standards of achievement.
 Team members have a shared sense of ownership of the team goals.
Page 4 of 6
SOFTWARE APPLICATIONS:
GENERAL-PURPOSE APPLICATION:
Business analyst use office productivity applications to document and track requirements.
 Ability to apply an understanding of one tool to other similar tools.
 Able to identify major tools in marketplace and their uses.
 Understands and is able to use most of the major features of the tool.
 Able to use tools to complete requirements-related activities more rapidly than without them.
 Able to track changes to the requirements made through tools.
SPECIALIZED APPLICATIONS:
Business analysts use modeling tools to support the development of formal models and in some
cases, their validation and implementation as well.
 Ability to apply an understanding of one tool to other similar tools.
 Able to identify major tolls in marketplace.
 Understands and is able to use most of the major features of the tool.
 Able to use tools to complete requirements-related activities more rapidly than without them.
 Able to track changes to the requirements made through tools.
Page 5 of 6
Page 6 of 6

Business Analysis Book of Knowledge

Uploaded by

Copyright:

Available Formats

You might also like

Business Analysis Book of Knowledge

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Analysis Book of Knowledge

Uploaded by

Copyright:

Available Formats

BUSINESS ANALYSIS PLANNING & MONITORING BABOK V2.

TOPICS COVERED IN THIS MODULE:

PLAN BUSINESS ANALYSIS APPROACH:

CONDUCT STAKEHOLDER ANALYSIS:

PLAN BUSINESS ANALYSIS ACTIVITIES:

PLAN BUSINESS ANALYSIS COMMUNICATION:

PLAN REQUIREMENTS MANAGEMENT PROCESS:

MANAGE BUSINESS ANALYSIS PERFORMANCE:

TOPICS COVERED IN THIS MODULE:

PREPARE FOR ELICITATION:

CONDUCT ELICITATION ACTIVITY:

DOCUMENT ELICITATION RESULTS:

CONFIRM ELICITATION RESULTS:

TOPICS COVERED IN THIS MODULE:

MANAGE SOLUTION SCOPE & REQUIREMENTS:

MANAGE REQUIREMENTS TRACEABILITY:

MANAGE REQUIREMENTS FOR RE-USE:

PREPARE REQUIREMENTS PACKAGE:

o Formal Presentation: Formal presentations typically disseminate information in a well-

TOPICS COVERED IN THIS MODULE:

DEFINE BUSINESS NEED:

New Business needs can be generated in several different ways:

ASSESS CAPABILITY GAPS:

DETERMINE SOLUTION APPROACH:

DEFINE SOLUTION APPROACH:

Solution Scope includes:

DEFINE BUSINESS CASE:

TOPICS COVERED IN THIS MODULE:

 Relationship to Other Requirements: Supports other high priority requirements.

SPECIFY AND MODEL REQUIREMENTS:

4. Capture Requirements Attributes:

DEFINE ASSUMPTIONS AND CONSTRAINTS:

TOPICS COVERED IN THIS MODULE:

ASSESS PROPOSED SOLUTION:

ASSESS ORGANIZATIONAL READINESS:

In addition to general techniques Force Field Analysis is also done.

DEFINE TRANSITION REQUIREMENTS:

 Operational Support: May be to operate two solutions simultaneously.

EVALUATE SOLUTION PERFORMANCE:

TOPICS COVERED IN THIS MODULE:

ANALYTICAL THINKING AND PROBLEM SOLVING:

BUSINESS PRINCIPLES AND PRACTICES:

FACILITATION AND NEGOTIATION:

LEADERSHIP AND INFLUENCING:

You might also like