bussiness analyst

Introduction

The following image shows how three of the knowledge areas support the delivery of business value before, during, and after the life cycle of a project.

What is Business Analysis?

• Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.

• Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.

• Initiatives may be strategic , tactical , or operational.

• It can be used to understand the current state , to define the future state , and to determine the activities required to move from the current to the future state

Who is a Business Analyst?

• A business analyst is any person who performs business analysis tasks described in the BABOK Guide, no matter their job title or organizational role. (business architect, business system analyst, data analyst, enterprise analyst, management consultant, system analyst…)

• Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders.

• The business analyst is responsible for eliciting the actual needs of stakeholders —which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes.

• Business analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders.

The activities that business analysts perform include:

• understanding enterprise problems and goals,
• analyzing needs and solutions,
• devising strategies,
• driving change, and
• facilitating stakeholder collaboration.

Knowledge Areas

Knowledge areas represent areas of specific business analysis expertise that encompass several tasks. Each knowledge area includes a visual representation of its inputs and outputs. The six knowledge areas are:

• Business Analysis Planning and Monitoring: describes the tasks that business analysts perform to organize and coordinate the efforts of business analysts and stakeholders.

• Elicitation and Collaboration: describes the tasks that business analysts perform to prepare for and conduct elicitation activities and confirm the results obtained along with the communication and ongoing collaboration with the stakeholders.

• Requirements Life Cycle Management: describes the tasks that business analysts perform in order to manage and maintain requirements and design information from inception to retirement.

• Strategy Analysis: describes the business analysis work that must be performed to collaborate with stakeholders in order to identify a need of strategic or tactical importance (the business need), enable the enterprise to address that need, and align the resulting strategy for the change with higher- and lower-level strategies.

• Requirements Analysis and Design Definition: describes the tasks that business analysts perform to structure and organize requirements discovered during elicitation activities, specify and model requirements and designs, validate and verify information, identify solution options that meet business needs and estimate the potential value that could be realized for each solution option.

• Solution Evaluation: describes the tasks that business analysts perform to assess the performance of and value delivered by a solution in use by the enterprise, and to recommend removal of barriers or constraints that prevent the full realization of the value.

Business Analysis Key Concepts

Business Analysis Core Concept Model (BACCM)

The six core concepts in the BACCM are: Change, Need, Solution, Stakeholder, Value, and Context.

The core concepts can be used by business analysts to consider the quality and completeness of the work being done. While planning or performing a task or technique, business analysts can consider how each core concept is addressed by asking questions such as:

• What are the kinds of changes we are doing?
• What are the needs we are trying to satisfy?
• What are the solutions we are creating or changing?
• Who are the stakeholders involved?
• What do stakeholders consider to be of value?
• What are the contexts that we and the solution are in?

If any of the core concepts experience a change, it should cause us to re-evaluate these core concepts and their relationships to value delivery.

Key Terms

• Business Analysis: The BABOK Guide describes and defines business analysis as the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.

• Business Analysis Information: Business analysis information refers to the broad and diverse sets of information that business analysts analyze, transform, and report. Examples include elicitation results, requirements, designs, solution options, solution scope, and change strategy.

• Design: A design is a usable representation of a solution. Design focuses on understanding how value might be realized by a solution if it is built.

• Enterprise: An enterprise is a system of one or more organizations and the solutions they use to pursue a shared set of common goals. These solutions (also referred to as organizational capabilities) can be processes, tools or information.

• Organization: An autonomous group of people under the management of a single individual or board, that works towards common goals and objectives. Organizations often have a clearly defined boundary and operate on a continuous basis.

• Plan: A plan is a proposal for doing or achieving something. Plans describe a set of events, the dependencies among the events, the expected sequence, the schedule, the results or outcomes, the materials and resources needed, and the stakeholders involved.

• Requirement: A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled.

• Risk: Risk is the effect of uncertainty on the value of a change, a solution, or the enterprise. Business analysts collaborate with other stakeholders to identify, assess, and prioritize risks, and to deal with those risks by altering the likelihood of the conditions or events that lead to the uncertainty.

Requirements Classification Schema

The following classification schema describes requirements:

• Business requirements : statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.

• Stakeholder requirements : describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.

• Solution requirements : describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories:

  • functional requirements : describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage, and

  • non-functional requirements or quality of service requirements : do not relate directly to the behavior of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.

• Transition requirements : describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.

Stakeholders

• Business Analyst

  Business analyst is responsible and accountable for the execution of these activities and may also be responsible for performing activities that fall under another stakeholder role.

• Customer

  A customer uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet.

• Domain Subject Matter Expert

  A domain subject matter expert is any individual with in-depth knowledge of a topic relevant to the business need or solution scope. Eg. managers, process owners, legal staff, consultants.

• End User

  End users are stakeholders who directly interact with the solution. End users can include all participants in a business process, or who use the product or solution.

• Implementation Subject Matter Expert (实施主题专家)

  An implementation subject matter expert is any stakeholder who has specialized knowledge regarding the implementation of one or more solution components. Eg. project librarian, change manager (变更经理), configuration manager (配置经理), solution architect (解决方案架构师), developer, database administrator, information architect, usability analyst, trainer, and organizational change consultant (组织变更顾问).

• Operational Support (运营支持)

  Operational support is responsible for the day-to-day management and maintenance of a system or product. Eg. operations analyst, product analyst, help desk, and release manager.

• Project Manager

  Project managers are responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project’s objectives are met while balancing the project factors including scope, budget, schedule, resources, quality, and risk.

  Eg. project lead, technical lead, product manager, and team leader.

• Regulator

  Regulators are responsible for the definition and enforcement of standards. Standards can be imposed on the solution by regulators through legislation, corporate governance standards, audit standards, or standards defined by organizational centers of competency. Alternate roles are government, regulatory bodies, and auditor.

• Sponsor

  Sponsors are responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed and control the budget and scope for the initiative. Alternate roles are executive and project sponsor.

• Supplier

  A supplier is a stakeholder outside the boundary of a given organization or organizational unit. Suppliers provide products or services to the organization and may have contractual or moral rights and obligations that must be considered. Alternate roles are providers, vendors, and consultants.

• Tester

  Testers are responsible for determining how to verify that the solution meets the requirements defined by the business analyst, as well as conducting the verification process. Testers also seek to ensure that the solution meets applicable quality standards, and that the risk of defects or failures is understood and minimized. An alternate role is quality assurance analyst.

Requirements and Design

Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements.

A requirement (or set of requirements) may be used to define a design. That design may then be used to elicit additional requirements that are used to define more detailed designs. The business analyst often reviews the final designs to ensure that they align with the requirements.

Stakeholders may present a need or a solution to an assumed need. A business analyst uses activities found in Elicitation and Collaboration to transform that request into a requirement or design. Regardless of the focus of the stakeholder, the importance of the role of the business analyst lies in continuously asking the question ‘why?’

Business Analysis Planning and Monitoring

The Business Analysis Planning and Monitoring knowledge area tasks organize and coordinate the efforts of business analysts and stakeholders. These tasks produce outputs that are used as key guidelines for the other tasks throughout the BABOK Guide. The Business Analysis Planning and Monitoring knowledge area includes the following tasks:

• Plan Business Analysis Approach : describes the planning of business analysis work from creation or selection of a methodology to planning the individual activities, tasks, and

deliverables.

• Plan Stakeholder Engagement : describes understanding which stakeholders are relevant to the change, what business analysts need from them, what they need from business analysts,

and the best way to collaborate.

• Plan Business Analysis Governance : defines the components of business analysis that are used to support the governance function of the organization and help ensure that decisions are made properly and consistently and follows a process that ensures decision makers have the

information they need.

• Plan Business Analysis Information Management : defines how information developed by business analysts (including requirements and designs) is captured, stored, and integrated with

other information for long-term use.

• Identify Business Analysis Performance Improvements : describes managing and monitoring how business analysis work is performed to ensure that commitments are met, and continuous

learning and improvement opportunities are realized.

3.1 Plan Business Analysis Approach (page 24)

3.1.1 Purpose (page 24)

• define an appropriate method to conduct business analysis activities.

3.1.2 Description (page 24)

• describe the overall method that will be followed when performing business analysis work on a

given initiative, how and when tasks will be performed, and deliverables that will be produced.

• identify an initial set of techniques to use. This list may change as the initiative proceeds

The business analysis approach should:

• align to the overall goals of the change,
• coordinate the business analysis tasks with the activities and deliverables of the overall change,
• include tasks to manage any risks that could reduce the quality of business analysis deliverables or impede task efficiency, and
• leverage approaches and select techniques and tools that have historically worked well.

3.1.3 Inputs (page 24)

• Needs : the problem or opportunity faced by the organization. It is necessary to consider what is known about the need at the time of planning, while acknowledging that understanding evolves

throughout business analysis activities.

3.1.4 Elements (page 26)

.1 Planning Approach

• planning methods fit somewhere along a continuum between predictive and adaptive

approaches.

• Predictive approaches focus on minimizing upfront uncertainty and ensuring that the solution is defined before implementation begins in order to maximize control and minimize risk. Preferred in situations where requirements can effectively be defined ahead of implementation, the risk of

an incorrect implementation is unacceptably high, or when engaging stakeholders presents

1

significant challenges.

• Adaptive approaches focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution. Preferred when taking an exploratory approach to finding the best solution or for incremental

improvement of an existing solution.

• Planning typically occurs more than once on a given initiative as plans are updated to address changing business conditions and newly raised issues. The business analysis approach should

describe how plans will be altered if changes are required.

.2 Formality and Level of Detail of Business Analysis Deliverables

• BAs consider the level of formality that is appropriate for approaching and planning the initiative
• Predictive approaches typically call for formal documentation and representations. Information is

captured at various levels of detail.

• Adaptive approaches favour defining requirements and designs through team interaction and gathering feedback on a working solution. Mandatory requirements representations are often

limited to a prioritized requirements list. Formal documentation is often produced after the

1

solution is implemented to facilitate knowledge transfer.

Other considerations that may affect the approach include:

• the change is complex and high risk,

• the organization is in, or interacts with, heavily regulated industries,

• contracts or agreements necessitate formality,

• stakeholders are geographically distributed,

• resources are outsourced,

• staff turnover is high and/or team members may be inexperienced,

• requirements must be formally signed off, and

• business analysis information must be maintained long-term or handed over for use on future initiatives.

.3 Business Analysis Activities

• provides a description of the types of activities that the business analyst will perform. Integrating

business analysis activities in the business analysis approach includes:

• identifying the activities required to complete each deliverable and then breaking each activity into tasks,
• dividing the work into iterations, identifying the deliverables for each iteration, and then identifying the associated activities and tasks, or
• using a previous similar initiative as an outline and applying the detailed tasks and activities unique to the current initiative.

.4 Timing of Business Analysis Work

Business analysts determine when the business analysis tasks need to be performed and if the level of business analysis effort will need to vary over time, along with determining whether the business analysis tasks will be performed primarily in specific phases or iteratively over the course of the initiative. The timing of business analysis activities can also be affected by:

• the availability of resources,
• priority and/or urgency of the initiative,
• other concurrent initiatives, or
• constraints such as contract terms or regulatory deadlines.

.5 Complexity and Risk

The complexity and size of the change and the overall risk of the effort to the organization are considered when determining the business analysis approach. Factors that can impact complexity include:

• increase in complexity and risk
• change in the number of stakeholders
• size of the change,
• number of business areas or systems affected,
• geographic and cultural considerations,
• technological complexities, and
• any risks that could impede the business analysis effort.

Factors that can impact the risk level of a business analysis effort include:

• experience level of the business analyst,
• extent of domain knowledge held by the business analyst,
• level of experience stakeholders have in communicating their needs,
• stakeholder attitudes about the change and business analysis in general,
• amount of time allocated by stakeholders to the business analysis activities,
• any pre-selected framework, methodology, tools, and/or techniques imposed by organizational

policies and practices, and

• cultural norms of the organization.

.6 Acceptance

The business analysis approach is reviewed and agreed upon by key stakeholders. Some organizations may require key stakeholders to sign off on the approach to ensure all business analysis activities have been identified, estimates are realistic, and the proposed roles and responsibilities are correct.

3.1.5 Guidelines and Tools (page 29)

• Business Analysis Performance Assessment
• Business Policies : define the limits within which decisions must be made.
• Expert Judgment
• Methodologies and Frameworks : shape the approach that will be used for business analysis
• Stakeholder Engagement Approach

3.1.6 Techniques (page 29)

• Brainstorming
• Business Cases
• Document Analysis
• Estimation
• Financial Analysis
• Functional Decomposition
  • Interviews
  • Item Tracking
  • Lessons Learned
  • Process Modelling
  • Reviews
  • Risk Analysis and
    • Management
    • Scope Modelling
    • Surveys or Questionnaire
    • Workshops

3.1.7 Stakeholders (page 30)

• Domain Subject Matter Expert
• Project Manager
• Regulator
• Sponsor

3.1.8 Outputs (page 31)

• Business Analysis Approach : identifies the business analysis approach and activities that will be performed across an initiative including who will perform the activities, the timing and

sequencing of the work, the deliverables that will be produced and the business analysis

1

techniques that may be utilized.

3.2 Plan Stakeholder Engagement (page 31)

3.2.1 Purpose (page 31)

• plan an approach for establishing and maintaining effective working relationships with the

stakeholders.

3.2.2 Description

• conducting a thorough stakeholder analysis to identify all of the involved stakeholders and

analyze their characteristics.

• define the best collaboration and communication approaches for the initiative and to

appropriately plan for stakeholder risks.

• the degree of complexity can increase disproportionately as the number of stakeholders involved

in the business analysis activities increases.

3.2.3 Inputs (page 31)

• Needs : business need and the parts of the enterprise that it affects helps in the identification of

stakeholders. Needs may evolve.

• Business Analysis Approach: incorporating the overall business analysis approach into the

stakeholder analysis, collaboration, and communication approaches.

3.2.4 Elements (page 32)

.1 Perform Stakeholder Analysis

• identifying the stakeholders (who will be directly or indirectly impacted by the change) and their characteristics, as well as analyzing the information once collected, which is performed

repeatedly.

• A company’s organizational chart and business processes can serve as an initial source for

identifying internal stakeholders, in addition to sponsors who also identify stakeholders.

• External stakeholders are identified from existing contracts, regulatory and governing bodies. Shareholders, customers, and suppliers are also considered when searching for external

stakeholders.

Important factors to consider while performing the stakeholder analysis are:

Roles: how the stakeholders will contribute to the initiative.

Attitudes: Stakeholder attitudes can positively or negatively impact a change. Business analysts analyze stakeholder attitudes about:

• business goals, objectives of the initiative, and any proposed solutions,
• business analysis in general,
• the level of interest in the change,
• the sponsor,
• team members and other stakeholders, and
• collaboration and a team-based approach.

Decision Making Authority: identify the authority level a stakeholder possesses

Level of Power or Influence: Understanding the influence and attitude of each stakeholder

.2 Define Stakeholder Collaboration

Ensuring effective collaboration with stakeholders is essential for maintaining their engagement in business analysis activities. Collaboration can be a spontaneous event. Some considerations when planning collaboration include:

• timing and frequency of collaboration,
• location,
• available tools such as wikis and online communities,
• delivery method such as in-person or virtual, and
• preferences of the stakeholders.

Planning considerations can be documented in the form of a stakeholder collaboration plan.

.3 Stakeholder Communication Needs

The business analyst evaluates:

• what needs to be communicated,
• what is the appropriate delivery method (written or verbal),
• who the appropriate audience is,
• when communication should occur,
• frequency of communication,
• geographic location of stakeholders who will receive communications,
• level of detail appropriate for the communication and stakeholder, and
• level of formality of communications.

3.2.5 Guidelines and Tools (page 35)

• Business Analysis Performance Assessment : provides results of previous assessments that

should be reviewed and incorporated.

• Change Strategy : used for improved assessment of stakeholder impact and the development of

more effective stakeholder engagement strategies.

• Current State Description : provides the context within which the work needs to be completed.

3.2.6 Techniques (page 35)

3.2.7 Stakeholders (page 36)

• Customers
• Domain Subject Matter Experts
• End Users
• Project Managers
• Regulators
• Sponsor
• Supplier

3.2.8 Outputs (page 36)

• Stakeholder Engagement Approach : contains a list of the stakeholders, their characteristics which were analyzed, and a listing of roles and responsibilities for the change. It also identifies the collaboration and communication approaches the business analyst will utilize during the

initiative.

3.3 Plan Business Analysis Governance (page 37)

3.3.1 Purpose

• define how decisions are made about requirements and designs, including reviews, change

control, approvals, and prioritization.

3.3.2 Description

When planning the governance approach, business analysts identify:

• how business analysis work will be approached and prioritized,

• what the process for proposing a change to business analysis information is,

  • Process Modelling
  • Risk Analysis and Management
  • Scope Modelling
  • Stakeholder List, Map or Personas
  • Survey or Questionnaire
  • Workshops

• Brainstorming

• Business Rules Analysis

• Document Analysis

• Interviews

• Lessons Learned

• Mind Mapping

• Organizational Modelling

• who has the authority and responsibility to propose changes and who should be involved in the

change discussions,

• who has responsibility for analyzing change requests,
• who has the authority to approve changes, and
• how changes will be documented and communicated.

3.3.3 Inputs

**- Business Analysis Approach

• Stakeholder Engagement Approach**

3.3.4 Elements

.1 Decision Making

A stakeholder may serve in various roles in the decision-making process such as:

• participant in decision-making discussions,
• subject matter expert (SME) lending experience and knowledge to the decision-making process,
• reviewer of information, and
• approver of decisions.

The decision-making process defines what happens when teams cannot reach consensus, by identifying escalation paths and key stakeholders who hold final decision-making authority.

.2 Change Control Process

When business analysts develop a change control process, they:

• Determine the process for requesting changes
• Determine the elements of the change request
  • Cost and time estimates
  • Benefits
  • Risks
  • Priority
  • Course(s) of action
• Determine how changes will be prioritized
• Determine how changes will be documented
• Determine how changes will be communicated
• Determine who will perform the impact analysis - Determine who will authorize change

.3 Plan Prioritization Approach

Timelines, expected value, dependencies, resource constraints, adopted methodologies, and other factors influence how requirements and designs are prioritized. When planning the prioritization process, business analysts determine the:

• formality and rigour of the prioritization process,

• participants who will be involved in prioritization,

• process for deciding how prioritization will occur, including which prioritization techniques will be utilized, and

• criteria to be used for prioritization. For example, requirements may be prioritized based on cost, risk, and value.

.4 Plan for Approvals

The business analyst must determine the type of requirements and designs to be approved, the timing for the approvals, the process to follow to gain approval, and who will approve the requirements and designs. Also includes the schedule of events where approvals will occur and how they will be tracked.

3.3.5 Guidelines and Tools

• Business Analysis Performance Assessment : provides results of previous assessments that should be reviewed and incorporated into all planning approaches.
• Business Policies : define the limits within which decisions must be made. May be described by regulations, contracts, agreements, warranties, certifications or other legal obligations.
• Current State Description : provides the context within which the work needs to be completed. This information can help drive how to make better decisions.
• Legal/Regulatory Information : describes legislative rules or regulations that must be followed and can be used to help develop a framework that ensures sound business decision making.

3.3.6 Techniques

3.3.7 Stakeholders

- Domain Subject Matter Experts^ - Project Manager - Regulator - Sponsor

3.3.8 Output

• Governance Approach : identifies the stakeholders who will have the responsibility and authority to make decisions about business analysis work including who will be responsible for setting priorities and who will approve changes to business analysis information. - Organization Modelling - Process Modelling - Reviews - Survey and Questionnaire^ - Workshops^ - Brainstorming - Document Analysis - Interviews - Item Tracking^ - Lessons Learned^

3.4 Plan Business Analysis Information Management (page 42)

3.4.1 Purpose

• develop an approach for how business analysis information will be stored and accessed.^

3.4.2 Description

Information is comprised of all the information business analysts elicit, create, compile, and disseminate in the course of performing business analysis. Information management entails identifying:

• how information should be organized,
• the level of detail at which information should be captured,
• any relationships between the information,
• how information may be used across multiple initiatives and throughout the enterprise,
• how information should be accessed and stored, and
• characteristics about the information that must be maintained.

3.4.3 Inputs

• Business Analysis Approach
• Governance Approach
• Stakeholder Engagement Approach^

3.4.4 Elements

.1 Organization of Business Analysis Information

Information must be well structured to ensure it is not difficult to locate, conflicts with other information, or is needlessly duplicated. Things to consider are type and amount of information to be collected, the stakeholder’s access and usage needs, and the size and complexity of the change.

.2 Level of Abstraction

Level of abstraction describes the breadth and depth of the information being provided.

.3 Plan Traceability Approach

The traceability approach is based on:

• the complexity of the domain,
• the number of views of requirements that will be produced,
• any requirement-related risks, organizational standards, applicable regulatory requirements, and
• an understanding of the costs and benefits involved with tracing.

.4 Plan for Requirements Reuse

Reusing requirements can save an organization time, effort, and cost—provided the requirements are accessible and structured in a manner that supports their reuse.

Requirements that are potential candidates for long-term use are those an organization must meet on an ongoing basis such as:

• regulatory requirements, • contractual obligations, • quality standards, • service level agreements, • business rules, • business processes, or • requirements describing products the enterprise produces.

.5 Storage and Access

Business analysis information can be stored in many ways depending on who must access the information, how often they need to access it, and what conditions must be present for access. It defines how various tools will be used on the initiative and how the information will be captured and stored within those tools.

.6 Requirements Attributes

Requirements attributes provide information about requirements, and aid in the ongoing management of the requirements throughout the change. Some commonly used requirements attributes include:

• Absolute reference (Unique ID), • Author, • Complexity, • Ownership, • Priority, • Risks,^
  • Source, • Stability, • Status, • Urgency

3.4.5 Guidelines and Tools

• Business Analysis Performance Assessments
• Business Policies^
• Information Management Tools
• Legal/ Regulatory Information^

3.4.6 Techniques

3.4.7 Stakeholders

- Domain Subject Matter Experts - Regulator - Sponsor - Mind Mapping - Process Modelling - Survey and Questionnaire - Workshops - Brainstorming - Interviews - Item Tracking - Lessons Learned

3.4.8 Output

• Information Management Approach : includes the defined approach for how business analysis information will be stored, accessed, and utilized during the change and after the change is complete.

3.5 Identify Business Analysis Performance Improvements (page 47)

3.5.1 Purpose

• assess business analysis work and to plan to improve processes where required.

3.5.2 Description

To monitor and improve performance, it is necessary to establish the performance measures, conduct the performance analysis, report on the results of the analysis, and identify any necessary preventive, corrective, or developmental actions. Performance analysis should occur throughout an initiative. Once potential performance improvements are identified, they become guidelines for the next time a task is executed.

3.5.3 Inputs

• Business Analysis Approach
• Performance Objectives (external) : describe the desired performance outcomes that an enterprise or organization is hoping to achieve.

3.5.4 Elements

.1 Performance Analysis

Reports on business analysis performance can be informal and verbal, or they may include formal documentation; and are designed and tailored to meet the needs of the various types of reviewers.

.2 Assessment Measures

Appropriate performance measures enable the business analyst to determine when problems are occurring that may affect the performance of business analysis or identify opportunities for improvement. Measures may be both quantitative and qualitative. Some possible measures are:

• Accuracy and Completeness (correct and relevant)
• Knowledge
• Effectiveness
• Organizational Support
• Significance (value justification)
• Strategic (meet objectives, solve problems and achieve improvements)
• Timeliness

.3 Analyze Results

The business analysis process and deliverables are compared against the set of defined measures. The analysis may be performed on the business analysis process, the resources involved, and the deliverables.

.4 Recommend Actions for Improvement

• Preventive : reduces the probability of an event with a negative impact
• Corrective : establishes ways to reduce the negative impact of an event
• Improvements : establishes ways to increase the probability or impact of events with a positive

impact.

3.5.5 Guidelines and Tools

- Organizational Performance Standards

3.5.6 Techniques

3.5.7 Stakeholders

- Domain Subject Matter Experts^ - Project Manager - Sponsor^

3.5.8 Outputs

Business Analysis Performance Assessment : includes a comparison of planned versus actual performance, identifying the root cause of variances from the expected performance, proposed approaches to address issues, and other findings to help understand the performance of business analysis processes.

- Brainstorming - Interviews - Item Tracking - Lessons Learned - Metrics and Key Performance Indicators (KPIs) - Observation - Process Analysis - Process Modelling - Reviews - Risk Analysis and Management - Root Cause Analysis - Survey and Questionnaire - Workshops

Elicitation and Collaboration

• The Elicitation and Collaboration knowledge area describes the tasks that business analysts perform to obtain information from stakeholders , confirm the results and communicate with stakeholders once the business analysis information is assembled.
• Elicitation is the drawing forth or receiving of information from stakeholders or other^ sources and is the main path to discovering requirements and design information.
• Collaboration is the act of two or more people working together towards a common goal.
• Elicitation and collaboration can be planned , unplanned , or both and is an ongoing activity.^ Planned activities include workshops, experiments, and/or surveys whereas unplanned activities can be last-minute or ‘just in time’ collaboration or conversations.

The Elicitation and Collaboration knowledge area is composed of the following tasks:

**- Prepare for Elicitation

• Conduct Elicitation**^ **- Confirm Elicitation Results
• Communicate Business Analysis Information**^ - Manage Stakeholder Collaboration

4.1 Prepare for Elicitation (page 56)

4.1.1 Purpose

• understand the scope of the elicitation activity, select appropriate techniques, and plan for (or procure) appropriate supporting materials and resources.

4.1.2 Description

• defining the desired outcomes of the activity, considering the stakeholders involved and the goals of the initiative
• determining which work products will be produced using the elicitation results, deciding which techniques are best suited to produce those results, establishing the elicitation logistics, identifying any supporting materials needed, and understanding circumstances to foster collaboration during an elicitation activity.

4.1.3 Inputs

**- Needs

• Stakeholder Engagement Approach**^

4.1.4 Elements

.1 Understand the Scope of Elicitation

To determine the type of business analysis information to be discovered during the elicitation activity and the techniques that may be used, business analysts consider:

• business domain,^
• overall corporate culture and environment,
• stakeholder locations,^
• stakeholders who are involved and their group dynamics,
• expected outputs the elicitation activities will feed,^
• skills of the business analysis practitioner,^
• other elicitation activities planned to complement this one,
• strategy or solution approach,^
• scope of future solution, and
• possible sources of the business analysis information that might feed into the specific elicitation

activity.

.2 Select Elicitation Techniques

The techniques used depend on cost and time constraints, the types of business analysis information sources and their access, the culture of the organization, and the desired outcomes; in addition to the needs of the stakeholders, their availability, and their location (co-located or dispersed). When selecting elicitation techniques, business analysts consider:

• techniques commonly used in similar initiatives,
• techniques specifically suited to the situation, and^
• the tasks needed to prepare, execute, and complete each technique.^

Due to changing dynamics and situations, the business analyst may be required to adjust the initial selections by incorporating more appropriate techniques. A thorough understanding of the variety of techniques available assists the business analyst in adapting to changing circumstances.

.3 Set Up Logistics

Logistics are planned prior to an elicitation activity. The logistics for each elicitation activity include identifying:

• the activity’s goals,
• participants and their roles,
• scheduled resources, including people, rooms, and tools,
• locations,
• communication channels,
• techniques, and
• languages used by stakeholders (oral and written).

.4 Secure Supporting Material

Business analysts identify sources of information that are needed to conduct the elicitation activity. There might be a great deal of information needed to conduct elicitation including people, systems, historical data, materials and documents. Business analysts procure or develop the materials and tools needed.

.5 Prepare Stakeholders

Business analysts may need to educate stakeholders on how an elicitation technique works or what information is needed. Stakeholders may be unresponsive or challenging during an elicitation activity. In preparing for elicitation, the business analyst should ensure that there is buy-in from all necessary stakeholders.

4.1.5 Guidelines and Tools

• Business Analysis Approach
• Business Objectives
• Existing Business Analysis Information^
• Potential Value

4.1.6 Techniques

- Interviews - Mind Mapping - Risk Analysis and Management - Stakeholder List, Map, or Personas - Brainstorming - Data Mining - Document Analysis - Estimation

4.1.7 Stakeholders

- Domain Subject Matter Experts - Project Manager - Sponsor

4.1.8 Outputs

• Elicitation Activity Plan : used for each elicitation activity. It includes logistics, scope of the elicitation activity, selected techniques, and supporting materials.

4.2 Conduct Elicitation (page 61)

4.2.1 Purpose

• draw out, explore, and identify information relevant to the change.^

4.2.2 Description

There are three common types of elicitation:

• Collaborative : involves direct interaction with stakeholders, and relies on their experiences,

1

expertise, and judgment.

• Research : involves systematically discovering and studying information from materials or

1
2

sources that are not directly known by stakeholders involved in the change. Research can
include data analysis of historical data to identify trends or past results.

• Experiments : involves identifying information that could not be known without some sort of controlled test. Experiments can help discover previously unknown information. Experiments include observational studies, proofs of concept, and prototypes.

Stakeholders may collaborate in elicitation by:

• participating and interacting during the elicitation activity, and
• researching, studying, and providing feedback on documents, systems, models, and interfaces.

4.2.3 Inputs

- Elicitation Activity Plan

4.2.4 Elements

.1 Guide Elicitation Activity

In order to help guide and facilitate towards the expected outcomes, business analysts consider:

• the elicitation activity goals and agenda,

• scope of the change,

• what forms of output the activity will generate,

• what other representations the activity results will support,^

• how the output integrates into what is already known,

• who provides the information,

• who will use the information, and

• how the information will be used.

.2 Capture Elicitation Outcomes

If the elicitation activity is unplanned, outcomes are captured and integrated into the appropriate planned outcomes. Capturing the elicitation outcomes helps to ensure that the information produced during elicitation activities is recorded for later reference and use.

4.2.5 Guidelines and Tools

• Business Analysis Approach
• Existing Business Analysis Information
• Stakeholder Engagement Approach
• Supporting Materials^

4.2.6 Techniques

4.2.7 Stakeholders

- Customers - Domain Subject Matter Experts - End Users - Implementation Subject Matter Experts - Sponsor - Any stakeholders

4.2.8 Outputs

• Elicitation Results (unconfirmed) : captured information in a format that is specific to the elicitation activity. - Interface Analysis - Interviews - Mind Mapping - Observation - Process Analysis - Process Modelling - Prototyping - Survey or Questionnaire - Workshops
• Benchmarking and Market Analysis
• Brainstorming
• Business Rules Analysis
• Collaborative Games
• Concept Modelling
• Data Mining
• Data Modelling
• Document Analysis
• Focus Groups

4.3 Confirm Elicitation Results (page 65)

4.3.1 Purpose

• check the information gathered during an elicitation session for accuracy and consistency with other information.

4.3.2 Description

Elicited information is confirmed to identify any problems and resolve them before resources are committed to using the information. This review may discover errors, omissions, conflicts, and ambiguity.

4.3.3 Inputs

- Elicitation Results (Unconfirmed)

4.3.4 Elements

.1 Compare Elicitation Results Against Source Information

Task Conduct Elicitation (p. 61) describes sources from which elicitation results may be derived, including documents and stakeholder knowledge. The business analyst may lead follow-up meetings where stakeholders correct the elicitation results.

.2 Compare Elicitation Results Against Other Elicitation Results

Business analysts compare results collected through multiple elicitation activities, identify variations in results and resolve them, to confirm that the information is consistent and accurately represented.

4.3.5 Guidelines and Tools

• Elicitation Activity Plan
• Existing Business Analysis Information

4.3.6 Techniques

4.3.7 Stakeholders

- Domain Subject Matter Experts - Any stakeholders

4.3.8 Outputs

• 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. - Reviews - Workshops
• Document Analysis
• Interviews

4.4 Communicate Business Analysis Information (page 67)

4.4.1 Purpose

• Ensure stakeholders have a shared understanding of business analysis information.

4.4.2 Description

• Business analysts must communicate appropriate information to stakeholders at the right time and in formats that meet their needs considering the language, tone, and style that is appropriate to the audience.
• Communication of business analysis information is bi-directional and iterative. It involves determining the recipients, content, purpose, context, and expected outcomes.
• Business analysts engage stakeholders to ensure they understand the information and gain agreement. The business analyst acts on any disagreements.

4.4.3 Inputs

**- Business Analysis Information

• Stakeholder Engagement Approach**

4.4.4 Elements

.1 Determine Objectives and Format of Communication

Business analysis information packages may be prepared for a number of reasons including:

• 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

The primary goal of developing a package is to convey information clearly and in usable format for continuing change activities. Possible forms for packages may include:

• Formal Documentation : usually based on a template used by the organization and may include

text, matrices, or diagrams. It provides a stable, easy to use, long-term record of the information.

• Informal Documentation : may include text, diagrams, or matrices that are used during a^

change but are not part of a formal organizational process.

• Presentations : deliver a high-level overview appropriate for understanding goals of a change,^

functions of a solution, or information to support decision making.

.2 Communicate Business Analysis Package

The main purpose of this is to provide stakeholders with the appropriate level of detail about the change so they can understand the information it contains. Stakeholders are given the opportunity to review the package, ask questions about the information, and raise any concerns they may have. Common communication platforms include:

• Group collaboration : used to communicate the package to a group of relevant stakeholders at the same time. It allows immediate discussion about the information and related issues.
• Individual collaboration : used to communicate the package to a single stakeholder at a time to gain individual understanding of the information when a group setting is not feasible, most productive, or going to yield the best results.
• E-mail or other non-verbal methods : used to communicate the package when there is a high maturity level of information that will need little or no verbal explanation to support it.

4.4.5 Guidelines and Tools

• Business Analysis Approach^
• Information Management Approach^

4.4.6 Techniques

4.4.7 Stakeholders

- End User - Customer - Domain Subject Matter Expert^ - Implementation Subject Matter Expert - Tester - Any stakeholders

4.4.8 Outputs

• Business Analysis Information (communicated) : business analysis information is considered communicated when the target stakeholders have reached an understanding of its content and implications.

4.5 Manage Stakeholder Collaboration (page 71)

4.5.1 Purpose

• Encourage stakeholders to work towards a common goal.

4.5.2 Description

• Stakeholders hold various degrees of influence and authority over the approval of work^ products, and are also an important source of needs, constraints, and assumptions. As the
• Interviews^ • Workshops^
• Reviews

1
2
3

business analysis work progresses, the business analyst identifies stakeholders, confirms their
roles, and communicates with them to ensure that the right stakeholders participate at the right
times and in the appropriate roles.

• Managing stakeholder collaboration is an ongoing activity. Although managing stakeholder collaboration begins once stakeholders have been identified and analyzed, new stakeholders may be identified at any point during an initiative.
• The more significant the impact of the change or its visibility within the organization, the more^ attention is directed to managing stakeholder collaboration. Business analysts manage stakeholder collaboration to capitalize on positive reactions, and mitigate or avoid negative reactions.
• Business analysts actively manage relationships with stakeholders who:
  • provide services to the business analyst, including inputs to business analysis tasks and other support activities,
  • depend on services provided by the business analyst, including outputs of business analysis tasks, and
  • participate in the execution of business analysis tasks.

4.5.3 Inputs

**- Stakeholder Engagement Approach

• Business Analysis Performance Assessment**^

4.5.4 Elements

.1 Gain Agreement on Commitments

Stakeholders participate in business analysis activities that may require time and resource commitments. The business analyst and stakeholders identify and agree upon these commitments as early in the initiative as possible. The specific details of the commitments can be communicated formally or informally, as long as there is explicit understanding of the expectations and desired outcomes of the commitment.

.2 Monitor Stakeholder Engagement

Business analysts monitor the participation and performance of stakeholders to ensure that:

• the right subject matter experts (SMEs) and other stakeholders are participating effectively,
• stakeholder attitudes and interest are staying constant or improving,
• elicitation results are confirmed in a timely manner, and
• agreements and commitments are maintained.

Business analysts continually monitor for such risks as:

• stakeholders being diverted to other work,
• elicitation activities not providing the quality of business analysis information required, and
• delayed approvals.

.3 Collaboration

Stakeholders are more likely to support change if business analysts collaborate with them and encourage the free flow of information, ideas, and innovations. Genuine stakeholder engagement requires that all stakeholders involved feel that they are heard, their opinions matter, and their contributions are recognized. Collaboration involves regular, frequent, and bi-directional communication.

4.5.5 Guidelines and Tools

• Business Analysis Approach
• Business Objectives
• Future State Description
• Recommended Actions
• Risk Analysis Results

4.5.6 Techniques

4.5.7 Stakeholders

- All stakeholders^

4.5.8 Outputs

• Stakeholder Engagement : willingness from stakeholders to engage in business analysis activities and interact with the business analyst when necessary. - Risk Analysis and Management - Stakeholder List, Map, or Personas^
• Collaborative Games^
• Lessons Learned^

Requirements Life Cycle Management

• The Requirements Life Cycle Management knowledge area describes the tasks that business analysts perform in order to manage and maintain requirements and design information from inception to retirement.

• These tasks describe establishing meaningful relationships between related requirements and designs , assessing changes (评估变更) to requirements and designs when changes are proposed , and analyzing and gaining consensus on changes (分析变更并就变更达成共识).

• The purpose of requirements life cycle management is to ensure that business, stakeholder, and solution requirements and designs are aligned to one another and that the solution implements them. It involves a level of control over requirements and over how requirements will be implemented in the actual solution to be constructed and delivered. It also helps to ensure that business analysis information is available for future use. The requirements life cycle:

  • begins with the representation of a business need as a requirement,
  • continues through the development of a solution, and
  • ends when a solution and the requirements that represent it are retired.

  

The Requirements Life Cycle Management knowledge area includes the following tasks:

• Trace Requirements: analyzes and maintains the relationships between requirements, designs, solution components, and other work products for impact analysis, coverage, and allocation.
• Maintain Requirements: ensures that requirements and designs are accurate and current throughout the life cycle and facilitates reuse where appropriate
• Prioritize Requirements: assesses the value, urgency (紧迫性), and risks associated with particular requirements and designs to ensure that analysis and/or delivery work (交付工作) is done on the most important ones at any given time.
• Assess Requirements Changes: evaluates new and changing stakeholder requirements to determine if they need to be acted on within the scope of a change.
• Approve Requirements: works with stakeholders involved in the governance process to reach approval and agreement on requirements and designs.

Trace Requirements

• Purpose

  Ensure that requirements and designs at different levels are aligned to one another, and to manage the effects of change to one level on related requirements.

  Requirements traceability identifies and documents the lineage of each requirement, including its backward traceability, its forward traceability, and its relationship to other requirements.

  Traceability enables:

  • faster and simpler impact analysis,
  • more reliable discovery of inconsistencies and gaps in requirements,
  • deeper insights into the scope and complexity of a change, and
  • reliable assessment of which requirements have been addressed and which have not.

• Relationships between two requirements

• Traceability Repository

  Requirements traceability is documented and maintained in accordance with the methods identified by the business analysis approach.

• Expected

  • Requirements (traced) : have clearly defined relationships to other requirements, solution components, or releases, phases, or iterations, within a solution scope, such that coverage and the effects of change (变更影响) are clearly identifiable.
  • Designs (traced) : clearly defined relationships to other requirements, solution components, or releases, phases, or iterations, within a solution scope, such that coverage and the effects of change (变更影响) are clearly identifiable.

Maintain Requirements

• Purpose

  Retain requirement accuracy and consistency throughout and beyond the change during the entire requirements life cycle, and to support reuse of requirements in other solutions.

  A requirement that represents an ongoing need must be maintained to ensure that it remains valid over time (随时间推移保持有效).

• Expected

  • Requirements (maintained) : defined once and available for long-term usage by the organization. They may become organizational process assets or be used in future initiatives. In some cases, a requirement that was not approved or implemented may be maintained for a possible future initiative.
  • Designs (maintained) : may be reusable once defined. For example, as a self- contained component that can be made available for possible future use.

Prioritize Requirements

• Purpose

  Rank requirements in the order of relative importance.

  Priority can refer to the relative value of a requirement, or to the sequence in which it will be implemented.

  Prioritization is an ongoing process, with priorities changing as the context changes.

  Inter-dependencies between requirements are identified and may be used as the basis for prioritization.

  Prioritization is a critical exercise that seeks to ensure the maximum value is achieved.

• Basis for Prioritization

  The basis on which requirements are prioritized is agreed upon by relevant stakeholders as defined in the Business Analysis Planning and Monitoring knowledge area.

• Challenges of Prioritization

  Prioritization is an assessment of relative value. Each stakeholder may value something different. Stakeholders may also have difficulty characterizing any requirement as a lower priority, and this may impact the ability to make necessary trade-offs.

• Continual Prioritization

  Priorities may shift as the context evolves and as more information becomes available.

• Excepted

  • Requirements (prioritized) : prioritized or ranked requirements are available for additional work, ensuring that the highest valued requirements are addressed first.
  • Designs (prioritized) : prioritized or ranked designs are available for additional work, ensuring that the highest valued designs are addressed first.

Assess Requirements Changes

• Purpose

  Evaluate the implications of proposed changes to requirements and designs.

  Performed as new needs or possible solutions are identified. Assessment must be performed to determine whether a proposed change will increase the value of the solution, and if so, what action should be taken.

  Business analysts assess the potential effect of the change to solution value, and whether proposed changes introduce conflicts with other requirements or increase the level of risk. Business analysts also ensure each proposed change can be traced back to a need. When assessing changes, business analysts consider if each proposed change:

  • aligns with the overall strategy (与整体战略保持一致),
  • affects value delivered (影响交付价值) to the business or stakeholder groups,
  • impacts the time to deliver (影响交付时间) or the resources required to deliver the value, and
  • alters any risks, opportunities, or constraints (风险、机会、限制) associated with the overall initiative.

• Impact Analysis

  Traceability is a useful tool for performing impact analysis. When a requirement changes, its relationships to other requirements or solution components can be reviewed. When considering changes or additions to existing requirements, business analysts assess the impact of the proposed change by considering:

  Benefit : the benefit that will be gained by accepting the change.

  Cost : the total cost to implement the change including the cost to make the change, the cost of associated rework, and the opportunity costs.

  Impact : the number of customers or business processes affected if the change is accepted.

  Schedule (进度) : the impact to the existing delivery commitments if the change is approved (变更获批对现有交付承诺的影响).

  Urgency (紧迫性) : the level of importance including the factors which drive necessity such as regulator or safety issues.

• Impact Resolution (影响解决)

  Depending on the planned approach, various stakeholders (including the business analyst) may be authorized to approve, deny, or defer the proposed change. All impacts and resolutions resulting from the change analysis are to be documented and communicated to all stakeholders.

• Excepted

  • Requirements Change Assessment : the recommendation to approve, modify, or deny a proposed change to requirements.
  • Designs Change Assessment : the recommendation to approve, modify, or deny a proposed change to one or more design components.

Approve Requirements

• Purpose

  Business analysts are responsible for ensuring clear communication of requirements, designs, and other business analysis information to the key stakeholders responsible for approving that information.

• Conflict and Issue Management

  Stakeholder groups frequently have varying points of view and conflicting priorities. A conflict may arise among stakeholders as a result of different interpretations of requirements or designs and conflicting values placed on them.

  The business analyst facilitates communication between stakeholders in areas of conflict so that each group has an improved appreciation for the needs of the others. Conflict resolution and issue management may occur quite often, as the business analyst is reviewing requirements and designs, and aiming to secure sign-off.

• Gain Consensus (达成共识)

  Approval may confirm that stakeholders believe that sufficient value will be created for the organization to justify investment in a solution. Business analysts obtain approval by reviewing the requirements or changes to requirements (审查需求和需求变更) with the accountable individuals or groups and requesting that they approve, indicating their agreement with the solution or designs described.

  Complete agreement may not be necessary for a successful change, but if there is a lack of agreement, the associated risks are to be identified and managed accordingly.

• Track and Communicate Approval (跟踪和传达审批)

  The business analyst records approval decisions, possibly in requirements maintenance and tracking tools. In order to communicate the status of requirements, it is necessary to keep accurate records of current approval status.

• Excepted

  • Requirements (approved) : requirements which are agreed to by stakeholders and are ready for use in subsequent business analysis efforts.
  • Designs (approved) : designs which are agreed to by stakeholders and are ready for use in subsequent business analysis or solution development efforts.

Strategy Analysis

• Strategy defines the most effective way to apply the capabilities of an enterprise in order to reach a desired set of goals and objectives. Strategies may exist for the entire enterprise, for a division, department or region, and for a product, project, or iteration.
• The Strategy Analysis knowledge area describes the business analysis work that must be performed to collaborate with stakeholders in order to identify a need of strategic or tactical importance (the business need ), enable the enterprise to address that need, and align the resulting strategy for the change with higher- and lower-level strategies.
• Strategy analysis focuses on defining the future and transition states needed to address the^ business need, and the work required is defined both by that need and the scope of the solution space.
• Strategy analysis provides context to requirements analysis and design definition for a given change. Strategy analysis should be performed as a business need is identified. This allows stakeholders to make the determination of whether to address that need or not. Strategy analysis is an ongoing activity that assesses any changes in that need, in its context, or any new information that may indicate that an adjustment to the change strategy may be required.

1
2

The following image illustrates the spectrum of value as business analysis activities progress from
delivering potential value to actual value.

(^) A strategy may be captured in a strategic plan, product vision, business case, product roadmap, or other artifacts. The Strategy Analysis knowledge area includes the following tasks:

• Analyze Current State : understands the business need and how it relates to the way the enterprise functions today. Sets a baseline and context for change.

• Define Future State : defines goals and objectives that will demonstrate that the business need has been satisfied and defines what parts of the enterprise need to change in order to meet those goals and objectives.

• Assess Risks : understands the uncertainties around the change, considers the effect those uncertainties may have on the ability to deliver value through a change, and recommends actions to address risks where appropriate.

• Define Change Strategy : performs a gap analysis between current and future state, assesses options for achieving the future state, and recommends the highest value approach for reaching the future state including any transition states that may be required along the way.

6.1 Analyze Current State (page 103)

6.1.1 Purpose

• Understand the reasons why an enterprise needs to change some aspect of how it operates and^ what would be directly or indirectly affected by the change.

6.1.2 Description

• The starting point for any change is an understanding of why the change is needed. Potential change is triggered by problems or opportunities that cannot be addressed without altering the current state. Without clearly understood business needs, it is impossible to develop a coherent strategy.
• Change always occurs in a context of existing stakeholders, processes, technology, and policies^ which constitute the current state of the enterprise. Business analysts examine the current state in the context of the business need to understand what may influence proposed changes, and what will be affected by them.
• The current state is explored in just enough detail to validate the need for a change and/or the change strategy. The current state of an enterprise is rarely static while a change is being developed and implemented.

6.1.3 Inputs

**- Elicitation Results

• Needs**

6.1.4 Elements

.1 Business Needs

Business needs are the problems and opportunities of strategic importance faced by the enterprise. An issue encountered in the organization, such as a customer complaint, a loss of revenue, or a new market opportunity, usually triggers the evaluation of a business need. A business need may be identified at many different levels of the enterprise:

• From the top-down : a strategic goal that needs to be achieved.
• From the bottom-up : a problem with the current state of a process, function or system.^
• From middle management : a manager needs additional information to make sound decisions or must perform additional functions to meet business objectives.
• From external drivers : customer demand or business competition in the marketplace.

The definition of business needs is frequently the most critical step in any business analysis effort. A solution must satisfy the business needs to be considered successful. The way the need is defined determines which alternative solutions will be considered, which stakeholders will be consulted, and which solution approaches will be evaluated.

Business needs are always expressed from the perspective of the enterprise, and not that of any particular stakeholder. Business needs are often identified or expressed along with a presumed solution. Business needs will drive the overall analysis of the current state.

A solution to a set of business needs must have the potential to generate benefits for the enterprise or its stakeholders, or avoid losses that would otherwise occur. Factors the business analyst may consider include:

• adverse impacts the problem is causing within the organization and quantify those impacts (for example, potential lost revenue, inefficiencies, dissatisfied customers, low employee morale),
• expected benefits from any potential solution (for example, increased revenue, reduced costs, increased market share),
• how quickly the problem could potentially be resolved or the opportunity could be taken, and the cost of doing nothing, and
• the underlying source of the problem.

.2 Organizational Structure and Culture

Organizational structure defines the formal relationships between people working in the enterprise. While communication channels and relationships are not limited to that structure, they are heavily influenced by it.

Organizational culture is the beliefs, values, and norms shared by the members of an organization. These beliefs drive the actions taken by an organization. Business analysts perform a cultural assessment to:

• identify if cultural changes are required to better achieve the goals,^
• identify whether stakeholders understand the rationale for the current state of the enterprise and the value delivered by it, and
• ascertain whether the stakeholders view the current state as satisfactory or if change is needed.

.3 Capabilities and Processes

Capabilities and processes describe the activities an enterprise performs. They also include the knowledge the enterprise has, the products and services it provides, the functions it supports, and the methods it uses to make decisions. Core capabilities or processes describe the essential functions of the enterprise that differentiate it from others. They are measured by performance indicators that can be used to assess the benefits of a change.

Business analysts may use:

• A capability-centric view of the enterprise when looking for innovative solutions that combine existing capabilities to produce a new outcome. A capability-based view is useful in this situation because capabilities are generally organized in a functional hierarchy with relationships to other capabilities, making it easier to identify any gaps.
• A process-centric view of the enterprise when looking for ways to improve the performance of^ current activities. A process-based view is useful in this situation because processes are organized in an end-to-end fashion across the enterprise to deliver value to its customers, making it easier to ensure that a change does in fact increase performance.

.4 Technology and Infrastructure

Information systems used by the enterprise support people in executing processes, making decisions, and in interactions with suppliers and customers.

The infrastructure describes the enterprise’s environment with respect to physical components and capabilities. The infrastructure can include components such as computer hardware, physical plants, and logistics, as well as their operation and upkeep.

.5 Policies

Policies define the scope of decision making at different levels of an enterprise. They generally address routine operations rather than strategic change. They ensure that decisions are made correctly, provide guidance to staff on permitted and appropriate behaviour and actions, support governance, and determine when and how new resources can be acquired.

.6 Business Architecture

Business analysts must understand how all of the elements of the current state fit together and support one another in order to recommend changes that will be effective. The existing business architecture typically meets an assortment of business and stakeholder needs.

.7 Internal Assets

Business analysts identify enterprise assets used in the current state. Resources can be tangible or intangible, such as financial resources, patents, reputation, and brand names.

.8 External Influences

There are external influences on the enterprise that do not participate in a change but might present constraints, dependencies, or drivers on the current state. Sources of external influence include:

• Industry Structure
• Competitors
• Customers^
• Suppliers
• Political and Regulatory Environment^
• Technology
• Macroeconomic Factors^

6.1.5 Guidelines and Tools

• Business Analysis Approach^
• Enterprise Limitation
• Organizational Approach
• Solution Limitation^
• Solution Performance Goals
• Solution Performance Measures^
• Stakeholder Analysis Results

6.1.6 Techniques

6.1.7 Stakeholders

• Customer - Domain Subject Matter Expert - End User - Implementation Subject Matter Expert - Operational Support - Project Manager - Regulator - Sponsor - Supplier - Tester

6.1.8 Outputs

• Current State Description : the context of the enterprise’s scope, capabilities, resources, performance, culture, dependencies, infrastructure, external influences, and significant relationships between these elements.
• Business Requirements : the problem, opportunity, or constraint which is defined based on an understanding of the current state. - Metrics and Key Performance Indicators (KPIs) - Mind Mapping - Observation - Organizational Modelling - Process Analysis - Process Modelling - Risk Analysis and Management - Root Cause Analysis - Scope Modelling - Survey or Questionnaire - SWOT Analysis - Vendor Assessment - Workshops
• Benchmarking and Market Analysis
• Business Capability Analysis
• Business Model Canvas
• Business Cases
• Concept Modelling
• Data Mining
• Document Analysis
• Financial Analysis
• Focus Group
• Functional Decomposition
• Interviews
• Item Tracking
• Lessons Learned

6.2 Define Future State (page 110)

6.2.1 Purpose

• Determine the set of necessary conditions to meet the business need.

6.2.2 Description

• Business analysts work to ensure that the future state of the enterprise is well defined, that it is achievable with the resources available, and that key stakeholders have a shared consensus vision of the outcome. The future state will be defined at a level of detail that:
  • allows for competing strategies to achieve the future state to be identified and assessed,
  • provides a clear definition of the outcomes that will satisfy the business needs,
  • details the scope of the solution space,
  • allows for value associated with the future state to be assessed, and
  • enables consensus to be achieved among key stakeholders.
• The future state description can include any context about the proposed future state. It describes the new, removed, and modified components of the enterprise. It can include simple changes to existing components of an organization to changes to the boundaries of the organization itself.
• Change may be needed to any component of the enterprise, including (but not limited to) business processes, functions, lines of business, organization structures, staff competencies, knowledge and skills, training, facilities, desktop tools, organization locations, data and information, application systems, and/or technology infrastructure.
• Descriptions may include visual models and text to clearly show the scope boundaries and details. Relevant relationships between entities are identified and described.

6.2.3 Inputs

- Business Requirements

6.2.4 Elements

.1 Business Goals and Objectives

Business goals and objectives describe the ends that the organization is seeking to achieve. Goals and objectives can relate to changes that the organization wants to accomplish, or current conditions that it wants to maintain.

Goals are longer term, ongoing, and qualitative statements of a state or condition that the organization is seeking to establish and maintain. Examples of business goals include:

• Create a new capability such as a new product or service, address a competitive disadvantage,

or create a new competitive advantage.

• Improve revenue by increasing sales or reducing cost.^

• Increase customer satisfaction.

• Increase employee satisfaction.^

• Comply with new regulations.

• Improve safety.^

• Reduce time to deliver a product or service

High-level goals can be decomposed to break down the general strategy into areas that may lead to desired results, such as increased customer satisfaction, operational excellence, and/or business growth.

As goals are analyzed they are converted into more descriptive, granular and specific objectives, and linked to measures that make it possible to objectively assess if the objective has been achieved. A common test for assessing objectives is to ensure that they are SMART (Specific, Measurable, Achievable, Relevant and Time-bound)

.2 Scope of Solution Space

The scope of the solution space defines which kinds of options will be considered when investigating possible solutions, including changes to the organizational structure or culture, capabilities and processes, technology and infrastructure, policies, products, or services, or even creating or changing relationships with organizations currently outside the scope of the extended enterprise.

If multiple future states can meet the business needs, goals and objectives, it will be necessary to determine which ones will be considered. This decision is typically based on the value to be delivered to stakeholders and requires an understanding of possible change strategies. The critical considerations for the decision are dependent on the overall objectives of the enterprise, but will involve an understanding of the quantitative and qualitative value of each option, the time needed to achieve each future state, and the opportunity cost to the enterprise.

.3 Constraints

Constraints describe aspects of the current state, aspects of the planned future state that may not be changed by the solution, or mandatory elements of the design. They must be carefully examined to ensure that they are accurate and justified. Constraints may reflect any of the following: budgetary restrictions, time restrictions, technology, infrastructure, policies, limits on the number of resources available, restrictions based on the skills of the team and stakeholders, a requirement that certain stakeholders not be affected by the implementation of the solution, compliance with regulations, and any other restriction.

.4 Organizational Structure and Culture

The formal and informal working relationships that exist within the enterprise may need to change to facilitate the desired future state. Changes to reporting lines can encourage teams to work more closely together and facilitate alignment of goals and objectives. Elements of the organizational structure and culture may need to change to support the future state. Describing the components of the future state provides insight into potential conflicts, impact, and limits.

.5 Capabilities and Processes

Identify new kinds of activities or changes in the way activities will be performed to realize the future state. New or changed capabilities and processes will be needed to deliver new products or services, to comply with new regulations, or to improve the performance of the enterprise.

.6 Technology and Infrastructure

The existing technology may impose technical constraints on the design of the solution. If current technology and infrastructure are insufficient to meet the business need, the business analyst identifies the changes necessary for the desired future state.

.7 Policies

Policies are a common source of constraints on a solution or on the solution space. Business policies may mandate what solutions can be implemented given certain levels of approval, the process for obtaining approval, and the necessary criteria a proposed solution must meet in order to receive funding.

.8 Business Architecture

The elements of any future state must effectively support one another and all contribute to meeting the business goals and objectives. In addition, they should be integrated into the overall desired future state of the enterprise as a whole, and support that future state.

.9 Internal Assets

The analysis of resources might indicate that existing resources need to be increased or require increased capabilities, or that new resources need to be developed. When analyzing resources, business analysts examine the resources needed to maintain the current state and implement the change strategy, and determine what resources can be used as part of a desired future state.

.10 Identify Assumptions

Most strategies are predicated on a set of assumptions that will determine whether or not the strategy can succeed, particularly when operating in a highly uncertain environment. These assumptions must be identified and clearly understood, so that appropriate decisions can be made if the assumption later proves invalid.

.11 Potential Value

When defining the future state, business analysts identify the potential value of the solution. The potential value of the future state is the net benefit of the solution after operating costs are accounted for. A change must result in greater value for the enterprise than would be achieved if no action was taken. However, it is possible that the future state will represent a decrease in value from the current state for some stakeholders or even for the enterprise as a whole. While determining the future state, business analysts consider increased or decreased potential value from:

• external opportunities revealed in assessing external influences,
• unknown strengths of new partners,
• new technologies or knowledge,
• potential loss of a competitor in the market, and^
• mandated adoption of a change component

In addition to the potential value of the future state, this analysis should consider the acceptable level of investment to reach the future state.

6.2.5 Guidelines and Tools

• Current State Description
• Metrics and Key Performance Indicators (KPIs)^
• Organizational Strategy^ 6.2.6 Techniques

6.2.7 Stakeholders

• Customer - Domain Subject Matter Expert - End User - Implementation Subject Matter Expert - Operational Support^ - Project Manager - Regulator - Sponsor - Supplier^ - Tester

6.2.8 Outputs

• Business Objectives : the desired direction that the business wishes to pursue in order to achieve the future state.
• Future State Description : the future state description includes boundaries of the proposed new, removed, and modified components of the enterprise and the potential value expected from the future state.
• Potential Value : the value that may be realized by implementing the proposed future state.
  • Lessons Learned
  • Metrics and Key Performance Indicators (KPIs)
  • Mind Mapping
  • Organizational Modelling
  • Process Modelling
  • Prototyping
  • Risk Analysis and Management
  • Scope Modelling
  • Survey or Questionnaire
  • SWOT Analysis
  • Vendor Assessment
  • Workshops
• Acceptance and Evaluation Criteria
• Balanced Scorecard
• Benchmarking and Market Analysis
• Brainstorming
• Business Capability Analysis
• Business Cases
• Business Model Canvas
• Decision Analysis
• Decision Modelling
• Financial Analysis
• Functional Decomposition
• Interviews

6.3 Assess Risk (page 120)

6.3.1 Purpose

• Understand the undesirable consequences of internal and external forces on the enterprise during a transition to, or once in, the future state. An understanding of the potential impact of those forces can be used to make a recommendation about a course of action.

6.3.2 Description

• Assessing risks includes analyzing and managing them. Risks might be related to the current state, a desired future state, a change itself, a change strategy, or any tasks being performed by the enterprise. The risks are analyzed for the:
  • possible consequences if the risk occurs,
  • impact of those consequences,
  • likelihood of the risk, and
  • potential time frame when the risk might occur.
• A risk assessment can include choosing to accept a risk if either the effort required to modify the risk or the level of risk outweighs the probable loss. If the risks are understood and the change proceeds, then the risks can be managed to minimize their overall impact to value.

6.3.3 Inputs

**- Business Objectives

• Elicitation Results (confirmed)
• Influences (internal and external)
• Potential Value
• Requirements (prioritized)**

6.3.4 Elements

.1 Unknowns

When assessing a risk, there will be uncertainty in the likelihood of it occurring, and the impact if it does occur. Business analysts collaborate with stakeholders to assess risks based on current understanding.

.2 Constraints, Assumptions, and Dependencies

Constraints, assumptions, and dependencies can be analyzed for risks and sometimes should be managed as risks themselves. If the constraint, assumption, or dependency is related to an aspect of a change, it can be restated as a risk by identifying the event or condition and consequences that could occur because of the constraint, assumption, or dependency.

.3 Negative Impact to Value

Risks are expressed as conditions that increase the likelihood or severity of a negative impact to value. Business analysts clearly identify and express each risk and estimate its likelihood and impact to determine the level of risk. Business analysts estimate a total risk level from the

aggregated set of risks, indicating the overall potential impact for the risks being assessed. In some cases overall risk level can be quantified in financial terms, or in an amount of time, effort, or other measures.

.4 Risk Tolerance

How much uncertainty a stakeholder or an enterprise is willing to take on in exchange for potential value is referred to as risk tolerance. In general, there are three broad ways of describing attitude toward risk:

• Risk-aversion : An unwillingness to accept much uncertainty^
• Neutrality : Some level of risk is acceptable^ - Risk-seeking: Willingness to accept or even take on more risk in return for a higher potential value

If there is low tolerance for risk, there may be more effort on avoidance, transfer or mitigation strategies. If the tolerance for risk is high, more risks are likely to be accepted.

.5 Recommendation

Based on the analysis of risks, business analysts recommend a course of action. Business analysts work with stakeholders to understand the overall risk level and their tolerance for risk. The recommendation usually falls into one of the following categories:

• pursue the benefits of a change regardless of the risk,^
• pursue the benefits of a change while investing in reducing risk (likelihood and/or impact),
• seek out ways to increase the benefits of a change to outweigh the risk,^
• identify ways to manage and optimize opportunities, and^
• do not pursue the benefits of a change.^

6.3.5 Guidelines and Tools

**- Business Analysis Approach

• Business Policies
• Change Strategy**^
• Current State Description
• Future State Description
• Identified Risks
• Stakeholder Engagement Approach

6.3.6 Techniques

• Lessons Learned
• Mind Mapping
• Risk Analysis and Management
• Root Cause Analysis
• Survey or Questionnaire
• Workshops
• Brainstorming
• Business Cases
• Decision Analysis
• Document Analysis
• Financial Analysis
• Interviews

6.3.7 Stakeholders

- Domain Subject Matter Expert - Implementation Subject Matter Expert - Operational Support - Project Manager - Regulator - Sponsor - Supplier - Tester

6.3.8 Outputs

• Risk Analysis Results: an understanding of the risks associated with achieving the future state, and the mitigation strategies which will be used to prevent those risks, reduce the impact of the risk, or reduce the likelihood of the risk occurring.

6.4 Define Change Strategy (page 124)

6.4.1 Purpose

• Develop and assess alternative approaches to the change, and then select the recommended approach.

6.4.2 Description

• Developing a change strategy is simpler when the current state and the future state are already defined because they provide some context for the change. The change strategy clearly describes the nature of the change in terms of:
  • context of the change,
  • identified alternative change strategies,
  • justification for why a particular change strategy is the best approach,
  • investment and resources required to work toward the future state,
  • how the enterprise will realize value after the solution is delivered,
  • key stakeholders in the change, and
  • transition states along the way.
• The appropriate representation of a change strategy depends on the perspective of the change team and their stakeholders. The change strategy might be presented as part of a business case, Statement of Work (SOW), an enterprise’s strategic plan, or in other formats.

6.4.3 Inputs

**- Current State Description

• Future State Description**^ **- Risk Analysis Results
• Stakeholder Engagement Approach**

6.4.4 Elements

.1 Solution Scope

The solution is the outcome of a change that allows an enterprise to satisfy a need. Multiple solution options might be evaluated and, as part of a change strategy, the best solution approach is justified and selected. The solution scope defines the boundaries of the solution, and is described in enough detail to enable stakeholders to understand which new capabilities the change will deliver. The solution scope might be described in different ways, including the use of:

The solution scope can also include descriptions of out-of-scope solution components to provide clarity.

.2 Gap Analysis

A gap analysis identifies the difference between current state and future state capabilities. To perform gap analysis, both current state and future state should be defined. Gap analysis can help identify the gaps that prevent the enterprise from meeting needs and achieving goals. It can be used to determine if the enterprise can meet its needs using its existing structure, resources, capabilities, and technology. The gaps will need to be addressed in the transition and future states.

.3 Enterprise Readiness Assessment

Business analysts analyze the enterprise to assess its capacity to make the change and to sustain the change in the future state. The readiness assessment considers the enterprise’s capacity not only to make the change, but to use and sustain the solution, and realize value from the solution.

.4 Change Strategy

A change strategy is a high-level plan of key activities and events that will be used to transform the enterprise from the current state to the future state. Change strategies may be a singular initiative composed of smaller changes which might be structured as a set or sequence of projects, or as various continuous improvement efforts.

During the course of the development of a change strategy, several options are identified, explored, and described in enough detail to determine which options are feasible. Alternatives can be identified through brainstorming and consulting subject matter experts (SMEs). Sources of

ideas can include historical ideas, historical changes, other markets’ strategies, and competitors’ approaches. The preferred change strategy should be selected considering:

• organizational readiness to make the change,
• major costs and investments needed to make the change,^
• timelines to make the change,^
• alignment to the business objectives,^
• timelines for value realization, and^
• opportunity costs of the change strategy.

Business analysts may develop a business case for each potential change strategy to support decision making. The opportunity cost of each change strategy also needs to be considered. While every change facilitated by business analysts is intended to increase value, some changes decrease value in parts of an enterprise while increasing it in others.

.5 Transition States and Release Planning

In many cases, the future state will need to be achieved over time rather than through a single change, meaning that the enterprise will have to operate in one or more transition states. Release planning is concerned with determining which requirements to include in each release, phase, or iteration of the change.

There are many factors that guide these decisions, such as the overall budget, deadlines or time constraints, resource constraints, training schedules, and the ability of the business to absorb changes within a defined time frame.

6.4.5 Guidelines and Tools

**- Business Analysis Approach

• Design Option**
• Solution Recommendations

6.4.6 Techniques

6.4.7 Stakeholders

- Customer - Functional Decomposition - Interviews - Lessons Learned - Mind Mapping^ - Organizational Modelling^ - Process Modelling^ - Scope Modelling - SWOT Analysis^ - Vendor Assessment - Workshops^

• Balanced Scorecard
• Benchmarking and Market Analysis^
• Brainstorming
• Business Capability Analysis^
• Business Cases
• Business Model Canvas^
• Decision Analysis
• Estimation
• Financial Analysis
• Focus Group^

- Domain Subject Matter Expert - End User - Implementation Subject Matter Expert - Operational Support - Project Manager - Regulator - Sponsor - Supplier - Tester

6.4.8 Outputs

• Change Strategy : the approach that the organization will follow to guide change.
• Solution Scope : the solution scope that will be achieved through execution of the change strategy.

Requirements Analysis and Design Definition

• The Requirements Analysis and Design Definition knowledge area describes the tasks that business analysts perform to structure and organize requirements discovered during elicitation activities, specify and model requirements and designs , validate and verify information , identify solution options that meet business needs, and estimate the potential value that could be realized for each solution option.
• This knowledge area covers the incremental and iterative activities ranging from the initial concept and exploration of the need through the transformation of those needs into a particular recommended solution.
• One person’s designs may be another person’s requirements, and it may be either high-level or very detailed based upon what is appropriate to those consuming the information.
• Business analysts analyze the potential value of both requirements and designs. In collaboration with implementation subject matter experts, business analysts define solution options that can be evaluated in order to recommend the best solution option that meets the need and brings the most value. The following image illustrates the spectrum of value as business analysis activities progress from delivering potential value to actual value.

The Requirements Analysis and Design Definition knowledge area includes the following tasks:

• Specify and Model Requirements : describes a set of requirements or designs in detail using analytical techniques.
• Verify Requirements : ensures that a set of requirements or designs has been developed in enough detail to be usable by a particular stakeholder, is internally consistent, and is of high quality.
• Validate Requirements : ensures that a set of requirements or designs delivers business value and supports the organization’s goals and objectives.
• Define Requirements Architecture : structures all requirements and designs so that they support the overall business purpose for a change and that they work effectively as a cohesive whole.
• Define Solution Options : identifies, explores and describes different possible ways of meeting the need.
• Analyze Potential Value and Recommend Solution : assesses the business value associated with a potential solution and compares different options, including trade-offs, to identify and recommend the solution option that delivers the greatest overall value.

Specify and Model Requirements

Purpose

Analyze, synthesize (综合), and refine (提炼) elicitation results (启发结果) into requirements and designs.

Specify and Model Requirements describes the practices for analyzing elicitation results and creating representations of those results. When the focus of the specifying and modelling activity is on understanding the need, the outputs are referred to as requirements. When the focus of the specifying and modelling activity is on a solution, the outputs are referred to as designs.

In many IT environments, the word ‘design’ is used specifically for technical designs created by software developers, data architects, and other implementation subject matter experts. All business deliverables are referred to as ‘requirements’.

Model Requirements

A model is a descriptive and visual way to convey information to a specific audience (受众) in order to support analysis, communication, and understanding; and sometimes used to confirm knowledge, identify information gaps that the business analyst may have, and identify duplicate information. Business analysts choose from one or more of the following modelling formats:

• Matrices : a matrix is used when the business analyst is modelling a requirement or set of requirements that have a complex but uniform structure, which can be broken down into elements that apply to every entry in the table. Matrices may be used for data dictionaries, requirements traceability, or for gap analysis. Matrices are also used for prioritizing requirements and recording other requirements attributes and metadata.
• Diagrams : a diagram is a visual, often pictorial, representation of a requirement or set of requirements. A diagram is especially useful to depict complexity in a way that would be difficult to do with words. Diagrams can also be used to define boundaries for business domains, to categorize and create hierarchies of items, and to show components of objects such as data and their relationships.

Model categories can include:

• People and Roles : models represent organizations, groups of people, roles, and their relationships within an enterprise and to a solution. Techniques include Organizational Modelling, Roles and Permissions Matrix and Stakeholder List, Map, or Personas.
• Rationale (基本原理): models represent the ‘why’ of a change. Techniques include Decision Modelling, Scope Modelling, Business Model Canvas, Root Cause Analysis, and Business Rules Analysis.
• Activity Flow : models represent a sequence of actions, events, or a course that may be taken. Techniques include Process Modelling, Use Cases and Scenarios, and User Stories.
• Capability : models focus on features or functions of an enterprise or a solution. Techniques include Business Capability Analysis, Functional Decomposition, and Prototyping.
• Data and Information : models represent the characteristics and the exchange of information within an enterprise or a solution. Techniques include Data Dictionary, Data Flow Diagrams, Data Modelling, Glossary, State Modelling, and Interface Analysis.

Analyze Requirements

Business analysis information is decomposed into components to further examine for:

• anything that must change to meet the business need,

• anything that should stay the same to meet the business need,

• missing components,

• unnecessary components, and

• any constraints or assumptions that impact the components.

.3 Represent Requirements and Attributes

Requirements should be explicitly represented and should include enough detail such that they exhibit the characteristics of requirements and designs quality. Various attributes can be specified for each requirement or set of requirements. These attributes are selected when planning for information management.

.4 Implement the Appropriate Levels of Abstraction

The level of abstraction of a requirement varies based on the type of requirement and audience for the requirement. Not all stakeholders require or find value in the complete set of requirements and models. It may be appropriate to produce different viewpoints of requirements to represent the same need for different stakeholders.

7.1.5 Guidelines and Tools

**- Modelling Notations/Standards

• Modelling Tools**^ **- Requirements Architecture
• Requirements Life Cycle Management Tools**^
• Solution Scope

7.1.6 Techniques

7.1.7 Stakeholders

- Any Stakeholders

7.1.8 Outputs

• Requirements (specified and modelled) : any combination of requirements and/or designs in the form of text, matrices, and diagrams. - Non-Functional Requirements Analysis^ - Organizational Modelling - Process Modelling^ - Prototyping - Roles and Permissions Matrix^ - Root Cause Analysis - Scope Modelling^ - Sequence Diagrams - Stakeholder List, Map, or Personas^ - State Modelling - Use Cases and Scenarios - User Stories
• Acceptance and Evaluation Criteria^
• Business Capability Analysis
• Business Model Canvas^
• Business Rules Analysis
• Concept Modelling^
• Data Dictionary
• Data Flow Diagrams^
• Data Modelling
• Decision Modelling^
• Functional Decomposition
• Glossary
• Interface Analysis

Verify Requirements

7.2.1 Purpose

• Ensure that requirements and designs specifications and models meet quality standards and are^ usable for the purpose they serve.

7.2.2 Description

• Verifying requirements ensures that the requirements and designs have been defined correctly. Requirements verification determines that the requirements and designs are ready for validation, and provides the information needed for further work to be performed.
• A high-quality specification is well written and easily understood by its intended audience. The most important characteristic of quality requirements and designs is fitness for use. They must meet the needs of stakeholders who will use them for a particular purpose. Quality is ultimately determined by stakeholders.

7.2.3 Inputs

- Requirements (specified and modelled)^

7.2.4 Elements

.1 Characteristics of Requirements and Designs Quality

A While quality is ultimately determined by the needs of the stakeholders who will use the requirements or the designs, acceptable quality requirements exhibit many of the following characteristics:

• Atomic : self-contained and capable of being understood independently
• Complete : enough to guide further work and at the appropriate level of detail
• Consistent : aligned with the identified needs of the stakeholders and not conflicting with other requirements.
• Concise : contains no extraneous and unnecessary content.
• Feasible : reasonable and possible within the agreed-upon risk, schedule, and budget.
• Unambiguous : the requirement must be clearly stated to clarify whether a solution does or does not meet the associated need.
• Testable : able to verify that the requirement or design has been fulfilled.
• Prioritized : ranked, grouped, or negotiated in terms of importance and value.
• Understandable : represented using common terminology of the audience

.2 Verification Activities

Verification activities are typically performed iteratively throughout the requirements analysis process. Verification activities include:

• checking for compliance with organizational performance standards for business analysis,

• checking for correct use of modelling notation, templates, or forms,

• checking for completeness within each model,

• comparing each model against other relevant models, checking for elements that are mentioned in one model but are missing in other models, and verifying that the elements are referenced consistently,

• ensuring the terminology used in expressing the requirement is understandable to stakeholders and consistent with the use of those terms within the organization, and

• adding examples where appropriate for clarification.

.3 Checklists

Checklists are used for quality control when verifying requirements and designs. Checklists may include a standard set of quality elements that business analysts use to verify the requirements, or they may be specifically developed to capture issues of concern. The purpose of a checklist is to ensure that items determined to be important are included in the final requirements deliverables, or that steps required for the verification process are followed.

7.2.5 Guidelines and Tools

- Requirements Life Cycle Management Tools

7.2.6 Techniques

7.2.7 Stakeholders

- All Stakeholders

7.2.8 Outputs

• Requirements (verified) : a set of requirements or designs that is of sufficient quality to be used as a basis for further work.

Validate Requirements

7.3.1 Purpose

• Ensure that all requirements and designs align to the business requirements and support the delivery of needed value.

7.3.2 Description

• Requirements validation is an ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements and that the designs satisfy the requirements.
• Understanding what the desired future state looks like for stakeholders after their needs have been met is valuable to business analysts when validating requirements. The overall goal of implementing the requirements is to achieve the stakeholders’ desired future state. In many cases, stakeholders have different, conflicting needs and expectations that may be exposed through the validation process. - Metrics and Key Performance Indicators (KPIs) - Reviews
• Acceptance and Evaluation Criteria
• Item Tracking

7.3.3 Inputs

- Requirements (specified and modelled)

7.3.4 Elements

.1 Identify Assumptions

If an organization is launching an unprecedented product or service, it may be necessary to make assumptions about customer or stakeholder response, as there are no similar previous experiences on which to rely. In other cases, it may be difficult or impossible to prove that a particular problem derives from an identified root cause. Stakeholders may have assumed that certain benefits will result from the implementation of a requirement. These assumptions are identified and defined so that associated risks can be managed.

.2 Define Measurable Evaluation Criteria

While the expected benefits are defined as part of the future state, the specific measurement criteria and evaluation process may not have been included. Business analysts define the evaluation criteria that will be used to evaluate how successful the change has been after the solution is implemented. Baseline metrics or target metrics might be established based on the current state.

.3 Evaluate Alignment with Solution Scope

A requirement can be of benefit to a stakeholder and still not be a desirable part of a solution. When requirements do not align, either the future state must be re-evaluated and the solution scope changed, or the requirement removed from the solution scope.

If a design cannot be validated to support a requirement, there might be a missing or misunderstood requirement, or the design must change.

7.3.5 Guidelines and Tools

**- Business Objectives

• Future State Description
• Potential Value
• Solution Scope**

7.3.6 Techniques

• Acceptance and Evaluation Criteria^ • Metrics and Key Performance Indicators (KPIs)
• Document^ Analysis • Reviews
• Financial^ Analysis • Risk Analysis and^ Management
• Item^ Tracking^

7.3.7 Stakeholders

- All Stakeholders

7.3.8 Outputs

• Requirements (validated) : validated requirements and designs are those that can be demonstrated to deliver benefit to stakeholders and align with the business goals and objectives of the change. If a requirement or design cannot be validated, it either does not benefit the organization, does not fall within the solution scope, or both.

Define Requirements Architecture

7.4.1 Purpose

• Ensure that the requirements collectively support one another to fully achieve the objectives.

7.4.2 Description

• Requirements architecture is the structure of all of the requirements of a change. A requirements architecture fits the individual models and specifications together to ensure that all of the requirements form a single whole that supports the overall business objectives and produces a useful outcome for stakeholders. Business analysts use a requirements architecture to:
  • understand which models are appropriate for the domain, solution scope, and audience,
  • organize requirements into structures relevant to different stakeholders,
  • illustrate how requirements and models interact with and relate to each other, and show how the parts fit together into a meaningful whole,
  • ensure the requirements work together to achieve the overall objectives, and
  • make trade-off decisions about requirements while considering the overall objectives.
• Requirements architecture is not intended to demonstrate traceability, but rather to show how elements work in harmony with one another to support the business requirements, and to structure them in various ways to align the viewpoints of different stakeholders. Traceability is often used as the mechanism to represent and manage these relationships. Traceability proves that every requirement links back to an objective and shows how an objective was met. Traceability does not prove the solution is a cohesive whole that will work.

7.4.3 Inputs

**- Information Management Approach

• Requirements (any state)
• Solution Scope**

7.4.4 Elements

.1 Requirements Viewpoints and Views

A viewpoint is a set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related. Viewpoints provide templates for addressing the concerns of particular stakeholder groups. Requirements viewpoints frequently include standards and guidelines for the:

• model types used for requirements,

• attributes that are included and consistently used in different models,

• model notations that are used, and^

• analytical approaches used to identify and maintain relevant relationships among models.^

No single viewpoint alone can form an entire architecture. Trying to put too much information into any one viewpoint will make it too complex and degrade its purpose. Examples of viewpoints include - Business process models, Data models and information, User interactions including use cases and/or user experience, Audit and security, and Business models.

The actual requirements and designs for a particular solution from a chosen viewpoint are referred to as a view. A collection of views makes up the requirements architecture for a specific solution. Business analysts align, coordinate, and structure requirements into meaningful views; and this set of coordinated, complementary views provides a basis for assessing the completeness and coherence of the requirements.

In short, the viewpoints tell business analysts what information they should provide for each stakeholder group to address their concerns, while views describe the actual requirements and designs that are produced.

.2 Template Architectures

An architectural framework is a collection of viewpoints that is standard across an industry, sector, or organization. Business analysts can treat frameworks as predefined templates to start from in defining their architecture. Similarly, the framework can be populated with domain-specific information to form a collection of views.

.3 Completeness

An architecture helps ensure that a set of requirements is complete. The entire set of requirements should be able to be understood by the audience in way that it can be determined that the set is cohesive and tells a full story. Structuring requirements according to different viewpoints helps ensure this completeness. Iterations of elicitation, specification, and analysis activities can help identify gaps.

.4 Relate and Verify Requirements Relationships

Requirements may be related to each other in several ways when defining the requirements architecture. Business analysts examine and analyze the requirements to define the relationships between them. Business analysts examine each relationship to ensure that the relationships satisfy the following quality criteria:

• Defined : there is a relationship and the type of the relationship is described.
• Necessary : the relationship is necessary for understanding the requirements holistically.^
• Correct : the elements do have the relationship described.^
• Unambiguous : there are no relationships that link elements in two different and conflicting ways.^
• Consistent : relationships are described in the same way, using the same set of standard^ descriptions as defined in the viewpoints.

.5 Business Analysis Information Architecture

The information architecture is a component of the requirements architecture because it describes how all of the business analysis information for a change relates. It defines relationships for types

of information such as requirements, designs, types of models, and elicitation results. Understanding this type of information structure helps to ensure that the full set of requirements is complete by verifying the relationships are complete.

7.4.5 Guidelines and Tools

**- Architecture Management Software

• Legal/ Regulatory Information
• Methodologies and Frameworks**

7.4.6 Techniques

7.4.7 Stakeholders

• Domain Subject Matter Expert
• Implementation Subject Matter Expert
• Project Manager
• Sponsor
• Tester - Any Stakeholders

7.4.8 Outputs

• Requirements Architecture : the requirements and the interrelationships among them, as well as any contextual information that is recorded.

Define Design Options

7.5.1 Purpose

• Define the solution approach, identify opportunities to improve the business, allocate^ requirements across solution components, and represent design options that achieve the desired future state.

7.5.2 Description

• When designing a solution, there may be one or more design options identified. Each design option represents a way to satisfy a set of requirements. Design options exist at a lower level than the change strategy, and are tactical rather than strategic. As a solution is developed, tactical trade-offs may need to be made among design alternatives.
• Business analysts must assess the effect these trade-offs will have on the delivery of value to^ stakeholders. As initiatives progress and requirements evolve, design options evolve as well. - Organizational Modelling - Scope Modelling^ - Workshops^
• Data Modelling
• Functional Decomposition^
• Interviews^

7.5.3 Inputs

**- Change Strategy

• Requirements (validated, prioritized)
• Requirements Architecture**

7.5.4 Elements

.1 Define Solution Approaches

The solution approach describes whether solution components will be created or purchased, or some combination of both. Business analysts assess the merits of the solution approaches for each design option. Solution approaches include:

• Create : solution components are assembled, constructed, or developed by experts as a direct response to a set of requirements.
• Purchase : solution components are selected from a set of offerings that fulfill the requirements.
• Combination of both : Design options may include a combination of both creation and purchase of components.

The requirements and the design options have enough detail to make a decision about which solution to construct or purchase.

.2 Identify Improvement Opportunities

When proposing design options, a number of opportunities to improve the operation of the business may occur and are compared. Some common examples of opportunities include:

• Increase Efficiencies : automate or simplify the work people perform by re- engineering or sharing processes, changing responsibilities, or outsourcing.
• Improve Access to Information : provide greater amounts of information to staff who interface directly or indirectly with customers, thereby reducing the need for specialists.
• Identify Additional Capabilities : highlight capabilities that have the potential to provide future value and can be supported by the solution.

.3 Requirements Allocation

Requirements allocation is the process of assigning requirements to solution components and releases to best achieve the objectives. Allocation is supported by assessing the trade-offs between alternatives in order to maximize benefits and minimize costs. The objective of allocation is to maximize that value.

Requirements may be allocated between organizational units, job functions, solution components, or releases of a solution. Requirements allocation typically begins when a solution approach has been determined, and continues until all valid requirements are allocated and the solution is implemented.

.4 Describe Design Options

Design options are investigated and developed while considering the desired future state, and in order to ensure the design option is valid. Solution performance measures are defined for each

design option. A design option usually consists of many design components, each described by a design element. Design elements may describe:

• business policies and business rules,
• business processes to be performed and managed,
• people who operate and maintain the solution, including their job functions and responsibilities,
• operational business decisions to be made,
• software applications and application components used in the solution, and
• organizational structures, including interactions between the organization, its customers, and its suppliers.

7.5.5 Guidelines and Tools

**- Existing Solutions

• Future State Description**^ - Requirements (traced)^ - Solution Scope

7.5.6 Techniques

7.5.7 Stakeholders

• Domain Subject Matter Expert^
• Implementation Subject Matter Expert^
• Operational Support^
• Project Manager^ - Supplier

7.5.8 Outputs

• Design Options : describe various ways to satisfy one or more needs in a context. They may include solution approach, potential improvement opportunities provided by the option, and the components that define the option.

Analyze Potential Value and Recommend Solution

7.6.1 Purpose

• Estimate the potential value for each design option and to establish which one is most appropriate to meet the enterprise’s requirements. - Mind Mapping - Root Cause Analysis - Survey or Questionnaire - Vendor Assessment - Workshops
• Benchmarking and Market Analysis
• Brainstorming
• Document Analysis
• Interviews
• Lessons Learned

7.6.2 Description

• Describes how to estimate and model the potential value delivered by a set of requirements, designs, or design options. Potential value is analyzed many times over the course of a change. This analysis may be a planned event, or it may be triggered by a modification to the context or scope of the change.
• The analysis of potential value includes consideration that there is uncertainty in the estimates. Value can be described in terms of finance, reputation, or even impact on the marketplace. Any change may include a mix of increases and decreases in value.
• Design options are evaluated by comparing the potential value of each option to the other options. Depending on the reasons for the change, there may be no best option to recommend, or there may be a clear best choice.

7.6.3 Inputs

- Potential Value^ - Design Options

7.6.4 Elements

.1 Expected Benefits

Expected benefits describe the positive value that a solution is intended to deliver to stakeholders. Value can include benefits, reduced risk, compliance with business policies and regulations, an improved user experience, or any other positive outcome. The total expected benefit is the net benefit of all the requirements a particular design option addresses. Benefits are often realized over a period of time.

.2 Expected Costs

Expected costs include any potential negative value associated with a solution, including the cost to acquire the solution, any negative effects it may have on stakeholders, and the cost to maintain it over time. Expected costs can include - timeline, maintenance costs, effort, physical resources, operating costs, information resources, purchase and/or implementation costs, and human resources.

Expected costs for a design option consider the cumulative costs of the design components. Business analysts also consider opportunity cost when estimating the expected cost of a change.

.3 Determine Value

Potential value is uncertain value. The potential value of a solution to a stakeholder is based on the benefits delivered by that solution and the associated costs. Value can be positive (if the benefits exceed the costs) or negative (if the costs exceed the benefits).

Business analysts consider potential value from the points of view of stakeholders. Value to the enterprise is almost always more heavily weighted than value for any individual stakeholder groups. Many changes are proposed in terms of intangible or uncertain benefits, while costs are described as tangible, absolute, and might grow.

.4 Assess Design Options and Recommend Solution

Each design option is assessed based on the potential value it is expected to deliver. At any point in analyzing the design options, it may become necessary to re-evaluate the initial allocation of design elements between components. The reasons for re-evaluation include better understanding of the cost to implement each component and to determine which allocations have the best cost-to- benefit ratio. There are several factors to take into consideration:

• Available Resources : there may be limitations regarding the amount of requirements that can be implemented based on the allocated resources. In some instances, a business case can be developed to justify additional investment.
• Constraints on the Solution : regulatory requirements or business decisions may require that certain requirements be handled manually or automatically, or that certain requirements be prioritized above all others.
• Dependencies between Requirements : some capabilities may in and of themselves provide limited value to the organization, but need to be delivered in order to support other high-value requirements

Other considerations may include relationships with proposed vendors, dependencies on other initiatives, corporate culture, and sufficient cash flow for investment. Business analysts recommend the option or options deemed to be the most valuable solution to address the need. It is possible that none of the design options are worthwhile and the best recommendation is to do nothing.

7.6.5 Guidelines and Tools

**- Business Objectives

• Current State Description**^ **- Future State Description
• Risk Analysis Results
• Solution Scope**^

7.6.6 Techniques

7.6.7 Stakeholders

• Customer

• Domain Subject Matter Expert

• End User

• Implementation Subject Matter Expert

  • Focus Groups^
  • Interviews
  • Metrics and Key Performance Indicators (KPIs)
  • Risk Analysis and Management
  • Survey or Questionnaire^
  • SWOT Analysis^
  • Workshops^

• Acceptance and Evaluation Criteria

• Backlog Management

• Brainstorming

• Business Cases

• Business Model Canvas^

• Decision Analysis^

• Estimation^

• Financial Analysis

• Project Manager - Regulator - Sponsor

7.6.8 Outputs

• Solution Recommendation : identifies the suggested, most appropriate solution based on an evaluation of all defined design options. The recommended solution should maximize the value

provided to the enterprise.

Solution Evaluation

• The Solution Evaluation knowledge area describes the tasks that business analysts perform to assess the performance of and value delivered by a solution in use by the enterprise, and to

recommend removal of barriers or constraints that prevent the full realization of the value.

• An important distinction between the Solution Evaluation knowledge area and other knowledge areas is the existence of an actual solution, which may only be a partial solution, but the solution

or solution component has already been implemented and is operating in some form.

• Solution Evaluation tasks can be performed on solution components in varying stages of

development:

• Prototypes or Proofs of Concept : working but limited versions of a solution that demonstrate value.
• Pilot or Beta releases : limited implementations or versions of a solution used in order to work through problems and understand how well it actually delivers value before fully releasing the solution.
• Operational releases : full versions of a partial or completed solution used to achieve business objectives, execute a process, or fulfill a desired outcome.
• Solution Evaluation describes tasks that analyze the actual value being delivered, identifies limitations which may be preventing value from being realized, and makes recommendations to increase the value of the solution. Solution Evaluation generally focuses on a component of an

enterprise rather than the entire enterprise. The following image illustrates the spectrum of value

1

as business analysis activities progress from delivering potential value to actual value.

The Solution Evaluation knowledge area includes the following tasks:

• Measure Solution Performance : determines the most appropriate way to assess the performance of a solution, its alignment with enterprise goals and objectives.
• Analyze Performance Measures : examines the performance information of a solution in order to understand the value it delivers, and determines whether it is meeting current business needs.
• Assess Solution Limitations : investigates issues within the scope of a solution that may prevent it from meeting current business needs.
• Assess Enterprise Limitations : investigates issues outside the scope of a solution that may be preventing the enterprise from realizing the full value that a solution is capable of providing.
• Recommend Actions to Increase Solution Value : identifies and defines actions the enterprise can take to increase the value that can be delivered by a solution.

8.1 Measure Solution Performance (page 166)

8.1.1 Purpose

• Define performance measures and use the data collected to evaluate the effectiveness of a

solution in relation to the value it brings.

8.1.2 Description

• Performance measures determine the value of a newly deployed or existing solution. The

measures used depend on the solution itself, the context, and how the organization defines

1
2
3
4
5

value. When solutions do not have built-in performance measures, the business analyst works
with stakeholders to determine and collect the measures that will best reflect the performance of
a solution. Performance may be assessed through key performance indicators (KPIs) aligned
with enterprise measures, goals and objectives for a project, process performance targets, or
tests for a software application.

8.1.3 Inputs

**- Business Objectives

• Implemented Solution (external)**

8.1.4 Elements

.1 Define Solution Performance Measures

Business analysts ensure that any existing performance measures are accurate, relevant and elicit any additional performance measures identified by stakeholders. Business goals, objectives, and business processes are common sources of measures. Performance measures may be influenced or imposed by third parties such as solution vendors, government bodies, or other regulatory organizations.

Solution performance measures may be quantitative, qualitative, or both, depending on the value being measured.

• Quantitative Measures : are numerical, countable, or finite, usually involving amounts, quantities, or rates.
• Qualitative Measures : are subjective and can include attitudes, perceptions, and any other^ subjective response. Customers, users, and others involved in the operation of a solution have perceptions of how well the solution is meeting the need.

.2 Validate Performance Measures

Validating performance measures helps to ensure that the assessment of solution performance is useful. Business analysts validate the performance measures and any influencing criteria with stakeholders. Specific performance measures should align with any higher-level measures that exist within the context affecting the solution. 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.

.3 Collect Performance Measures

When defining performance measures, business analysts may employ basic statistical sampling concepts. When collecting performance measures, business analysts consider:

• Volume or Sample Size : Smaller sample size might skew the results and lead to inaccurate conclusions. Larger sample sizes may be more desirable, but may not be practical to obtain.
• Frequency and Timing : the frequency and timing with which measurements are taken may^ have an effect on the outcome.
• Currency : measurements taken more recently tend to be more representative than older data.^

Using qualitative measures, business analysts can facilitate discussions to estimate the value realized by a solution.

8.1.5 Guidelines and Tools

**- Change Strategy

• Future State Description
• Requirements (validated)
• Solution Scope**

8.1.6 Techniques

8.1.7 Stakeholders

• Customer
• Domain Subject Matter Expert
• End User
• Project Manager^ - Regulator - Sponsor

8.1.8 Outputs

• Solution Performance Measures : measures that provide information on how well the solution is performing or potentially could perform.

8.2 Analyze Performance Measures (page 170)

8.2.1 Purpose

• Provide insights into the performance of a solution in relation to the value it brings.^

8.2.2 Description

• Performance measures themselves rarely trigger a decision about the value of a solution. In order to meaningfully analyze performance measures, business analysts require a thorough understanding of the potential value that stakeholders hope to achieve with the solution. To assist in the analysis, variables such as the goals and objectives of the enterprise, key performance indicators (KPIs), the level of risk of the solution, the risk tolerance of both stakeholders and the enterprise, and other stated targets are considered.

8.2.3 Inputs

- Potential Value (6.2)^ - Acceptance and Evaluation Criteria - Benchmarking and Market Analysis^ - Business Cases - Data Mining^ - Decision Analysis - Focus Groups^ - Metrics and Key Performance Indicators (KPIs) - Non-Functional Requirements Analysis - Observation^ - Prototyping - Survey or Questionnaire^ - Use Cases and Scenarios - Vendor Assessment^

- Solution Performance Measures (8.1)^

8.2.4 Elements

.1 Solution Performance versus Desired Value

Business analysts examine the measures previously collected in order to assess their ability to help stakeholders understand the solution’s value. If the measures are not sufficient to help stakeholders determine solution value, business analysts either collect more measurements or treat the lack of measures as a solution risk.

.2 Risks

Performance measures may uncover new risks to solution performance and to the enterprise. These risks are identified and managed like any other risks.

.3 Trends

When analyzing performance data, business analysts consider the time period when the data was collected to guard against anomalies and skewed trends. A large enough sample size over a sufficient time period will provide an accurate depiction of solution performance on which to make decisions and guard against false signals brought about by incomplete data. Any pronounced and repeated trends, such as a noticeable increase in errors at certain times or a change in process speed when volume is increased, are noted.

.4 Accuracy

Business analysts test and analyze the data collected by the performance measures to ensure their accuracy. To be considered accurate and reliable, the results of performance measures should be reproducible and repeatable.

.5 Performance Variance

The difference between expected and actual performance represents a variance that is considered when analyzing solution performance. Root cause analysis may be necessary to determine the underlying causes of significant variances within a solution.

8.2.5 Guidelines and Tools

- Change Strategy^ **- Future State Description

• Risk Analysis Results
• Solution Scope**^

8.2.6 Techniques

• Acceptance and Evaluation Criteria^
• Benchmarking and Market Analysis
• Data Mining
• Interviews
• Metrics and Key Performance Indicators (KPIs)^
  • Observation
  • Risk Analysis and Management
  • Root Cause Analysis^
  • Survey or Questionnaire

8.2.7 Stakeholders

• Domain Subject Matter Expert
• Project Manager - Sponsor^

8.2.8 Outputs

• Solution Performance Analysis : results of the analysis of measurements collected and recommendations to solve performance gaps and leverage opportunities to improve value.

8.3 Assess Solution Limitations (page 173)

8.3.1 Purpose

• Determine the factors internal to the solution that restrict the full realization of value.^

8.3.2 Description

• Identifies the root causes for under-performing and ineffective solutions and solution components. This task focuses on the assessment of those factors internal to the solution if the solution has not met its potential value. This assessment may be performed at any point during the solution life cycle. It may occur on a solution component during its development, on a completed solution prior to full implementation, or on an existing solution that is currently working within an organization.

8.3.3 Inputs

- Implemented Solution (external)^ - Solution Performance Analysis (8.2)^

8.3.4 Elements

.1 Identify Internal Solution Component Dependencies

Solutions often have internal dependencies that limit the performance of the entire solution to the performance of the least effective component. Business analysts identify solution components which have dependencies on other solution components, and then determine if there is anything about those dependencies or other components that limit solution performance and value realization.

.2 Investigate Solution Problems

Business analysts identify problems in a solution or solution component by examining instances where the outputs from the solution are below an acceptable level of quality or where the potential value is not being realized. Problems may be indicated by an inability to meet a stated goal, objective, or requirement, or may be a failure to realize a benefit that was projected during the tasks Define Change Strategy or Recommend Actions to Increase Solution Value.

.3 Impact Assessment

Business analysts review identified problems in order to assess the effect they may have on the operation of the organization or the ability of the solution to deliver its potential value. This requires determining the severity of the problem, the probability of the re-occurrence of the problem, the impact on the business operations, and the capacity of the business to absorb the impact. Business analysts identify which problems must be resolved, which can be mitigated through other activities or approaches, and which can be accepted.

In addition to identified problems, business analysts assess risks to the solution and potential limitations of the solution. This risk assessment is specific to the solution and its limitations.

8.3.5 Guidelines and Tools

- Change Strategy^ - Risk Analysis Results^ - Solution Scope

8.3.6 Techniques

8.3.7 Stakeholders

• Customer^
• Domain Subject Matter Expert^
• End User^
• Regulator^ - Sponsor - Tester

8.3.8 Outputs

• Solution Limitation : a description of the current limitations of the solution including constraints and defects.

8.4 Assess Enterprise Limitations (page 177)

8.4.1 Purpose

• Determine how factors external to the solution are restricting value realization.
  • Acceptance and Evaluation Criteria
  • Benchmarking and Market Analysis
  • Business Rules Analysis
  • Data Mining
  • Decision Analysis
  • Interviews
    • Item Tracking
    • Lessons Learned
    • Risk Analysis and Management
    • Root Cause Analysis
    • Survey or Questionnaire

8.4.2 Description

• Solutions may operate across various organizations within an enterprise, and therefore have many interactions and interdependencies. Solutions may also depend on environmental factors that are external to the enterprise. Enterprise limitations may include factors such as culture, operations, technical components, stakeholder interests, or reporting structures.
• Assessing enterprise limitations identifies root causes and describes how enterprise factors limit value realization. This assessment may be performed at any point during the solution life cycle. It may occur on a solution component during its development or on a completed solution prior to full implementation, or on an existing solution that is currently working within an organization.

8.4.3 Inputs

- Current State Description (6.1)^ - Implemented (or Constructed) Solution (external)^ - Solution Performance Analysis (8.2)^

8.4.4 Elements

.1 Enterprise Culture Assessment

Enterprise culture is defined as the deeply rooted beliefs, values, and norms shared by the members of an enterprise. While these beliefs and values may not be directly visible, they drive the actions taken by an enterprise. Business analysts perform cultural assessments to:

• identify whether or not stakeholders understand the reasons why a solution exists,^
• ascertain whether or not the stakeholders view the solution as something beneficial and are^ supportive of the change, and
• determine if and what cultural changes are required to better realize value from a solution.

The enterprise culture assessment evaluates the extent to which the culture can accept a solution.

.2 Stakeholder Impact Analysis

A stakeholder impact analysis provides insight into how the solution affects a particular stakeholder group. When conducting stakeholder impact analysis, business analysts consider:

• Functions : the processes in which the stakeholder uses the solution, which include inputs a stakeholder provides into the process, how the stakeholder uses the solution to execute the process, and what outputs the stakeholder receives from the process.
• Locations : the geographic locations of the stakeholders interacting with the solution. If the stakeholders are in disparate locations, it may impact their use of the solution and the ability to realize the value of the solution.
• Concerns : the issues, risks, and overall concerns the stakeholders have with the solution. This^ may include the use of the solution, the perceptions of the value of the solution, and the impact the solution has on a stakeholder’s ability to perform necessary functions.

.3 Organizational Structure Changes

The use of a solution and the ability to adopt a change can be enabled or blocked by formal and informal relationships among stakeholders. The reporting structure may be too complex or too simple to allow a solution to perform effectively. Assessing if the organizational hierarchy supports the solution is a key activity. On occasion, informal relationships within an organization, whether

alliances, friendships, or matrix-reporting, impact the ability of a solution to deliver potential value.

.4 Operational Assessment

The operational assessment is performed to determine if an enterprise is able to adapt to or effectively use a solution. This identifies which processes and tools within the enterprise are adequately equipped to benefit from the solution, and if sufficient and appropriate assets are in place to support it. When conducting an operational assessment, business analysts consider - policies and procedures, capabilities and processes that enable other capabilities, skill and training needs, human resources practices,risk tolerance and management approaches, and tools and technology that support a solution.

8.4.5 Guidelines and Tools

**- Business Objectives

• Change Strategy**^ **- Future State Description
• Risk Analysis Results
• Solution Scope**

8.4.6 Techniques

8.4.7 Stakeholders

• Customer
• Domain Subject Matter Expert
• End User^
• Regulator - Sponsor

8.4.8 Outputs

• Enterprise Limitation : a description of the current limitations of the enterprise including how the solution performance is impacting the enterprise.
• Benchmarking and Market Analysis
• Brainstorming
• Data Mining
• Decision Analysis
• Document Analysis
• Interviews
• Item Tracking
• Lessons Learned
• Observation
• Organizational Modelling
• Process Analysis
• Process Modelling
• Risk Analysis and Management
• Roles and Permission Matrix
• Root Cause Analysis
• Survey or Questionnaire
• SWOT Analysis
• Workshops

8.5 Recommend Actions to Increase Solution Value (page 182)

8.5.1 Purpose

• Understand the factors that create differences between potential value and actual value, and to recommend a course of action to align them.

8.5.2 Description

• The task Recommend Actions to Increase Solution Value (p. 182), focuses on understanding the aggregate of the performed assessments and identifying alternatives and actions to improve solution performance and increase value realization.
• Recommendations generally identify how a solution should be replaced, retired, or enhanced. They may also consider long-term effects and contributions of the solution to stakeholders.

8.5.3 Inputs

- Enterprise Limitation (8.4)^ - Solution Limitation (8.3)

8.5.4 Elements

.1 Adjust Solution Performance Measures

In some cases, the performance of the solution is considered acceptable but may not support the fulfillment of business goals and objectives. An analysis effort to identify and define more appropriate measures may be required.

.2 Recommendations

While recommendations often describe ways to increase solution performance, this is not always the case. Depending on the reason for lower than expected performance, it may be reasonable to take no action, adjust factors that are external to the solution, or reset expectations for the solution. Some common examples of recommendations that a business analyst may make include:

• Do Nothing : is usually recommended when the value of a change is low relative to the effort required to make the change, or when the risks of change significantly outweigh the risks of remaining in the current state.

• Organizational Change : is a process for managing attitudes about, perceptions of, and participation in the change related to the solution. Organizational change management generally refers to a process and set of tools for managing change at an organizational level. Possible recommendations that relate to organizational change include: - automating or simplifying the work people perform. - improving access to information.

• Reduce Complexity of Interfaces : interfaces are needed whenever work is transferred between^ systems or between people. Reducing their complexity can improve understanding.

• Eliminate Redundancy : different stakeholder groups may have common needs that can be met^ with a single solution, reducing the cost of implementation.

• Avoid Waste : the aim of avoiding waste is to completely remove those activities that do not add value and minimize those activities that do not contribute to the final product directly.

• Identify Additional Capabilities : solution options may offer capabilities to the organization above and beyond those identified in the requirements. In many cases, these capabilities are not of immediate value to the organization but have the potential to provide future value.

• Retire the Solution : it may be necessary to consider the replacement of a solution or solution component. This may occur because technology has reached the end of its life, services are being insourced or outsourced, or the solution is not fulfilling the goals for which it was created.

• Some additional factors that may impact the decision regarding the replacement or retirement of^ a solution include: - ongoing cost versus initial investment - opportunity cost - necessity - sunk cost

8.5.5 Guidelines and Tools

**- Business Objectives

• Current State Description**^ - Solution Scope

8.5.6 Techniques

8.5.7 Stakeholders

• Customer
• Domain Subject Matter Expert
• End User
• Regulator - Sponsor

8.5.8 Outputs

• Recommended Actions : recommendation of what should be done to improve the value of the

solution within the enterprise.

• Data Mining
• Decision Analysis
• Financial Analysis
• Focus Group
• Organizational Modelling
  • Prioritization
  • Process Analysis
  • Risk Analysis and Management
  • Survey or Questionnaire

Underlying Competencies

• The Underlying Competencies chapter provides a description of the behaviours, characteristics,

knowledge, and personal qualities that support the practice of business analysis.

• These competencies are grouped into six categories:^
  • Analytical Thinking and Problem Solving (p. 188),
  • Behavioural Characteristics (p. 194),
  • Business Knowledge (p. 199),
  • Communication Skills (p. 203),
  • Interaction Skills (p. 207), and
  • Tools and Technology (p. 211).
• Each underlying competency is defined with a purpose, definition, and effectiveness measures.

9.1 Analytical Thinking and Problem Solving (page 188)

Analytical thinking and problem solving skills are required for business analysts to analyze problems and opportunities effectively, identify which changes may deliver the most value, and work with stakeholders to understand the impact of those changes.

Business analysts use analytical thinking by rapidly assimilating various types of information (for example, diagrams, stakeholder concerns, customer feedback, schematics, user guides, and spreadsheets), and identifying which are relevant.

Possessing a sound understanding of the analytical thinking and problem solving core competencies allows business analysts to identify the best ways to present information to their stakeholders. Analytical Thinking and Problem Solving core competencies include -

Creative Thinking, Decision Making, Learning, Problem Solving, Systems Thinking, Conceptual Thinking, and Visual Thinking.

9.1.1 Creative Thinking

.1 Purpose & .2 Definition

Thinking creatively and helping others to apply creative thinking helps business analysts to be effective in generating new ideas, approaches, and alternatives to problem solving and opportunities. Creative thinking involves generating new ideas and concepts as well as finding new or different associations between existing ideas and concepts. Creative thinking may involve combining, changing, and reapplying existing concepts or ideas.

.3 Effective Measures

Measures of effective creative thinking include:

• generating and productively considering new ideas,
• exploring concepts and ideas that are new,^
• exploring changes to existing concepts and ideas,
• generating creativity for self and others, and
• applying new ideas to resolve existing problems.

9.1.2 Decision Making

.1 Purpose & .2 Definition

Business analysts must be effective in understanding the criteria involved in making a decision, and in assisting others to make better decisions. Determining this involves gathering the information that is relevant to the decision, analyzing the relevant information, making comparisons and trade-offs between similar and dissimilar options, and identifying the most desirable option.

.3 Effective Measures

Measures of effective decision making include:

• the appropriate stakeholders are represented in the decision-making process,^
• stakeholders understand the decision-making process and the rationale behind the decision,
• the pros and cons of all available options are clearly communicated to stakeholders,
• the decision reduces or eliminates uncertainty, and any remaining uncertainty is accepted,^
• the decision made addresses the need or the opportunity at hand and is in the best interest of all stakeholders,
• stakeholders understand all the conditions, environment, and measures in which the decision will^ be made, and
• a decision is made.^

9.1.3 Learning

.1 Purpose & .2 Definition

The ability to quickly absorb new and different types of information and also modify and adapt existing knowledge allows business analysts to work effectively in rapidly changing and evolving environments. Learning is the process of gaining knowledge or skills. Learning techniques to consider include:

• Visual : learning through the presentation of pictures, photographs, diagrams, models, and videos.
• Auditory : learning through verbal and written language and text.
• Kinesthetic : learning by doing.^

.3 Effective Measures

Measures of effective learning include:

• understanding that learning is a process for all stakeholders,^
• learning the concepts presented and then demonstrating an understanding of them,
• demonstrating the ability to apply concepts to new areas or relationships,
• rapidly absorbing new facts, ideas, concepts, and opinions, and
• effectively presenting new facts, ideas, concepts, and opinions to others.^

9.1.5 Systems Thinking

.1 Purpose & .2 Definition

Understanding how the people, processes, and technology within an organization interact allows business analysts to understand the enterprise from a holistic point of view. Systems theory and

systems thinking suggest that a system as a whole has properties, behaviours, and characteristics that emerge from the interaction of the components of that system.

.3 Effective Measures

Measures of effective systems thinking include:

• communicating how a change to a component affects the system as a whole,^
• communicating how a change to a system affects the environment it is in, and
• communicating how systems adapt to internal and/or external pressures and changes.^

9.1.6 Conceptual Thinking

.1 Purpose & .2 Definition

Conceptual thinking is about understanding the linkage between contexts, solutions, needs, changes, stakeholders, and value abstractly and in the big picture. It involves understanding and connecting information and patterns that may not be obviously related. Conceptual thinking involves understanding where details fit into a larger context.

.3 Effective Measures

Measures of effective conceptual thinking include:

• connecting disparate information and acting to better understand the relationship,^
• confirming the confidence and understanding of the concept being communicated with stakeholders,
• formulating abstract concepts using a combination of information and uncertainty, and
• drawing on past experiences to understand the situation.^

9.1.7 Visual Thinking

.1 Purpose & .2 Definition

Visual thinking skills allow business analysts to create graphical representations of the concepts or systems being discussed. The goal of these graphical representations is to allow stakeholders to easily understand the concepts being presented, and then provide input. Visual thinking requires that the analyst make abstractions and then find suitable graphic devices to represent them.

.3 Effective Measures

Measures of effective visual thinking include:

• complex information is communicated in a visual model which is understandable by stakeholders,
• visuals allow for comparisons, pattern finding, and idea mapping with participants,
• productivity increases due to increased learning, quick memory, and follow through from effective visuals,
• stakeholders are engaged at a deeper level than with text alone, and
• stakeholders understand critical information which may have been missed if presented in textual content alone.

9.2 Behavioural Characteristics (page 194)

Behavioural characteristics exist at the core of every business analyst’s skill set. Each of the behavioural characteristics described here can impact the outcome of the practitioner’s efforts. The core competencies of behavioural characteristics focus on the skills and behaviours that allow a business analyst to gain the trust and respect of stakeholders.

Business analysts do this by consistently acting in an ethical manner, completing tasks on time and to expectations, efficiently delivering quality results, and demonstrating adaptability to changing needs and circumstances. Behavioural Characteristics core competencies include -

Ethics, Personal Accountability, Trustworthiness, Organization and Time Management, and Adaptability

9.2.1 Ethics

.1 Purpose & .2 Definition

Behaving ethically and thinking of ethical impacts on others allows business analysts to earn the respect of the stakeholders. Ethics require an understanding and focus on fairness, consideration, and moral behaviour through business analysis activities and relationships. Ethical behaviour includes consideration of the impact that a proposed solution can have on all stakeholder groups and working to ensure that those groups are treated as fairly as possible.

.3 Effective Measures

Measures of effective ethical behaviour include:

• prompt identification and resolution of ethical dilemmas,
• feedback from stakeholders confirming they feel decisions and actions are transparent and fair,
• decisions made with consideration of the interests of all stakeholders,^
• reasoning for decisions that is clearly articulated and understood,^
• full and prompt disclosure of potential conflicts of interest, and
• honesty regarding one’s abilities, the performance of one’s work, and accepting responsibility for^ failures or errors.

9.2.2 Personal Accountability

.1 Purpose & .2 Definition

Personal accountability is important for a business analyst because it ensures business analysis tasks are completed on time and to the expectations of colleagues and stakeholders. It includes effectively planning business analysis work to achieve targets and goals, and ensuring that value delivered is aligned with business needs.

.3 Effective Measures

Measures of effective personal accountability include:

• work effort is planned and easily articulated to others,^

• work is completed as planned or re-planned with sufficient reasoning and lead time,

• status of both planned and unplanned work is known,

• stakeholders feel that work is organized,^

• risks and issues are identified and appropriately acted on,^

• completely traceable requirements are delivered on time, and stakeholder needs are met.

9.2.3 Trustworthiness

.1 Purpose & .2 Definition

Earning the trust of stakeholders helps business analysts elicit business analysis information around sensitive issues and enables them to help stakeholders have confidence that their recommendations will be evaluated properly and fairly. Several factors can contribute to being considered trustworthy like - intentionally and consistently completing tasks and deliverables on time and within budget, presenting a consistent attitude of confidence, acting in an honest and straightforward manner, addressing conflict and concerns immediately, and maintaining a consistent schedule over a long period of time.

.3 Effective Measures

Measures of effective trustworthiness include:

• stakeholders involve the business analyst in discussions and decision making,
• stakeholders bring issues and concerns to the business analyst,^
• stakeholders are willing to discuss difficult or controversial topics with the business analyst,
• stakeholders do not blame the business analyst when problems occur,
• stakeholders respect the business analyst’s ideas and referrals, and
• stakeholders respond to the business analyst’s referrals with positive feedback.^

9.2.4 Organization and Time Management

.1 Purpose & .2 Definition

Organization and time management skills help business analysts perform tasks effectively and use work time efficiently. It involves the ability to prioritize tasks, perform them efficiently, and manage time effectively. Techniques of organization include establishing short- and long-term goals, action plans, prioritizing tasks, and utilizing a checklist. Techniques for effective time management include establishing time limits on non-critical tasks, focusing more time on high risk and priority tasks, setting aside focus time, and managing potential interruptions.

.3 Effective Measures

Measures of effective organization and time management include:

• the ability to produce deliverables in a timely manner,
• stakeholders feel that the business analyst focuses on the correct tasks at the right time,
• schedule of work effort and deadlines is managed and communicated to stakeholders,^
• stakeholders feel their time in meetings and in reading communications is well spent,
• complete preparation for meetings, interviews, and requirements workshops,
• relevant business analysis information is captured, organized, and documented,^
• adherence to the project schedule and the meeting of deadlines,
• provides accurate, thorough, and concise information in a logical manner which is understood by stakeholders, and
• maintains up-to-date information on the status of each work item and all outstanding work.

9.2.5 Adaptability

.1 Purpose & .2 Definition

Business analysts frequently work in rapidly changing environments and with a variety of stakeholders. They adjust their behavioural style and method of approach to increase their effectiveness when interacting with different stakeholders, organizations, and situations. Adaptability is the ability to change techniques, style, methods, and approach to changing situations and context.

.3 Effective Measures

Measures of effective adaptability include:

• demonstrating the courage to act differently from others,
• adapting to changing conditions and environments, valuing and considering other points of view and approaches, demonstrating a positive attitude in the face of ambiguity and change, demonstrating a willingness to learn new methods, procedures, or techniques in order to accomplish goals and objectives,
• changing behaviour to perform effectively under changing or unclear conditions,^
• acquiring and applying new information and skills to address new challenges,^
• acceptance of having changes made to tasks, roles and project assignments as organizational realities change,
• altering interpersonal style to highly diverse individuals and groups in a range of situations, and^
• evaluating what worked, what did not, and what could be done differently next time.^

9.3 Business Knowledge (page 199)

Business knowledge is required for the business analyst to perform effectively within their business, industry, organization, solution, and methodology. Business knowledge enables the business analyst to better understand the overarching concepts that govern the structure, benefits, and value of the situation as it relates to a change or a need. Business Knowledge underlying competencies include -

Business Acumen, Industry Knowledge, Organization Knowledge, Solution Knowledge, and Methodology Knowledge

9.3.1 Business Acumen

.1 Purpose & .2 Definition

Business acumen is the ability to understand business needs using experience and knowledge obtained from other situations. Being aware of the experiences or challenges encountered in the past may assist a business analyst in determining which information may be applicable to the current situation. Factors that may cause differences in practices can include industry, location, size of organization, culture, and the maturity of the organization.

.3 Effective Measures

Measures of effective business acumen include:

• demonstrating the ability to recognize potential limitations and opportunities,^
• demonstrating the ability to recognize when changes to a situation may require a change in the direction of an initiative or effort,
• understanding the risks involved and the ability to make decisions on managing risks,
• demonstrating the ability to recognize an opportunity to decrease expenses and increase profits, and
• understanding the options available to address emerging changes in the situation.^

9.3.2 Industry Knowledge

.1 Purpose & .2 Definition

Industry knowledge provides the business analyst with an understanding of current practices and activities within an industry, and similar processes across industries. Industry knowledge is an understanding of: current trends, market forces, market drivers, key processes, services, products, definitions, customer segments, suppliers, practices, regulations, and other factors that impact or are impacted by the industry and related industries. Industry knowledge is also an understanding of how a company is positioned within an industry, and its impacts and dependencies, in regards to the market and human resources.

.3 Effective Measures

Measures of effective industry knowledge include:

• being aware of activities within both the enterprise and the broader industry,^
• having knowledge of major competitors and partners,
• the ability to identify key trends shaping the industry,
• being familiar with the largest customer segments,^
• having knowledge of common products and product types,^
• being knowledgeable of sources of information about the industry,
• understanding of industry specific terms, standards, processes and methodologies, and^
• understanding of the industry regulatory environment.

9.3.3 Organization Knowledge

.1 Purpose & .2 Definition

Organization knowledge includes an understanding of how the enterprise generates profits, accomplishes its goals, the management and organization structure, the relationships that exist between business units, and the persons who occupy key stakeholder positions. Organization knowledge also includes understanding the organization’s formal and informal communication channels as well as an awareness of the internal politics that influence decision making.

.3 Effective Measures

Measures of effective organization knowledge include:

• the ability to act according to informal and formal communications and authority channels,
• understanding of terminology or jargon used in the organization,^
• understanding of the products or services offered by the organization,^
• the ability to identify subject matter experts (SMEs) in the organization, and
• the ability to navigate organizational relationships and politics.^

9.3.4 Solution Knowledge

.1 Purpose & .2 Definition

Solution knowledge allows business analysts to leverage their understanding of existing departments, environments, or technology to efficiently identify the most effective means of implementing a change. The business analyst may leverage knowledge gained from prior experiences to expedite the discovery of potential changes through elicitation or in-depth analysis. Familiarity with the range of commercially available solutions or suppliers can assist with the identification of possible alternatives.

.3 Effective Measures

Measures of effective solution knowledge include:

• reduced time or cost to implement a required change,
• shortened time on requirements analysis and/or solution design,
• understanding when a larger change is, or is not, justified based on business benefit, and
• understanding how additional capabilities that are present, but not currently used, can be deployed to provide value.

9.3.5 Methodology Knowledge

.1 Purpose & .2 Definition

Organizations adopt or create their own methodologies to fit varying levels of culture, maturity, adaptability, risk, uncertainty, and governance. Knowledge regarding a variety of methodologies allows the business analyst to quickly adapt to, and perform in, new environments.

.3 Effective Measures

Measures of effective methodology knowledge include:

• the ability to adapt to changes in methodologies,^
• the willingness to use or learn a new methodology,
• the successful integration of business analysis tasks and techniques to support the current^ methodology,
• familiarity with the terms, tools, and techniques prescribed by a methodology, and^
• the ability to play multiple roles within activities prescribed by a methodology.^

9.4 Communication Skills (page 203)

Communication is the act of a sender conveying information to a receiver in a method which delivers the meaning the sender intended. Active listening skills help to deepen understanding and trust between the sender and the receiver. Effective communication benefits all stakeholders. Communication may be accomplished using a variety of delivery methods: verbal, non-verbal,

physical, and written. Most communication methods deal with words, while some methods deal with movements and expressions.

Planning effective communication includes the sender reviewing the information that is known about the receiver. Differences between the sender and the receiver, such as native language, culture, motivations, priorities, communication, learning, and thinking styles may call for specific

communication methods. When planning to communicate information, the following considerations may be helpful:

• consider what the receiver knows or does not know,^
• structure the information in a logical, comprehensible manner,
• determine how to best present the information to convey the intended meanings (for example, using visual aids, graphs, diagrams, or bullet points), and
• understand the expectations of the recipients.^

Communication Skills core competencies include -

Verbal Communication, Non-Verbal Communication, Written Communication, and Listening.

9.4.1 Verbal Communication

.1 Purpose & .2 Definition

Business analysts use verbal communication to convey ideas, concepts, facts, and opinions to a variety of stakeholders. Verbal communication uses spoken words to convey information from the sender to the receiver. Verbal communication skills are used to express business analysis information, ideas, concepts, facts, and opinions. It allows for the efficient transfer of information, including emotional and other non-verbal cues. Verbal communication deals specifically with the sender’s choice of words and the tone of voice. It can be paired with both written and non-verbal communication.

.3 Effective Measures

Measures of effective verbal communication include:

• restating concepts to ensure all stakeholders clearly understand the same information,
• assisting conversations to reach productive conclusions,
• delivering effective presentations by designing and positioning content and objectives appropriately, and
• communicating an issue’s important points in a calm and rational manner, and presenting solution options.

9.4.2 Non-Verbal Communication

.1 Purpose & .2 Definition

Non-verbal communication skills enable the effective sending and receiving of messages through —but not limited to—body movement, posture, facial expressions, gestures, and eye contact. Moods, attitudes, and feelings impact body movement and facial expressions. Non-verbal communication begins immediately when one person is able to see another. The effective use of non-verbal communication skills can present a trustworthy, confident, and capable demeanor.

.3 Effective Measures

Measures of effective non-verbal communication include:

• being aware of body language in others, but not assuming a complete understanding through non-verbal communication,

• intentional awareness of personal non-verbal communication,

• improving trust and communication as a result of non-verbal communication, and^

• effectively addressing and resolving situations when a stakeholder’s non- verbal communication does not agree with their verbal message.

9.4.3 Written Communication

.1 Purpose & .2 Definition

Written communication is the practice of using text, symbols, models (formal or informal), and sketches to convey and share information. An understanding of the audience is beneficial to effectively use written communication. Written communication has the added challenge of presenting information using the correct words to the audience, and at a time or place that is remote from the time and place it was created.

.3 Effective Measures

Measures of effective written communication include:

• adjusting the style of writing for the needs of the audience,
• proper use of grammar and style,^
• choosing words the audience will understand the intended meaning of, and
• ability of the reader to paraphrase and describe the content of the written communication.

9.4.4 Listening

.1 Purpose & .2 Definition

Listening is the process of not just hearing words but understanding their meaning in context. By exhibiting effective listening skills, business analysts not only have a greater opportunity to accurately understand what is being communicated, but also to demonstrate that they think what the speaker is saying is important.

.3 Effective Measures

Measures of effective listening include:

• giving the speaker undivided attention,
• acknowledging the speaker with verbal or non-verbal encouragement,
• providing feedback to the person or the group that is speaking to ensure there is an^ understanding, and
• using active listening skills by deferring judgment and responding appropriately.

9.5 Interaction Skills (page 207)

Interaction skills are represented by the business analyst’s ability to relate, cooperate, and communicate with different kinds of people. Business analysts are uniquely positioned to facilitate stakeholder communication, provide leadership, encourage comprehension of solution value, and promote stakeholder support of the proposed changes. Interaction Skills core competencies include:

Facilitation, Leadership and Influencing, Teamwork, Negotiation and Conflict Resolution, and Teaching.

9.5.1 Facilitation

.1 Purpose & .2 Definition

Business analysts facilitate interactions between stakeholders in order to help them make a decision, solve a problem, exchange ideas and information, or reach an agreement regarding the priority and the nature of requirements, and also for negotiation and conflict resolution. Facilitation is the skill of moderating discussions within a group in order to enable all participants to effectively articulate their views on a topic under discussion, and to ensure that participants in the discussion are able to recognize and appreciate the differing points of view that are articulated.

.3 Effective Measures

Measures of effective facilitation include:

• making it clear to the participants that the facilitator is a third party to the process and not a decision maker nor the owner of the topic,
• encouraging participation from all attendees,
• remaining neutral, but at the same time being impartial and intervening when required,
• establishing ground rules,
• ensuring that participants in a discussion correctly understand each other’s positions,
• using meeting management skills and tools to keep discussions focused and organized,^
• preventing discussions from being sidetracked onto irrelevant topics, and^
• understanding and considering all parties’ interests, motivations, and objectives.

9.5.2 Leadership and Influencing

.1 Purpose & .2 Definition

Leadership and influencing involves motivating people to act in ways that enable them to work together to achieve shared goals and objectives, and guiding stakeholders during the investigation of business analysis information and solution options. Understanding the individual motives, needs, and capabilities of each stakeholder and how those can be effectively channeled assists business analysts in meeting the shared objectives of the organization.

.3 Effective Measures

Measures of effective leadership and influencing include:

• reduced resistance to necessary changes,
• articulation of a clear and inspiring vision of a desired future state,^
• success in inspiring others to turn vision into action,
• influence on stakeholders to understand mutual interests,
• effective use of collaboration techniques to influence others,
• influence on stakeholders to consider broader objectives over personal motivations, and
• re-framing issues so alternate perspectives can be understood and accommodated to influence stakeholders towards shared goals.

9.5.3 Teamwork

.1 Purpose & .2 Definition

Teamwork skills allow business analysts to work productively with team members, stakeholders, and any other vested partners so that solutions can be effectively developed and implemented. Business analysts often work as part of a team with other business analysts, project managers, stakeholders, and subject matter experts (SMEs). Relationships with people in those roles are a critical part of the success of any project or enterprise.

.3 Effective Measures

Measures of effective teamwork include:

• fostering a collaborative working environment,
• effectively resolving conflict,
• developing trust among team members,^
• support among the team for shared high standards of achievement, and
• promoting a shared sense of ownership of the team goals.

9.5.4 Negotiation and Conflict Resolution

.1 Purpose & .2 Definition

Business analysts occasionally mediate negotiations between stakeholders in order to reach a common understanding or an agreement. During this process, business analysts help resolve conflicts and differences of opinion with the intent of maintaining and strengthening working relationships among stakeholders and team members. Negotiation and conflict resolution involves mediating discussions between participants in order to help them recognize that there are differing views on the topic, resolve differences, and reach conclusions that have the agreement of all participants.

.3 Effective Measures

Measures of effective teamwork include:

• a planned approach to ensure that the negotiation takes into account the tone of voice, the conveyed attitude, the methods used, and the concern for the other side’s feelings and needs,
• the ability to recognize that the needs of the parties are not always in opposition and that it is often possible to satisfy both parties without either side losing,
• an objective approach to ensure the problem is separated from the person so that the real issues^ are debated without damaging working relationships, and
• the ability to recognize that effective negotiation and conflict resolution are not always achieved^ in a single autonomous meeting, and that sometimes several meetings are required in order to achieve the stated goals.

9.5.4 Teaching

.1 Purpose & .2 Definition

Teaching skills help business analysts effectively communicate business analysis information, concepts, ideas, and issues. Teaching is the process of leading others to gain knowledge. Business analysts are responsible for confirming that the information communicated has been

understood by stakeholders. This requires teaching skills in selecting the most appropriate visual, verbal, written, and kinesthetic teaching approaches according to the information or techniques being taught.

.3 Effective Measures

Measures of effective teaching include:

• utilizing different methods to communicate information to be learned by stakeholders,
• discovering new information through high levels of stakeholder engagement,
• validating that audiences have a clear understanding of the key messages that are intended to be learned, and
• verifying that the stakeholders can demonstrate the new knowledge, facts, concepts, and ideas.

9.6 Tools and Technology (page 211)

Business analysts use a variety of software applications to support communication and collaboration, create and maintain requirements artifacts, model concepts, track issues, and increase overall productivity. Requirements documentation is often developed using word processing tools. Requirements management technologies support requirements workflow, approvals, baselining, and change control. Interacting with the stakeholders and team members may require the use of communication and collaboration tools, as well as presentation software

Business Analysis Tools and Technology core competencies include:

Office Productivity Tools and Technology, Business Analysis Tools and Technology, and Communication Tools and Technology.

9.6.1 Office Productivity Tools and Technology

.1 Purpose & .2 Definition

Business analysts use office productivity tools and technology to document and track information and artifacts. Office productivity tools and technology provide business analysts with the ability to organize, dissect, manipulate, understand, and communicate information clearly. Many organizations utilize these tools to study, store, and distribute information. Office productivity tools and technology include the following:

• Word processing and presentation programs
• Presentation software
• Spreadsheets^
• Communication Tools (e-mail and instant messaging programs)
• Collaboration and knowledge management tools^
• Hardware^

.3 Effective Measures

Measures of effective office productivity tools and technology include:

• increased efficiencies and streamlining of processes by exploring features and functions of tools,
• awareness of available tools, their operation, and abilities,^
• the ability to determine the tool that will best meet stakeholder needs, and
• the ability to clearly communicate the major features of available tools.^

9.6.2 Business Analysis Tools and Technology

.1 Purpose & .2 Definition

Business analysts use a variety of tools and technology to model, document, and manage outputs of business analysis activities and deliverables to stakeholders. Tools that are specific to the field of business analysis provide specialized capabilities in - modelling, diagramming, documenting, analyzing and mapping requirements, identifying relationships between requirements, tracking and storing requirements artifacts, and communicating with stakeholders.

Tools specifically designed for business analysis may include such functionality as modelling, requirements management, issue tracking, prototyping and simulation, computer aided software engineering (CASE), and survey engines.

.3 Effective Measures

Measures of effective business analysis tools and technology include:

• the ability to apply an understanding of one tool and other similar tools,^
• being able to identify major tools currently available and describe their strengths, weaknesses, and how they may be used in any given situation,
• understanding of and the ability to use the major features of the tool, ability to select a tool or tools that support organizational processes,
• the ability to use the tools to complete requirements-related activities more rapidly than otherwise possible, and
• the ability to track changes to the requirements and their impact on the solution implementation,^ stakeholders, and value.

9.6.3 Communication Tools and Technology

.1 Purpose & .2 Definition

Business analysts use communication tools and technology to perform business analysis activities, manage teams, and collaborate with stakeholders. Communication tools are used to plan and complete tasks related to conversational interactions and collaborative interactions. Communication tools allow business analysts to work with virtual and co-located teams. Business analysts select the appropriate tool and technology for the situation and stakeholder group while balancing cost, risk, and value.

Examples of conversation interaction tools include voice communications, instant messaging, online chat, e-mail, blogging, and microblogging. Examples of collaboration tools include video conferencing, electronic white boarding, wikis, electronic calendars, online brainstorming tools, electronic decision making, electronic voting, document sharing, and idea sharing.

.3 Effective Measures

Measures of effective business analysis tools and technology include:

• the selection of appropriate and effective tools for the audience and purpose,
• effectively choosing when to use communication technology and when not to,^
• the ability to identify tools to meet communication needs, and
• understanding of and the ability to use features of the tool.^

Techniques

Backlog Management

Decision Modelling

Decision Tables

Simple Decision Matrix

Weighted Decision Matrix

Decision Table

Eligibility Rules

Decision Tree

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

graph LR
A[Amount]
A -->|<=1000| AA(Age)
    AA -->|>18| AAA(Eligible)
    AA -->|<=18| AAB(Ineligible)
A -->|1000-2000| AB(Age)
    AB -->|>21| ABA(Eligible)
    AB -->|<=21| ABB(Ineligible)
A -->|>2000| AC(Age)
    AC -->|=25| ACA(Eligible)
    AC -->|<25| ACB(Ineligible)

Decision Requirements Diagram

Perspectives

The Agile Perspective

The Business Intelligence Perspective

The Information Technology Perspective

The Business Architecture Perspective

The Business Process Management Perspective

BA目标

• 以用户为中心，实现用户体验的持续改进，提升用户满意度

BA职责

• 参与产品架构的规划，负责产品应用架构的看护，确保产品需求符合产品应用架构规划，符合公司应用架构原则
• 负责IT产品端到端的需求管理，负责需求收集和、识别和排序，管理需求变更
• 负责产品需求分析、方案设计、API设计、用户体验设计，输出产品需求规则、Feature/Story和用户体验设计方案包
• 负责SIT测试结果的验收，参与UAT测试
• 参与产品上线准备度的评估，与业务人员一起编织用户手册，参与产品试点与推行。
• 负责产品设计质量，通过需求的运营，通过检测需求上线后业务价值，用户体验、性能等是否达到需求预期

BA能力地图

• 需求管理
  • 沟通引导力
    • 掌握识别、分类和管理产品干系人的方法
    • 掌握高效沟通与引导方法，进行有效的倾听与提问，有效挖掘用户潜在需求
    • 高效引导会议，对会议中的破坏性行为能够提前识别与消除，保证会议的顺利进行
    • 掌握培训与演讲的部分技巧，有效促进方案达成共识
  • 精益需求管理
    • 高效引导与挖掘用户需求与痛点，考虑业务、用户、技术三个要素进行需求分析
    • 掌握基于用户故事的精益需求管理方法，掌握产品特性、用户故事拆分方法及原则，定义需求验收标准，管理backlog和验收测试
    • 能够基于业务价值对需求优先级进行排序，
• 用户体验
  • 用户研究方法
    • 能够掌握定性与定量的用户研究方法与技巧，能够挖掘用户的痛点与产品价值，将用户研究方法应用到日常交付中
  • 用户体验设计方法
• 架构设计
  • 云化服务化设计
  • 应用架构设计
  • 软件包功能与架构
• 测试管理
  • 测试需求管理
    • 熟悉软件测试理论和原则，掌握黑合与白盒测试方法
    • 能够根据产品需求对测试需求分析，设计测试场景，搭建测试环境，准备测试数据、验收测试以及编写测试报告
• 产品运营
  • 产品运营方法
    • 理解业务运营、产品运营、用户运营的目标与实验框架，掌握运营方法，能够有效提升用户活跃度、验收自动化率、PO自动化率、问题解决周期、产品重点功能使用率、产品性能。能够识别问题与差距，推动产品持续改进，支撑业务效率持续提升

交付件

制定IT高阶解决方案 制定IT详细解决方案 确认需求归属感的产品 持续规划需求，定义产品特性和版本计划 刷新产品架构设计 Story设计及排序 制定迭代计划 Story开发 SIT测试 UAT测试 集成验证 上线验收

Reference

Certified Business Analysis Professional (CBAP®)

Business Analyst Certification Learning Path

A Guide to the Business Analysis Body of Knowledge (BABOK Guide)

Certified ScrumMaster® (CSM) Certification Training Course