Perspectives

Perspectives are used within business analysis work to provide focus to tasks and techniques specific to the context of the initiative. Most initiatives are likely to engage one or more perspectives. The perspectives included in the BABOK® Guide _are:
• Agile,
• Business Intelligence,
• Information Technology,
• Business Architecture, and
• Business Process Management.
These perspectives do not presume to represent all the possible perspectives from which business analysis is practiced. The perspectives discussed in the _BABOK® _Guide _represent some of the most common views of business analysis at the time of writing.
Any given initiative includes one, many, or all of these perspectives. For example, an initiative may have a technology component (Information Technology Perspective), the technology component may mean business process changes (Business Process Management Perspective), the initiative may decide to do part, or all of the work with an agile approach (Agile Perspective). Another initiative may merge two organizations and need to look at the business capabilities and how the transformation impacts those capabilities (Business Architecture Perspective), and the business leaders need updated information for decision making and analysis (Business Intelligence Perspective). Large or complex initiatives will likely employ all perspectives.

While the business analysis tasks detailed in the BABOK® Guide _are intended to be applicable across all areas of business analysis, they are also pertinent to each specific business analysis perspective. Perspectives provide ways to approach business analysis work in a more focused manner suitable to the context. The perspectives help interpret and understand the knowledge areas and tasks in the
_BABOK® _Guide _from the lens in which one is currently working.
Each perspective follows a common structure:
• Change Scope,
• Business Analysis Scope,
• Methodologies, Approaches, and Techniques,
• Underlying Competencies, and
• Impact on Knowledge Areas.

11.1 The Agile Perspective

The Agile Perspective highlights the unique characteristics of business analysis when practiced in the context of agile environments.
Agile is about having a flexible mindset, embodied in a set of values and principles and exhibited by a variety of complementary practices. Agile initiatives involve constant change. Business analysts working on agile initiatives continually reassess, adapt, and adjust their efforts and tactics. Business analysts conduct analysis and deliver work products at the last responsible moment to continually allow flexibility for change; detailed analysis work is not done ahead of time, but just in time to be effectively utilized by the agile team.
Agile business analysis ensures that information is available to the agile team at the right level of detail at the right time. Business analysts help agile teams answer these questions:
• What need are we trying to satisfy?
• Is that need worth satisfying?
• Should we deliver something to satisfy that need?
• What is the right thing to do to deliver that need?
Business analysis work is performed continuously throughout an agile initiative and relies heavily on interpersonal skills such as communication, facilitation, coaching, and negotiation. Business analysts are active members of an agile team and often facilitate planning, analyzing, testing, and demonstrating activities. In an agile team, business analysis may be performed by a product manager/owner, business analyst, or by other defined team roles. Business analysts help the team identify modifications in assumptions and other project variations that emerge.
Refer to the Agile Extension to the BABOK® _Guide _for an expanded treatment of the role, mindset, and practices of business analysis in agile approaches, as well as details on the values and principles of the Agile Manifesto (www.agilemanifesto.org).

11.1.1 Change Scope

Business analysts working on agile initiatives engage with the business sponsor on a strategic level and assist with defining how the proposed product or feature aligns with the organization’s objectives. They collaborate with various stakeholders and the change team to break the product vision down into a prioritized list of desired work items to be completed. The prioritized items (or prioritized backlog list) usually focus on the capabilities needed in the resultant product, with emphasis on the highest value items first.
Business analysts may act as a stakeholder proxy, or work directly with the sponsor or product owner.
In agile environments, change and rapid response to change is expected. Agile teams deliver small, incremental changes and commit to prioritized work items for only one iteration at a time. This allows the agile team to handle emerging changes for the upcoming iteration with minimal impact. An iteration is an agreed period of work time.
Requirements are developed through continual exploration and analysis of the business needs. It is important to note that though most agile approaches are iterative, not all iterative approaches are agile. There are also several agile approaches that are not iterative, such as the kanban method.
During agile initiatives, scope is constantly evolving. This is managed by the backlog list which is continually reviewed and re-prioritized. This process contributes to the refinement and redefinition of scope in order to meet the evolving and emerging business need.
If a major change emerges that significantly impacts the overall value and goals for the project, the project can be adjourned and reassessed.

.1 Breadth of Change

Agile approaches are used to address a variety of needs in an enterprise. The most common use of agile practices is in software development projects. However, many organizations have started to apply agile principles to non-software related change such as process engineering and business improvement. Initiatives using agile approaches can be undertaken within a single department or can span across multiple teams, departments, and divisions of an organization.
For organizations new to the agile mindset and practices, a focus on continuous improvement, ongoing changing behaviour, and making progress enables the organization to move towards culturally adopting the agile mindset. Adopting the agile mindset refers to the cultural adoption of agile principles as opposed to the organization considering agile as a methodology or practice to be implemented.

.2 Depth of Change

Initiatives using an agile approach are frequently part of a larger program of work, which can include organizational transformation and change, business process re-engineering, or business process change. The agile work stream is frequently, but not always, centered on software development. The other

elements of the program can be developed using agile or another methodology that is appropriate for the need. Agile principles and practices are often successfully applied in initiatives where:
• there is a clear commitment from the customer and engagement by empowered subject matter experts (SMEs),
• the business need or proposed solution is complex or complicated, and
• business needs are changing or unknown and are still emerging.
Agile approaches can be used for initiatives that are developing a solution for the first time, or for maintaining and enhancing an existing solution. For example, if the change is mission critical then processes can be added to address regulatory requirements and to deal with the mission critical aspects of the project.

.3 Value and Solutions Delivered

The value and solutions delivered in an agile initiative are similar to any other initiative. The difference with an agile approach is the emphasis on delivering value early in a highly collaborative manner, using adaptive planning that has a focus on continuous improvement.
An agile initiative provides value by virtue of the approach taken by an agile team through ongoing review and feedback of the work performed. Stakeholders get the opportunity to frequently review the product, which allows them to identify any missed requirements early. The solution evolves over time with an expectation of rapid and flexible response to change. Clarity and visibility of all communications is of the utmost importance to ensure the agile team’s efforts align with the organization’s needs and expectations.
In a new team, the business analyst often plays a central role in building rapport and trust amongst the agile team members and external stakeholders to help enable ongoing collaborative discussions and engagement. This interaction enables the agile team to accurately deliver value that meets evolving stakeholder needs.

.4 Delivery Approach

Agile approaches focus on people interactions, transparent communications, and ongoing delivery of valuable change to stakeholders.
Each agile approach has its own unique set of characteristics that allows teams to select an approach that best suits the initiative at hand. Some agile teams have found that a hybrid or combination of approaches is necessary to work within the constraints of their environment.
Refer to the Agile Extension to the BABOK® _Guide _for a description of different agile delivery approaches.

.5 Major Assumptions

The assumptions in place in agile environments frequently include:
• Changing requirements are welcome, even late in development.

• The business problem can be reduced to a set of needs that can be met using some combination of technology and business process change.
• Agile initiatives have fully engaged customers and empowered SMEs with complete buy-in to the agile approach.
• Ideally, team membership is constant and members are not continually being moved to other teams.
• There is a preference for multidisciplinary and co-located teams encouraging more efficient and effective face-to-face conversation. However, agile approaches can work well with distributed teams provided appropriate support and communication channels are in place.
• Team members may perform more than one role within the team if it is required, and provided that the team has the appropriate skills (for example, cross-functional teams).
• Team members have a mindset for continuous improvement and successful value delivery through regular inspection.
• Agile teams are empowered and self-organizing.

11.1.2 Business Analysis Scope

.1 Change Sponsor

It is important that a sponsor of an agile initiative be familiar with the agile philosophy, mindset, and approaches, and also be open to the constant feedback that will require trade-offs from the stakeholders.
An agile sponsor understands and accepts the:
• use of adaptive planning over predictive planning,
• use and value of a fixed period of time for a work cycle, and
• need and value of the sponsor’s involvement.
The sponsor’s (or empowered SME’s) active involvement with the agile team is critical to providing the sponsor with the ability to preview and understand the product being developed, as well as allowing an opportunity for the sponsor to provide continuous feedback to the team and adjust the product as needs change.

.2 Change Targets and Agents

Agile approaches are most successful when the organizational culture and working environments lend themselves to intensive collaboration, frequent communication, and a strong disposition towards incremental delivery of appropriate solution value.
Agile teams are frequently either small or around teams of small teams. The simpler and flatter structure doesn’t change the fact that the deliverables may affect a large group of stakeholders. The change agent, also considered a

stakeholder, is not different because the project uses agile. The primary agents for a change using an agile approach can include:
• Agile team leader: the facilitator of the work of the team. An agile team leader frequently shares the same soft skill set of a project manager, but completely delegates the tasks of planning, scheduling, and prioritization to the team. Rather than traditional command-and-control management, servant leadership is preferred in all the agile approaches. Depending on the approach, this role may be called scrum master, iteration manager, team leader, or coach.
• Customer representative or product owner: the active team member responsible for ensuring that the change being developed addresses the requirements for which it has been mandated. In Scrum this role is called the product owner. The dynamic systems development method (DSDM) refers to this role as that of a visionary, and extreme programming (XP) refers to it as a customer representative.
• Team members: the specialists or domain experts that include both technical and customer representation. Depending on size and particular context of the initiative, individuals within a team have different specialties. Usability experts, technical architects, and database administrators are just a sample of such specialized roles that provide support to the team as needed.
• External stakeholders: all of the remaining stakeholders who may not be considered team members, but are an interested party in the outcome of the project or simply required for its completion, playing what can be considered a supporting role in the team.

.3 Business Analyst Position

An agile team may have one or more team members with business analysis skills who may or may not have the job title of business analyst. This recognition of cross-skilled team members expands the practice of business analysis beyond that of a single specialist role.
On agile teams, business analysis activities can be performed by one or a combination of:
• a business analyst working on the team,
• the customer representative or product owner, or
• distributing these activities throughout the team.
Refer to the Agile Extension to the BABOK® _Guide _for more details.

.4 Business Analysis Outcomes

In an agile environment, business analysis brings people together and ensures that the right stakeholders are involved with the agile team at the right time. Open communication and collaboration is one of the principal outcomes of successful business analysis in an agile project.

Business analysts ensure that the project’s vision and direction are in strategic alignment to the organizational goals and business need. The business analyst holds shared responsibility in defining strategic criteria for project completion and during the project assists with defining acceptance criteria. They also facilitate the articulation of the product vision statement. The product vision statement is a common initial deliverable.
Documentation rigour and style is highly dependent on the purpose and the context in which it is produced. Agile approaches favour just enough and just-in- time documentation rather than establishing predefined models for documentation to be delivered. This documentation approach allows for the documents to incorporate as much of the change introduced as possible while keeping the cost of change low. Mandatory documentation, such as that required for auditing or compliance reporting, are still produced as part of each delivery cycle. It is important that documents address an identified need and deliver more value than the cost incurred to produce and maintain them.

11.1.3 Approaches and Techniques

.1 Approaches

Agile is an umbrella term for a variety of approaches. All agile approaches practice business analysis but only a few explicitly define the business analysis role. The primary characteristic of any agile approach is its alignment to the values and principles of the Agile Manifesto. An agile team may implement or evolve to use a combination of approaches which enables them to deliver value more effectively given their project type and work environment.

Table 11.1.1: Agile Approaches

Table 11.1.1: Agile Approaches (Continued)

.2 Techniques

The following table lists techniques commonly used within agile approaches. Refer to the Agile Extension to the BABOK® _Guide _for a more detailed description of these techniques.

Table 11.1.2: Techniques used within Agile Approaches

**

Table 11.1.2: Techniques used within Agile Approaches (Continued)

11.1.4 Underlying Competencies
Agile is a mindset. Agile business analysts embody the values and principles of the Agile Manifesto which are based on a humanistic view of product development as a process founded in communication and collaboration. Refer to the Agile Extension to the BABOK® _Guide _for a description of the principles for business
analysts. In adopting the agile mindset and philosophy, the business analyst develops competencies in:
• Communication and collaboration: the ability to communicate the sponsor’s vision and needs; assist in influencing others to support the vision; participate and possibly facilitate negotiation of priorities; and facilitate collaborative agreement on solution outcomes.
• Patience and tolerance: the ability to maintain self-control under pressure and keep an open mind when interacting with others.
• Flexibility and adaptability: cross-functional skill sets that allow the business analyst to step outside their specialization in order to support other team members.
• Ability to handle change: the ability to quickly assess the impact of change and determine what provides business value amongst frequently changing requirements, and assisting with, or maintaining, the re- prioritization of the to-do work list.
• Ability to recognize business value: the ability to understand how changes and new features can achieve business value and support the vision.
• Continuous improvement: periodically review with the agile team how to become more effective.

11.1.5 Impact on Knowledge Areas

This section explains how specific business analysis practices within agile are mapped to business analysis tasks and practices as defined by the BABOK® Guide. It also describes how each knowledge area is applied or modified with the agile discipline.
Each knowledge area lists techniques relevant to an agile perspective. BABOK® Guide _techniques are found in the Techniques chapter of the _BABOK® Guide. Agile Extension techniques are discussed in detail in the Agile Extension to the BABOK® Guide. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.

.1 Business Analysis Planning and Monitoring

In agile approaches, detailed business analysis planning can be deferred until work on an activity is ready to begin rather than done upfront as in predictive projects.
An initial plan for business analysis activities is developed at the beginning of the project. The plan then gets updated prior to the start of each cycle to account for change and to ensure that the plan is always up to date. Stakeholder involvement and engagement is key to the success of agile projects. Business analysts proactively plan to involve, engage, and collaborate with stakeholders.
Communication is commonly much less formal and business analysis deliverables are often interactions and collaboration with less emphasis on the written documents.

BABOK® Guide Techniques

• Backlog Management (p.220)
• Collaborative Games (p.243)
• Estimation (p.271)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Mind Mapping (p.299)

Agile Extension Techniques

• Lightweight Documentation
• MoSCoW Prioritization
• Personas
• Prioritization (p.311)
• Scope Modelling (p.338)
• Stakeholder List, Map, orPersonas(p.344)
• User Stories (p.359)
• Workshops (p.363)

• Relative Estimation
• Retrospective

.2 Elicitation and Collaboration

Progressive elicitation and elaboration occur throughout an agile initiative. The most common pattern is an initial elicitation activity that establishes the high-level vision and scope of the solution, and an initial milestone-based plan for the delivery of the product. In every cycle there is more detailed elicitation for the

backlog items that will be developed in that cycle. The intent of elicitation activities is to generate just enough detail to ensure that the work at hand is performed correctly while aiming towards the goals. Agile approaches aim to minimize the time between the elaboration of needs and their implementation in the solution. There is a strong focus on collaborative elicitation approaches such as workshops with stakeholders.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Backlog Management (p.220)
• Brainstorming (p.227)
• Collaborative Games (p.243)
• Concept Modelling (p.245)
• Interface Analysis (p.287)
• Mind Mapping (p.299)
• Non-Functional RequirementsAnalysis (p.302)

Agile Extension Techniques

• Behaviour Driven Development
• Lightweight Documentation
• Personas
• Process Modelling (p.318)
• Prototyping (p.323)
• Reviews (p.326)
• Scope Modelling (p.338)
• Stakeholder List, Map, orPersonas(p.344)
• Use Cases and Scenarios (p.356)
• User Stories (p.359)
• Workshops (p.363)

• Storyboarding
• Story Mapping

.3 Requirements Life Cycle Management

As agile initiatives unfold, the scope is defined with increasing specificity. The expectation is that the needs will change and that the design will evolve over the course of the project. Prioritization of features based on value and development priority drives the work done in each cycle. Validation of the evolving solution with the stakeholders occurs at the end of every iteration in place of a formal requirements approval process.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Backlog Management (p.220)
• Collaborative Games (p.243)

Agile Extension Techniques

• Kano Analysis
• MoSCoW Prioritization
• Prioritization (p.311)
• Reviews (p.326)
• Workshops (p.363)

• Story Decomposition
• Story Mapping

.4 Strategy Analysis

Agile approaches are often used when there is uncertainty about the needs, the solution, or the scope of change. Strategy analysis is a constant part of an agile initiative to ensure that the solution delivered continues to provide value to stakeholders. Agile team members use strategy analysis to help understand and define product vision, and develop and adjust the development roadmap, in addition to conducting ongoing assessments of related risks. For every iteration, the proposed solution is reassessed against the current business context to ensure that it will effectively meet the business goals. The adaptive nature of agile projects means that adapting the project to changes in the organization’s goals is not disruptive; rather, it is an expected part of the process.

BABOK® Guide Techniques

• Backlog Management (p.220)
• Brainstorming (p.227)
• Business Capability Analysis (p.230)
• Collaborative Games (p.243)

Agile Extension Techniques

• Kano Analysis
• Personas
• Purpose Alignment Model
• Concept Modelling (p.245)
• MetricsandKeyPerformanceIndicators (KPIs) (p.297)
• Scope Modelling (p.338)
• Workshops (p.363)

• Real Options
• Value Stream Analysis

.5 Requirements Analysis and Design Definition

Needs are progressively elaborated during an agile project. Analysis and design are performed on a just-in-time basis, either just before or during the iteration in which the solution component will be developed.
Analysis performed just before the iteration is to provide the team with enough information to estimate the planned work. Analysis performed during the iteration is to provide the team with enough information to construct or deliver the planned work.
Models and other analysis and design techniques are typically used informally, and may not be maintained once they have served their purposes. The analysis and design approach used should support progressive elaboration, be adaptable to change based on learning, and not cause the team to select solutions prematurely. Agile teams tend to use user stories at the lowest level of decomposition, usually supported by acceptance criteria which capture the analysis and design details regarding how the stories should behave when implemented. Validation of the evolving solution is performed with stakeholders at the end of every iteration.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Business Capability Analysis (p.230)
• Business Rules Analysis (p.240)

• Collaborative Games (p.243)
• Concept Modelling (p.245)
• Interface Analysis (p.287)
• Non-Functional RequirementsAnalysis (p.302)
• Prioritization (p.311)

Agile Extension Techniques

• Behaviour Driven Development
• Kano Analysis
• Lightweight Documentation
• MoSCoW Prioritization
• Purpose Alignment Model
• Real Options
• Process Analysis (p.314)
• Process Modelling (p.318)
• Scope Modelling (p.338)
• Use Cases and Scenarios (p.356)
• User Stories (p.359)
• Workshops (p.363)

• Story Decomposition
• Story Elaboration
• Story Mapping
• Storyboarding
• Value Stream Analysis

.6 Solution Evaluation

Throughout an agile project, the stakeholders and agile team continually assess and evaluate the development solution as it is incrementally built and refined. Evaluation of the evolving solution with the stakeholders occurs at the end of every development cycle to ensure the deliverable meets their needs and satisfies their expectations. The business analyst ensures that the product meets expectations before a product is released, and identifies new opportunities that will add value to the business.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Business Capability Analysis (p.230)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Non-Functional RequirementsAnalysis (p.302)
• Process Analysis (p.314)

Agile Extension Techniques

• Personas
• Value Stream Analysis
• Prototyping (p.323)
• Reviews (p.326)
• Stakeholder List, Map, orPersonas(p.344)
• Use Cases and Scenarios (p.356)
• User Stories (p.359)
• Workshops (p.363)

11.1 The Business Intelligence Perspective

The Business Intelligence Perspective highlights the unique characteristics of business analysis when practiced in the context of transforming, integrating, and enhancing data.
The focus of business intelligence is the transformation of data into value-added information: where to source it, how to integrate it, and how to enhance and deliver it as analytic insight to support business decision making.
Business intelligence initiatives apply data-centric system architectures as well as technologies and tools to deliver reliable, consistent, high-quality information that enables stakeholders to better manage strategic, tactical, and operational performance.

11.1.1 Change Scope

.1 Breadth of Change

A key objective of a business intelligence system is the consistent definition and usage of information throughout an organization by establishing a ‘single point of truth’ for diverse business data. A solution architecture that can integrate multiple data sources from within (and potentially from outside) the organization provides the foundation of a business intelligence solution.

Figure 11.2.1: Business Intelligence Solution - Conceptual Framework

**

The business intelligence promotes an enterprise-wide view of information management. To support that conceptual framework, a business intelligence initiative may also involve the development of infrastructure services in the organization, such as data governance and metadata management.

.2 Depth of Change

Business intelligence initiatives focus on the information needed to support decision making at, or across, different levels within the organization:
• executive level: supports strategic decisions,
• management level: supports tactical decisions, or
• process level: supports operational decisions.
Where information needs are initially expressed or identified at a particular level, the business analyst investigates the business implications at other levels to assess the overall impact of the change on the organization.
At each level, the business needs may involve any or all of the following:
• communication requirements for the development of new reporting or the replacement of existing reporting,
• information requirements for the addition or extension of analytic functionality, and/or
• data integration requirements for the construction or modification of the enterprise data view with regard to data sources, definitions, transformation rules and quality issues.

.3 Value and Solutions Delivered

The value of a business intelligence initiative is in its ability to provide timely, accurate, high value, and actionable information to those people and systems who can use it effectively in making business decisions.
Better informed decision making at all levels can lead to improved business performance in:
• strategic processes such as market analysis, customer engagement, and product development,
• tactical processes such as stock control and financial planning, and
• operational processes such as credit assessment, fault detection, and accounts payable monitoring.
These improvements in an organization’s current and future performance may be realized as increased revenues and reduced costs.

.4 Delivery Approach

A business intelligence solution presents a range of delivery options to meet the emerging information needs of stakeholders and the priorities of the organization.

Perspectives The Business Intelligence Perspective

The extensibility and scalability of the solution architecture provide for the support of business decision making to be progressively introduced or enhanced:
• at different levels in the organization, from strategic (senior executive), through tactical (management), to operational (staff and systems), and
• in target functional areas in the organization, from a specific area through to an enterprise-wide implementation.
The infrastructure services that provide data management, analytics, and presentation capabilities, facilitate a phased or incremental development strategy in respect of:
• the inclusion, coordination and control of different data sources, and
• the analysis and development of business information and insights.
Infrastructure components of a business intelligence solution are often provided by a commercial off-the-shelf package configured to the specific business environment and needs.

.5 Major Assumptions

The following is a list of major assumptions of a business intelligence initiative:
• existing business processes and transactional systems can provide source data that is definable and predictable,
• the cross-functional data infrastructure that is needed to support a business intelligence solution has not been precluded by the organization on technical, financial, political/cultural, or other grounds, and
• the organization recognizes that process re-engineering and change management might be needed in order to effectively realize the value from a business intelligence solution.

11.1.2 Business Analysis Scope

.1 Change Sponsor

The change sponsor of a business intelligence initiative is ideally the highest level role from the organizational unit affected by the change. This provides for a consistent, cohesive approach to the shared usage of data assets within the cross- functional architecture of a business intelligence solution.

.2 Change Targets

The targets of a business intelligence initiative are the business decisions made by people or processes at multiple levels in the organization that can be improved by better reporting, monitoring, or predictive modelling of performance-related data.

.3 Business Analyst Position

As in other initiatives, the business analyst acts as the primary liaison between business intelligence stakeholders and solution providers in the elicitation,

analysis, and specification of business needs.
In addition to that role, the business analyst may also participate in technical activities that are specific to business intelligence, including:
• enterprise data modelling,
• decision modelling,
• specialized presentation design (for example, dashboards), and
• ad hoc query design.
A business analyst working on a business intelligence initiative serves in one or in a combination of the following roles:
• business analyst who is competent in the definition of business requirements and the assessment of potential solutions,
• business intelligence functional analyst who has an understanding of data mining and predictive analytic techniques, as well as skills in developing visualizations,
• data analyst who is experienced at defining source systems data to be used for the required analytical purposes, or
• data modeller/architect who is skilled in defining the source and target data structures in logical data models.

.4 Business Analysis Outcomes

In the business intelligence discipline, business analysis is focused on the major components of the solution architecture:
• the specification of business decisions to be influenced or changed,
• the collection of data from source systems,
• the integration of divergent sources into a convergent enterprise framework, and
• the provision of targeted information and analytic insight to business stakeholders.
The business analyst is responsible for the analysis and specification of the business requirements for all of these components and collaborates with technical specialists to assess solution artifacts.
The major outcomes of business analysis are:
• Business process coverage: defines the scope of the change with a high- level overview of the business decisions within the enterprise that are to be supported by the solution. It identifies how the information output will be used and what value it will provide.
• Decision models: identify the information requirements of each business decision to be supported and specify the business rules logic of how the individual information components contribute to the decision outcome.
• Source logical data model and data dictionary: the source logical data model provides a standard definition of the required data as held in each

source system. The source data dictionary provides a definition of each element and the business rules applied to it: business description, type, format and length, legal values, and any inter-dependencies.
• Source data quality assessment: evaluates the completeness, validity, and reliability of the data from source systems. It identifies where further verification and enhancement of source data is required to ensure consistent business definitions and rules apply across the enterprise-wide data asset.
• Target logical data model and data dictionary: the target logical data model presents an integrated, normalized view of the data structures required to support the business domain. The target data dictionary provides the standardized enterprise-wide definition of data elements and integrity rules.
• Transformation rules: map source and target data elements to specify requirements for the decoding/encoding of values and for data correction (error values) and enrichment (missing values) in the transformation process.
• Business analytics requirements: define the information and communication requirements for decision support outputs. These include:
• predefined reports,
• dashboards,
• balanced scorecards,
• ad hoc reports,
• online analytical processing (OLAP) queries,
• data mining,
• prescriptive analytics,
• conditional alerts,
• complex event processing, and
• predictive modelling.
• Specifications for each output can include: (1) data selections/dimensions, level of granularity, filtering criterion applied, possibilities for drill down, slice and dice, and user access and permissions; and (2) presentation rules to define data element format, translation (labels, look-ups), calculations, and data aggregations.
• Solution architecture: provides a high-level design view of how the decision support requirements of each functional area will map to the business intelligence framework. It is typically presented in the form of a process (or data flow) model that defines:
• where the source data is held,
• how (pull/push) and when (frequency, latency) the data will be extracted,

The Business Intelligence Perspective Perspectives

• where the transformations will take place (cleansing, encoding, enhancement),
• where the data will be physically stored (data warehouse, data marts), and
• how the data will flow to presentation outputs (reporting facilities, query tools).

11.1.3 Methodologies and Approaches

.1 Methodologies

There are no formalized business intelligence methodologies that impact the responsibilities and activities of the business analyst. However, a business intelligence initiative can operate within or alongside methodologies applicable to other disciplines or perspectives which themselves might impact the business analysis role.

.2 Approaches

Within the business intelligence framework there are a number of less formal and potentially overlapping approaches that map to particular business and technical contexts.

Types of Analytics

There are three types of data analytics that represent incremental solutions, with increasing levels of systems complexity, cost, and value:
• Descriptive analytics: uses historical data to understand and analyze past business performance. Business information can be categorized and consolidated to best suit the stakeholder’s view including executive management dashboards, middle level management key performance indicator (KPI) scorecards, and operational level management charts. No assumptions are made as to which situations are of interest to the stakeholders, what decisions need to be made, or what actions might be carried out. The business analysis focus is on the information and communication requirements for standard reporting and dashboards, ad hoc reporting, and query functionality.
• Predictive analytics: applies statistical analysis methods to historical data to identify patterns, and then uses that understanding of relationships and trends to make predictions about future events. The particular situations that are of interest to the stakeholders are specified, and their business rules are defined. The business analysis focus is on the information requirements for pattern recognition through data mining, predictive modelling, forecasting, and condition-driven alerts.
• Prescriptive analytics: expands on predictive analytics to identify decisions to be made and to initiate appropriate action to improve business performance. Statistical optimization and simulation techniques can be

used to determine the best solution or outcome among various choices. For situations of interest to stakeholders, full specification of the associated decisions and potential actions are required. The business analysis focus is on the business objectives, constraints criteria, and the business rules that underpin the decision-making process.

Supply and Demand Driven

The objectives and priorities of a business intelligence initiative can be based on the technical goals of improving existing information delivery systems (supply- driven) or on the business goals of providing the appropriate information to improve decision-making processes (demand-driven):
• Supply-driven: assumes the view of “for a given cost, what value can we deliver?”. This approach maps existing systems data to define what data is available. A common implementation strategy would be to:
1. phase the inclusion of existing databases into the business intelligence solution architecture,
2. progressively replace or repair existing outputs, and
3. explore new insights that might be gained from the consolidated data.
• Demand-driven: assumes the view of “for a given value, what cost do we incur?”. This approach starts with identifying the information output needed to support business decisions, and then tracing that information back to the underlying data sources to determine feasibility and cost. It provides for incremental implementation strategies that are not determined by existing database structures, and allows for early exploratory usage of business intelligence beyond existing reporting requirements.

Structured and Unstructured Data

There are two types of data that business intelligence approaches consider:
• Structured data: traditional data warehouse solutions have been based on consolidating the structured data (numerical and categorical) recorded in operational systems where business information sets are identified by predefined structures (referred to as ‘schema on write’) and where a rules- driven template ensures data integrity. The business analysis focus is on data models, data dictionaries, and business rules to define information requirements and capabilities.
• Unstructured data: business intelligence solutions can include semi- structured or unstructured data which includes text, images, audio, and video. This data frequently comes from external sources. For this type of data, the structure and relationships are not predefined and no specific organization rules have been applied to ensure data integrity. Information sets are derived from the raw data (referred to as ‘schema on read’). The business analysis focus is on metadata definitions and data matching algorithms to define information requirements and capabilities.

11.1.4 Underlying Competencies

As in any business analysis discipline, the business analyst requires the fundamental communication and analytical competencies to be effective in liaising with both business stakeholders and technical solution providers.
In the business intelligence discipline, this coordination of business information requirements with business intelligence systems outcomes can be further enhanced by the business analyst’s specific competencies in:
• business data and functional usage, including terminology and rules,
• the analysis of complex data structures and their translation into standardized format,
• business processes affected including KPIs and metrics,
• decision modelling,
• data analysis techniques including basic statistics, data profiling,and pivoting,
• data warehouse and business intelligence concepts and architecture,
• logical and physical data models,
• ETL (Extract, Transform, Load) best practices including historical data track and reference data management, and
• business intelligence reporting tools.

11.1.5 Impact on Knowledge Areas

This section explains how specific business analysis practices within business intelligence are mapped to business analysis tasks and practices as defined by the BABOK® Guide. This section describes how each knowledge area is applied or modified with the business intelligence discipline.
Each knowledge area lists techniques relevant to a business intelligence perspective. Techniques used in the discipline of business intelligence do not deviate, to any great extent, from the BABOK® Guide _techniques. _BABOK® Guide _techniques are found in the Techniques chapter of the _BABOK® Guide. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.

.1 Business Analysis Planning and Monitoring

A business intelligence initiative may require establishing an underlying data infrastructure to support the solution, or it might be an enhancement based on the infrastructure of an existing solution. Scope Modelling is frequently used to differentiate between these alternatives and plan the relevant business analysis activities accordingly.
The business intelligence paradigm of information delivery might be a new,

unfamiliar approach for business stakeholders and for the business analysts themselves. In planning the initiative, the business analyst considers:
• how experienced the stakeholders are in expressing their information and communication requirements in the business intelligence context, and
• how skilled the business analysts are in interpreting those requirements into detailed specifications for business intelligence technical specialists.
Business intelligence solutions typically provide frameworks, tools, and techniques that can assist in requirements definition and solution modelling. The level of stakeholders’ and business analysts’ expertise in these can have an impact on the planned approach.
When assessing stakeholder attitudes towards the business intelligence initiative, the business analyst should be aware that an enterprise-wide business intelligence solution might not provide direct value to some operational stakeholders, but will deliver it elsewhere in the organization, and the flexibility and extensibility provided by the business intelligence infrastructure delivers longer-term strategic value that goes beyond short-term operational benefits.
A business intelligence solution that integrates multiple data sources typically engages many stakeholders with overlapping information requirements. Business analysts prepare for the analysis and synthesis of individual requirements into a set that is complete and cohesive without conflicts and redundancies.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Balanced Scorecard (p.223)
• Brainstorming (p.227)
• Decision Analysis (p.261)
• Estimation (p.271)
• Functional Decomposition (p.283)
• Interviews (p.290)
• ItemTracking(p.294)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Non-Functional RequirementsAnalysis (p.302)
• Organizational Modelling (p.308)
• Prioritization (p.311)
• Process Modelling (p.318)
• Reviews (p.326)
• Risk Analysis and Management(p.329)
• RolesandPermissionsMatrix(p.333)
• Root Cause Analysis (p.335)
• Scope Modelling (p.338)
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p.350)
• Use Cases and Scenarios (p. 356)
• User Stories (p.359)
• Workshops (p.363)

.2 Elicitation and Collaboration

The cross-functional nature of business intelligence typically requires business analysts to employ specialized documentation tools and techniques to elicit particular types of requirements from stakeholders, both business and technical.
Individual stakeholders may only possess partial knowledge and expertise regarding:
• the business decisions that need support,
• the data elements that support those business decisions,
• the data sourcing, transformation, and integration rules, and
• the presentation of the required information.
Interviews with individual stakeholders identify the information and analytic insight required to support their decision making. Workshops with stakeholders from across different functional areas of the business can help detect common, overlapping information requirements that would be better met with an integrated solution.
Data models and data dictionaries provide definitions of the structure and business rules of existing systems data. The business analyst assesses available documentation to identify incompleteness of a model or inconsistencies between models.
Process models that are extended to include data artifacts can help identify the data sources required at decision points. Decision models specify the data analytic requirements and business rules for decisions.
Commercial off-the-shelf packages of business intelligence functionality can provide the business analyst with a set of highly effective prototyping tools to elicit and clarify stakeholder information and communication requirements.

BABOK® Guide Techniques

• Brainstorming (p.227)
• Document Analysis (p.269)
• Focus Groups (p.279)
• Functional Decomposition (p.283)
• Glossary (p.286)
• Interface Analysis (p.287)
• Interviews (p.290)
• ItemTracking(p.294)
• Observation (p.305)
• Prototyping (p.323)
• Workshops (p.363)
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p.350)

.3 Requirements Life Cycle Management

The architectural nature of the business intelligence discipline requires establishing the infrastructure capabilities in the solution. This can introduce structural dependencies within the solution, particularly where delivery is phased,

that affect the prioritization of individual business needs. It is often possible to achieve efficiencies by implementing related requirements at the same time.

BABOK® Guide Techniques

• ItemTracking(p.294)
• Organizational Modelling (p.308)
• Prioritization (p.311)
• Reviews (p.326)
• RolesandPermissionsMatrix(p.333)
• Stakeholder List, Map, orPersonas(p.344)
• Workshops (p.363)

.4 Strategy Analysis

Business analysts can use high-level conceptual data models to map the current state of corporate information, to identify information silos, and to assess their related problems and opportunities. Organization Modelling can be used to evaluate any current data management infrastructure, such as metadata management and data governance.
In defining the future state strategy, business analysts can use high-level models to map the architecture for data storage and for data conveyance and transformation:
• Logical data models: provide a static view of the solution architecture, representing the information portal that connects the sourcing of operational data inputs with the delivery of the business information outputs.
• Data flow diagrams: are commonly used to map the dynamic aspects of the solution (data-in-motion) and to identify other architectural constructs such as latency and accessibility.
• Decision models: are useful for defining how relevant business decisions are made and where and how data analytics can be effectively used to meet these needs.
• Physical data models: show the implementation environment including the data warehouse and data marts.
The extensible architecture provided by business intelligence solutions can support incremental implementation across different functional areas of the business. Business analysts can define change strategy options based on business needs and priorities, impact on the business operations, and the usability of existing infrastructure components.

BABOK® Guide Techniques

• Backlog Management (p.220)
• Benchmarking and MarketAnalysis(p.226)
• Brainstorming (p.227)
• Business Rules Analysis (p.240)
• Data Flow Diagrams (p.250)
• Data Modelling (p.256)
• Decision Analysis (p.261)

The Business Intelligence Perspective Perspectives

• Decision Modelling (p.265)
• Document Analysis (p.269)
• Estimation (p.271)
• Focus Groups (p.279)
• Functional Decomposition (p.283)
• Glossary (p.286)
• Organizational Modelling (p. 308)
• Risk Analysis and Management(p. 329)
• Root Cause Analysis (p. 335)
• Stakeholder List, Map, or Personas(p. 344)
• SWOT Analysis (p. 353)

.5 Requirements Analysis and Design Definition

When modelling and specifying back office data capture and storage requirements, business analysts use specific data-oriented modelling techniques such as Data Modelling, Data Dictionary, Decision Modelling, and Business Rules Analysis.
Models of an existing system’s data help to define data availability and identify redundancies, inconsistencies, and data quality issues. Where existing systems documentation is non-existent or out of date, reverse-engineered modelling can be a substantial component of work, and frequently requires collaboration with technical experts such as database administrators and application programmers.
A future state data model demonstrates how the source information is generically structured in the proposed solution. The overall transformation process is commonly modelled using Data Flow Diagrams to illustrate the management of latency and accessibility requirements in the solution. Business analysts define specific business rules for data integrity checking and for data transformation.
For modelling and specifying front office information outputs, business analysts:
• analyze existing reports to determine if they are candidates to be replaced or repaired with business intelligence outputs, and
• use business intelligence capabilities such as ad hoc queries, data mining, and complex event processing to identify and specify the content and format of new business intelligence outputs.
Business analysts are involved in assessing the capability of a proposed solution (typically a commercial off-the-shelf software package) in respect of the specified requirements. In the business intelligence context, these include functional requirements such as self-serve facilities, data analytics tools, data presentation tools, drill down capabilities, and non-functional requirements related to issues such as data quality, data latency, and query performance.

.6 BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Balanced Scorecard (p. 223)
• Business Rules Analysis (p. 240)
• Data Dictionary (p. 247)
• Data Flow Diagrams (p. 250)
• Data Modelling (p. 256)
• Decision Modelling (p. 265)

• Document Analysis (p. 269)
• Functional Decomposition (p.283)
• Glossary (p. 286)
• Interface Analysis (p. 287)
• Interviews (p. 290)
• Metrics and Key PerformanceIndicators (KPIs) (p. 297)
• Non-Functional RequirementsAnalysis (p. 302)
• Observation (p. 305)
• Organizational Modelling (p. 308)
• Prioritization (p. 311)
• Process Modelling (p. 318)
• Prototyping (p. 323)
• Reviews (p. 326)
• Scope Modelling (p. 338)
• Sequence Diagrams (p. 341)
• Stakeholder List, Map, or Personas(p. 344)
• State Modelling (p. 348)
• Use Cases and Scenarios (p. 356)
• Vendor Assessment (p. 361)

.7 Solution Evaluation

A common enterprise limitation with the introduction of a business intelligence solution is the under-utilization of the information resource and analytic functionality that the solution provides. Stakeholders who are not familiar with the capabilities of business intelligence might focus on simply replacing or repairing existing information outputs. Business analysts explore and evaluate opportunities for additional value that are enabled by a business intelligence solution.

.8 BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Balanced Scorecard (p. 223)
• Business Rules Analysis (p. 240)
• Data Flow Diagrams (p. 250)
• Data Modelling (p. 256)
• Decision Analysis (p. 261)
• Decision Modelling (p. 265)
• Estimation (p. 271)
• Focus Groups (p. 279)
• Functional Decomposition (p. 283)
• Glossary (p. 286)
• Interviews (p. 290)
• Item Tracking (p. 294)
• Metrics and Key PerformanceIndicators (KPIs) (p. 297)
• Observation (p. 305)
• Organizational Modelling (p. 308)
• Prioritization (p. 311)
• Process Modelling (p. 318)
• Risk Analysis and Management(p.329)
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p. 350)
• SWOT Analysis (p. 353)
• Use Cases and Scenarios (p. 356)
• User Stories (p. 359)
• Vendor Assessment (p. 361)

11.2 The Information Technology Perspective

The Information Technology Perspective highlights the characteristics of business analysis when undertaken from the point of view of the impact of the change on information technology systems.

This perspective focuses on non- agile approaches to IT initiatives.

For information regarding agile approaches within information technology initiatives, see The Agile Perspective (p.368).
When working in the information technology (IT) discipline, business analysts deal with a wide range of complexity and scope of activities. Initiatives may be as small as minor bug fixes and enhancements, or as large as re-engineering the entire information technology infrastructure for an extended enterprise. Business analysts are called upon to work with this diverse level of knowledge and skills among stakeholders to deliver valuable solutions to their IT needs.
Being able to effectively articulate the business’ vision and needs to technical stakeholders is central to the success of a business analyst in the information technology discipline. Business analysts proactively collaborate with both the business stakeholders and development teams to ensure that needs are understood and aligned with organizational strategy. A business analyst frequently plays the role of the translator who helps business and technology stakeholders understand each other’s needs, constraints, and context. The concept of solution design is appropriate in a technology context, and from the IT business analyst’s point of view. However, the term ‘design’, when discussed within an IT setting, is generally assumed to mean ‘technical design’ or the utilization of technologies to solve business problems. Business analysts within an IT context define and elaborate solution requirements or participate in solution design with business stakeholders while maintaining a separation with technical design.

Important In IT contexts, the term ‘design’ has traditionally been reserved for solution or technical design performed by developers, IT architects, or solution architects. All work done by IT business analysts is covered by the term ‘requirements’, including concepts such as the definition and design of business processes, user interfaces, reports or other elements of the solution relevant to stakeholders outside of the implementation team. Business analysts working in this context may prefer the term ‘solution requirements’ instead of ‘design’ in order to maintain a clear separation of responsibility.
Business analysts working in an information technology environment consider their tasks in light of three key factors:
• Solution impact: the value and risk of the solution to the business.
• Organizational maturity: the formality and flexibility of the organizational change processes.
• Change scope: the breadth, depth, complexity, and context for the proposed change.

11.2.1 Change Scope

Changes to IT systems are initiated for several reasons. Each of the following triggers can lead to an IT change:

• Create a new organizational capability: can be executed to transform the organization. These types of IT initiatives may drive the creation of larger programs to address non-IT changes, but are centered on a technology that alters the business environment.
• Achieve an organizational objective by enhancing an existing capability: is part of a change that meets a defined need. This may include changes to meet regulatory requirements or to enable business specific goals. These types of initiatives often modify an existing system but may also require implementation and integration of new systems.
• Facilitate an operational improvement: is undertaken to improve organizational efficiency or reduce organizational risk. The change scope, organizational maturity, and solution impact dictate whether these changes will be managed as a project, part of a continuous improvement effort, or as an enhancement.
• Maintain an existing information technology system: is undertaken to ensure smooth operation of an existing IT system. Depending on the scope of the change, maintenance may be managed as a project or a regularly scheduled activity. This may include technology driven changes such as a vendor discontinuing support of a technology, scheduled releases or upgrades to a purchased software package, or technical modifications required to support architecture strategy.
• Repair a broken information technology system: is undertaken when an IT system that is not performing as expected is changed to correct the dysfunction. The urgency of the repair is generally based on the level of disruption caused. In some cases the scope of the repair effort is very large, so the repair is managed as a project.

.1 Breadth of Change

Information technology initiatives may focus on a single system or on multiple systems which interact with each other. Some systems are developed and maintained in-house while others are commercial off-the-shelf (COTS) systems developed by an organization that is external to the group implementing the system. It is also possible that an external organization completes custom development, such as when development tasks are outsourced or contracted.
The scope of an IT initiative is often narrowly focused on software and hardware and a minimal set of systems, applications, or stakeholders. Larger initiatives may impact multiple user groups or systems, and often require collaboration with the extended enterprise. The implementation of COTS information technology systems may begin with a small or limited scope when the change is initiated, but after analysis is complete the scope is broader than originally anticipated. The business analysis approach for a COTS selection and implementation is approached differently than in-house development. These IT systems almost always require customization, integration, administration, and training. In some cases, the initiatives are limited to initial installation and implementation, or enhancements to an existing application. IT initiatives may also focus on a very specific technology solution such as what data is needed, how data is gathered,

how it is stored and accessed in order to support business transaction methods, or how information is reported and available to the business groups.
Business analysts working in IT carefully consider the context for any information technology change. They consider whether the change is managed as a project, a continuous improvement, or a maintenance activity. Business analysts also consider organizational change management and all impacts including training, communications, and adoption of the change.
The nature of business analysis activities in an IT environment depend on a variety of solution impact factors:
• What happens to the business if this system shuts down?
• What happens if the system performance degrades?
• What business capabilities and processes depend on the IT system?
• Who contributes to those capabilities and processes?
• Who uses those capabilities and processes?
When considering these solution impact factors, not only do business analysts match the formality of analysis activities to the business analysis processes defined by the organization, but also consider the importance of the IT system. The importance of the system under analysis may indicate that more analysis is needed to support and define the requirements for the change.

.2 Depth of Change

Changes in an IT environment frequently require the business analyst to define explicit details, including technical details such as the definition of individual data elements being manipulated or impacted by the change. Integration efforts can require analysis and definition at a great level of detail while identifying and defining the interfaces between IT systems. Due to the level of detail required in these types of initiatives, business analysts elicit and analyze how the organization works as a whole and how the IT system will support those operations. This provides the necessary context for the business analyst to understand whether the details being discovered and documented are relevant to delivering value. This can be particularly challenging when an IT system change is initiated for technology driven reasons but without sufficient clarity or alignment to business purpose.

.3 Value and Solutions Delivered

Information technology systems are implemented to increase organizational value, which includes any support capabilities and processes that use the system. Business analysts seek to align IT functionality to these processes and capabilities, and to measure the effect that the system has on them.
Changes to IT systems can increase value many ways, including:
• reducing operating costs,
• decreasing wasted effort,

• increasing strategic alignment,
• increasing reliability and stability,
• automating error-prone or manual processes,
• repairing problems,
• making it possible to scale up, enhance, or make more readily available a business capability, and
• implementing new functionality and new capabilities.

.4 Delivery Approach

The delivery of business analysis activities within an IT organization varies greatly. Initiatives may range from small enhancement efforts which are completed with a single, short time frame release schedule to multi-release, phased implementations.
Short time frame initiatives may involve a single business analyst for a short period of time. Larger efforts frequently involve several business analysts who may coordinate analysis activities in several ways. Business analysts may divide work based on business group involved or by specific activity.

.5 Major Assumptions

The following is a list of major assumptions of the IT discipline:
• business capabilities and processes that use an IT system are delivering value to the organization,
• business analysts working from other perspectives can integrate their work with the work of the IT business analysts, and
• IT systems changes are usually driven by a business need, although some initiatives may originate from within technology developments.

11.2.2 Business Analysis Scope

.1 Change Sponsor

Information technology changes may be requested or sponsored by business sponsors, IT departments, or as a collaboration between the two. These changes should align to organizational strategy and business goals. It is possible for an IT department to initiate change to align with technical strategy or reach technical goals, but an overall organizational strategy alignment is still crucial for change success.
The following list represents possible change sponsors:
• technical team,
• technical executive,
• application owner,

The Information Technology Perspective Perspectives

• process owner,
• business owner,
• internal product manager, and
• regulatory representative (such as a corporate legal department).
Enterprises may use many methods to initiate changes related to information technology. Frequently, large enterprises define a program or project management office within the IT department, which intakes requests and prioritizes efforts on behalf of the department.

.2 Change Targets

Business analysts identify all possible departments, processes, applications, and functions which can be impacted by the proposed change. A business analyst not only focuses on details of the initiative, but also keeps an eye on the larger picture and the potential impact (both business and technical) of the change. This involves a level of process and functional analysis with specific focus on both technical interfaces as well as process hand-offs.

.3 Business Analyst Position

Within an IT initiative, the business analysis activities may be filled by personnel with one of several types of backgrounds or job titles within the organization. This assignment may be dependent upon the type of change, the level of experience, knowledge needed, or simply the personnel available to staff the effort. The personnel may be assigned to the business analysis tasks due to the experience described below, and may complete some or all of the business analysis responsibilities for a given change.
It is possible that all business analysis tasks for an IT project may be completed by a person with only one of these backgrounds:
• a business analyst who works specifically with the business users of an IT system,
• an IT business analyst who is the designated liaison between the technical team and the business group which uses the application,
• a subject matter expert (SME) experienced with the current software implementation,
• a software user experienced with the daily activity of how the software is used and can focus on usability,
• a systems analyst who has experience within the business domain, but does not have experience with the specific application,
• a business process owner who has a depth of experience with the business capabilities or processes, but may not have any technical or IT experience,
• a technical person with a depth of technical experience, or

• a COTS representative who will allow for customized implementations of a packaged solution, and leverage the knowledge of the vendor’s package and past implementation experience.

.4 Business Analysis Outcomes

Within an IT initiative, a business analyst may consider business processes impacted by the change, as well as the data and business intelligence information collected by the system. Business analysts working in the initiative thoroughly plan the business analysis effort and the deliverables that support the change effort.
The change approach being utilized has a direct impact on business analysis deliverables or outcomes. Many organizations have a defined system or solution development methodology which, to some extent, dictates the deliverables which are required at each project milestone. Even within the context of this structure the business analyst may seek to complete additional deliverables beyond those required by the change approach or organization specific process, and employ techniques which support the comprehensive understanding of the change effort needed.
Business analysts working in the IT discipline are responsible for delivering any of the following:
• defined, complete, testable, prioritized, and verified requirements,
• analysis of alternatives,
• business rules,
• gap analysis,
• functional decomposition,
• use cases and scenarios, and/or user stories as appropriate,
• interface analysis,
• prototypes,
• process analysis,
• process models,
• state models,
• decision models,
• context models or scope models, and
• data models.
Additional deliverables not included in the above list but relating to any of the outputs of business analysis techniques used may also be considered deliverables of the business analyst.

11.2.3 Methodologies

The methodologies followed by information technology organizations vary widely.
In general, solution development methodologies fall into two generic approaches:
• Predictive: structured processes which emphasize planning and formal documentation of the processes used to complete the change. Each phase of the process or sequence is completed before advancing to the next phase.
• Adaptive: processes which allow for reworking within one or more of the overall structured process cycles. Most adaptive models are both iterative and incremental, focusing on growing the product in both breadth and depth.
A hybrid methodology may also be utilized. A hybrid may include an overall vision for the whole initiative (as in predictive), as well as a definition of details within individual cycles or iterations (as in adaptive).
The following table identifies several established methodologies or approaches that a business analyst practicing in an information technology environment may encounter.

Table 11.3.1: Information Technology Methodologies

11.2.4 Underlying Competencies
A business analyst working within IT may possess skills related to IT development such as programming, creating a database, creating a system or solution

architecture, software testing experience, or other technical skills. However, development-related skills or technical skills are not necessary for a business analyst to be successful within an IT environment. It is important for the business analyst to have a strong understanding of the detail required within a requirements package to support technical solutions, as well as an understanding of what is technically feasible within the constraints of an organization’s technical architecture. These skills will enable a business analyst to work with all stakeholders to design a business solution framework which will also allow the technical team the flexibility to design a technical solution.
Business analysts use influencing and facilitation skills when working with stakeholders. Negotiation skills are frequently used when working with business and technical staff to come to agreements and decisions if the costs of a solution (either in budget, time, or architectural impact) conflict with the desired business outcome.
Systems thinking is a crucial competency for business analysts practicing in an IT environment. Systems thinking supports the ability of the business analyst to see the larger picture including any other applications or technical aspects which may be impacted, the details of the specific need, and possible technical solutions.
Systems thinking also supports the ability to identify impacts to people, processes, and software which are not necessarily directly changed as part of an IT development effort, and to analyze the risks and possible outcomes of those impacts.

11.2.5 Impact on Knowledge Areas

This section explains how specific business analysis practices within information technology are mapped to business analysis tasks and practices as defined by the BABOK® Guide. It also describes how each knowledge area is applied or modified within the IT discipline.
Each knowledge area lists techniques relevant to an IT perspective. Techniques used in the discipline of information technology do not deviate, to any great extent, from the BABOK® Guide _techniques. _BABOK® Guide _techniques are found in the Techniques chapter of the _BABOK® Guide. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.

.1 Business Analysis Planning and Monitoring

A business analysis approach is a fundamental communication tool which can be used to identify resources required for business analysis work and ensure adequate time for the analysis effort. A well-defined business analysis plan integrates into the overall project plan and provides business analysts with the opportunity to define and schedule the business analysis activities for the project.
Many organizations have some standards and processes in place, which may identify certain analysis tasks and deliverables. If these are not in place, the business analyst identifies these tasks and deliverables based on the needs of the specific initiative.

It is important that the context of the analysis work is understood. This includes understanding the inter-operation of software systems, business processes, and the data that is passed from one system to the next. Changes to any single system or process may have a ripple effect that brings additional systems, processes, or stakeholder groups into the scope of the initiative.
The IT business analyst may be embedded within a software team. This approach allows the business analyst to become quite knowledgeable about specific software or processes supported by the software. Stakeholder attitudes and needs may change or shift in regards to each particular change. Roles, collaboration, and communication plans are planned for every change effort.
COTS solutions can involve major systems integration efforts, customizations, and many unexpected tasks due to the introduction of external software. When planning for unknown impacts and unknown customization needs, business analysts engage both internal stakeholders who understand the needs of the change, and external stakeholders who have expertise with the COTS solution being implemented.

BABOK® Guide Techniques

• Backlog Management (p.220)
• Document Analysis (p.269)
• Estimation (p.271)
• Functional Decomposition (p.283)
• ItemTracking(p.294)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Organizational Modelling (p. 308)
• Roles and Permissions Matrix(p. 333)
• Scope Modelling (p. 338)
• Stakeholder List, Map, or Personas(p. 344)

.2 Elicitation and Collaboration

Information technology changes frequently affect many stakeholders with distinct relationships to the solution or change. When a change involves an IT application or system, the technical staff may have expertise, perspectives, or experience that can identify additional impacts to systems or processes as requirements and solutions are defined. For this reason, it is beneficial to have at least one elicitation session with IT technical personnel, such as development or technical design staff, and business SMEs in the same room at the same time. This type of elicitation approach provides a platform for collaboration between technical and business teams, where the IT business analyst serves as a facilitator and liaison for the process.
Business analysts practicing in an IT environment may utilize any of the techniques identified in the Elicitation and Collaborationknowledge area. Additionally, the following methods can be of great benefit in the information technology discipline:
• Investigation: using organizational process assets, market research, competitive analysis, functional specifications, and observation,

• Simulations: using statistical modelling and mock-ups, and
• Experimentation: using proofs of concept, prototypes, alpha- and beta- releases, and A/B testing.
Information technology changes can be seen as a distraction or cost by business stakeholders if the change is not perceived as mission critical or if the stakeholder is experiencing negative value from the change. This can make engagement for elicitation challenging. Elicitation across organizational boundaries may be impeded, causing collaboration breakdowns and rework. IT business analysts can decrease the risk of rework by engaging information technology and business resources in collaboration activities.

BABOK® Guide Techniques

• Brainstorming (p. 227)
• Collaborative Games (p. 243)
• Document Analysis (p. 269)
• Focus Groups (p. 279)
• Interface Analysis (p. 287)
• Interviews (p. 290)
• Observation (p. 305)
• Process Modelling (p. 318)
• Prototyping (p.323)
• Scope Modelling (p.338)
• Sequence Diagrams (p.341)
• Stakeholder List, Map, orPersonas(p.344)
• State Modelling (p.348)
• Survey or Questionnaire (p.350)
• Use Cases and Scenarios (p.356)
• Workshops (p.363)

.3 Requirements Life Cycle Management

IT initiatives frequently experience major discoveries while creating the change. It is through exploration that the business analysts discover the implications of the new functionality provided by the solution. This sense of discovery in IT environments has led to the adaptation of short cycle times (agile and continuous improvement), rigorous change control (Capability Maturity Model Integration (CMMI) and predictive), and externalized information technology (Software as a Service (SaaS) and cloud services).
Business analysts working in IT pay particular attention to alignment, approval, change control, traceability, and requirements life cycle management tools. It is the role of the business analyst to work with stakeholders to develop a consistent method for reviewing evolving requirements to ensure alignment with the business objectives for the initiative.
In many cases, changes to approved requirements are driven by changes to higher-level requirements such as business objectives. Business analysts collaborate with stakeholders to ensure these requirements are stable before proceeding to solution or technical requirements. When changes to requirements are presented, the business analyst analyzes the impact and plans how to manage proposed changes.
As the complexity of an information technology environment grows, it becomes increasingly important to track each change to each requirement or between

requirements and other information. Traceability that includes dependencies and relationships among requirements makes it easier for stakeholders to understand what is changing about the IT system and predict impacts of additional changes.
As technical systems are changed over time, it is helpful when each version of each requirement is stored in some way and accounted for. Traceability makes it possible to find the source and owner of each requested function and feature, as well as why, when, and how it changed over time. This history is important for ensuring that the requirements are complete and that the approval of requirements is a sensible decision. When the change–work and the IT system are audited, regulators and other interested parties can understand what happened, when, and why. This can be especially important for audit purposes, when an application manages data or processes systematically without human intervention for each transaction or instance of the process occurring. This tracing also helps the organization understand why some functionality is not delivered or implemented in the IT system, and why it was dropped from the scope of this implementation.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Decision Analysis (p.261)
• ItemTracking(p.294)
• Metrics and Key PerformanceIndicators (KPIs) (p. 297)
• Prioritization (p. 311)

.4 Strategy Analysis

Within an IT organization, strategy analysis focuses on the technologies and systems, business units, business processes, and business strategies impacted by a proposed change. It is possible that the impacts of a change cause a ripple effect through other systems in the organization. In order to analyze needs and proposed changes, business analysts seek to understand all the various aspects that may be impacted by the change.
Current state analysis within IT initiatives includes analysis of manual processes, understanding what the system or technology currently does, the data needed to complete tasks, and the other systems and processes that interact with the system. Business analysts plan for a thorough understanding of the current state and a large context of the enterprise at first, with the understanding that the scope will narrow as the future state is identified.
Once the current state is understood, the desired future state is described. This may be process or capability related and usually includes how current system functionality is required to change in order to support the future vision and meet the objectives of both individual stakeholders and the enterprise. In understanding both the current and future states, the gap between the two is identified, and that is where the direction of the change effort can be set. It is at this point of analysis that solution options are explored.
Once the aspects of the change scope and desired future state are understood, business analysts assess uncertainty and risk. Uncertainty is clarified by:

• identifying and defining risks,
• identifying and defining potential benefits,
• establishing parameters for variance in known processes and operations, and
• exploring the unknown.
Business analysts also explore other potential risks including:
• vendor risks, such as their business and product stability,
• impacts to the system’s technical environment,
• scalability of the solution should volumes of transactions or users increase over time, and
• additional process or system changes required based on the change initiated.

BABOK® Guide Techniques

• Business Capability Analysis (p. 230)
• Focus Groups (p. 279)
• Functional Decomposition (p. 283)
• Interviews (p. 290)
• Item Tracking (p. 294)
• Observation (p. 305)
• Process Analysis (p. 314)
• Process Modelling (p.318)
• Scope Modelling (p.338)
• Survey or Questionnaire (p.350)
• SWOT Analysis (p.353)
• VendorAssessment (p.361)
• Workshops (p.363)

.5 Requirements Analysis and Design Definition

It is important for business analysts working in IT to understand and clarify the term ‘design’. Many IT organizations think of design only as it applies to the design or blueprint of a software or technical change. Within the Requirements Analysis and Design Definitionknowledge area, the term design is viewed more broadly and from the business analyst’s point of view. Designs are usable representations that focus on the solution and understanding how value might be realized by a solution if it is built. For example, a model of a potential process improvement (whether it impacts or utilizes an IT system or not), as well as user interface layouts or report definitions, can all be considered designs.
Business analysts elaborate business and technical requirements, break down and define stakeholder needs, and identify the value to be realized by stakeholders once a technical solution or change is implemented. They elicit, define, and analyze business and stakeholder requirements, and also define, analyze, and model solution designs. They define requirements to a level of technical detail that will be used as part of solution design and input into technical designs. This elaboration will include both functional requirements and non-functional

requirements. For some change initiatives, the definition of non-functional requirements could define all business goals for the change effort.
Business analysts often rely on other change agents to produce technical designs for software solutions. A systems architect, programmer, database manager, or other technical expert is often needed to determine how to use technology to satisfy a set of requirements. IT business analysts define process steps, business rules, screen flows, and report layouts. Defining requirements to include detailed functionality of a system, the business, and system processes is a crucial part of solution design and does not separate analysis and design.
As part of requirements analysis, an IT business analyst may partner with another business analyst with a different focus, such as an enterprise business analyst or business architect, to ensure that the IT requirements align to business or organizational strategy.
Requirements analysis and design definition frequently involves documenting requirements using words and pictures. In some cases, requirements may be represented in other ways such as a proof of concept, working software prototypes, or simulations. In all cases, the business analyst works to produce documentation with sufficient and appropriate details for:
• the business to verify and validate the requirements,
• the developers to design from, and
• the testers to measure the solution against before it is implemented into a production environment.

BABOK® Guide Techniques

• Business Rules Analysis (p.240)
• Data Dictionary (p.247)
• Data Flow Diagrams (p.250)
• Data Modelling (p.256)
• Decision Analysis (p.261)
• Decision Modelling (p.265)
• Document Analysis (p.269)
• Estimation (p.271)
• Functional Decomposition (p.283)
• Glossary (p.286)
• Interface Analysis (p.287)
• Non-Functional RequirementsAnalysis (p.302)
• Organizational Modelling (p.308)
• Process Modelling (p.318)
• Prototyping (p.323)
• Reviews (p.326)
• RolesandPermissionsMatrix(p.333)
• Scope Modelling (p.338)
• Sequence Diagrams (p.341)
• State Modelling (p.348)
• Use Cases and Scenarios (p.356)
• User Stories (p.359)

.6 Solution Evaluation

Solution evaluation focuses on solution components and the value they provide. Within an IT context, this includes a focus on the interactions between multiple

systems within the change and the surrounding environment. It is important for a business analyst working in the IT discipline to understand the context of the solution and how changes within one system or process can impact other systems within the environment. These impacts can add negative or positive value to the other systems, therefore impacting the overall realization of value for the change.
One aspect of solution evaluation within an IT context is software testing or solution testing. Testing or quality assurance ensures that the solution performs as anticipated or designed, and that it meets the needs of the business or stakeholders who requested the change effort. The business analyst works with quality assurance (testers) to ensure that technical solutions will meet the business needs as defined by the requirements and other business analysis deliverables. Testers utilize testing methodologies to plan, develop, and execute tests. This aspect of solution testing generally focuses on complete process testing, including across systems to ensure end-to-end solution quality and accuracy. Business analysts work with stakeholders to plan, develop, and execute user acceptance tests to ensure that the solution meets their needs.
Business analysts make themselves aware of the rationale for implementing an IT solution and how that rationale works to create solution value. This value realization is commonly associated with better support for business processes and procedures.
Business and technical objectives are associated with benefits and value realization which are measured against defined metrics used to evaluate success. Requirements should trace back to the objectives, and this traceability provides a foundation for solution evaluation. The analysis of solution performance focuses on technical systems and how they provide potential and actual value to stakeholders.
Where a large organizational change contains an IT element, an IT solution evaluation can contribute to a broader benefits realization activity associated with the whole change program.
As part of solution evaluation activities, a business analyst may work with a team to complete tasks, such as assessing solution limitations and assessing the impacts of such limitations. The business analyst may support and assess technical testing efforts for all, or a portion of, the developed solution.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Decision Analysis (p.261)
• Estimation (p.271)
• ItemTracking(p.294)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Organizational Modelling (p.308)
• Risk Analysis and Management(p.329)
• Process Modelling (p.318)
• SWOT Analysis (p.353)
• VendorAssessment (p.361)

11.3 The Business Architecture Perspective

The Business Architecture Perspective highlights the unique characteristics of business analysis when practiced in the context of business architecture.
Business architecture models the enterprise in order to show how strategic concerns of key stakeholders are met and to support ongoing business transformation efforts.
Business architecture provides architectural descriptions and views, referred to as blueprints, to provide a common understanding of the organization for the purpose of aligning strategic objectives with tactical demands. The discipline of business architecture applies analytical thinking and architectural principles to the enterprise level. The solutions may include changes in the business model, operating model, organizational structure, or drive other initiatives.
Business architecture follows certain fundamental architectural principles:
• Scope: the scope of business architecture is the entire enterprise. It is not a single project, initiative, process, or piece of information. It puts projects, processes, and information into the larger business context to provide an understanding of interactions, integration opportunities, redundancies, and inconsistencies.
• Separation of concerns: business architecture separates concerns within its context. It specifically separates what the business does from:
• the information the business uses,
• how the business is performed,
• who does it and where in the enterprise it is done,
• when it is done,
• why it is done, and
• how well it is done.
Once the independent concerns are identified, they can be grouped in specific combinations or mappings, which can be used to analyze targeted business issues.
• Scenario driven: there are many different questions that a business tries to answer to provide the blueprint for alignment. Each of these different questions or business scenarios requires a different set of blueprints containing a different set of information and relationships, with different types of outcomes and measures to determine success.
• Knowledge based: while the primary goal of business architecture is to answer these business questions, a secondary but important goal is to collect and catalogue the different architectural components (what, how, who, why, etc.) and their relationships in a knowledge base so they can quickly and easily be used to help answer the next business question that comes up. The knowledge base is often managed in a formal architectural repository.

11.3.1 Change Scope

.1 Breadth of Change

Business architecture may be performed:
• across the enterprise as a whole,
• across a single line of business within the enterprise (defining the architecture of one of the enterprise’s business models), or
• across a single functional division.
Business architecture activities are generally performed with a view of the entire enterprise in mind, but may also be performed for an autonomous business unit within the enterprise. A broad scope is required to manage consistency and integration at the enterprise level. For example, business architecture can clarify a situation where the same business capability is implemented by multiple different processes and multiple different organizations using different information models. Given the clarity that comes from an enterprise scope, the business can then determine if this structure is the best way to align with strategic objectives.

.2 Depth of Change

A business architecture effort may focus on the executive level of the enterprise to support strategic decision making, or on the management level to support the execution of initiatives.
While business architecture provides important context, it does not usually operate at the operational decision or process level; instead, it assesses processes at the level of the value stream.

.3 Value and Solutions Delivered

Business architecture, using the principle of separation of concerns, develops models that decompose the business system, solution, or organization into individual elements with specific functions and shows the interactions between them.
The elements of business architecture models include:
• capabilities,
• value,
• processes,
• information and data,
• organization,
• reporting and management,
• stakeholders,
• security strategies, and
• outcomes.

Architecture models enable organizations to see the big picture of the domain that is under analysis. They provide insights into the important elements of the organization or software system and how they fit together, and highlight the critical components or capabilities.
The insights provided by business architecture help keep systems and operations functioning in a coherent and useful manner, and add clarity to business decisions. When change is being considered, the architecture provides details on the elements that are most relevant for the purposes of the change, allowing for prioritization and resource allocation. Because an architectural model also shows how the parts are related, it can be used to provide impact analysis to tell what other elements of the system or the business might be affected by the change.
The architecture itself can be used as a tool to help identify needed changes. The performance metrics for each element of the architecture can be monitored and assessed to identify when an element is under-performing. The importance of each element can be compared with the performance of the organization or system as a whole. This assists decision makers when considering where investment is needed and how to prioritize those decisions.
The function of business architecture is to facilitate coordinated and synchronized action across the organization by aligning action with the organization’s vision, goals, and strategy. The architectural models created in this process are the tools used to clarify, unify, and provide understanding of the intent of the vision, goals, and strategy, and to ensure that resources are focused and applied to the elements of the organization that align with and support this direction.
Business architecture provides a blueprint that management can use to plan and execute strategies from both information technology (IT) and non-IT perspectives. Business architecture is used by organizations to guide:
• strategic planning,
• business remodelling,
• organization redesign,
• performance measurement and other transformation initiatives to improve customer retention,
• streamlining business operations,
• cost reduction,
• the formalization of institutional knowledge, and
• the creation of a vehicle for businesses to communicate and deploy their business vision.

.4 Delivery Approach

Business architecture creates a planning framework that provides clarity and insight into the organization and assists decision makers in identifying required changes. The architectural blueprints provided by business architecture provide an insight and understanding of how well the organization aligns to its strategy. This insight is the trigger for change or other planning activities.

For each blueprint provided, business architecture may define:
• current state,
• future state, and
• one or more transition states that are used to transition to the future state.
Business architects require a view of the entire organization. In general, they may report directly to a member of senior leadership. Business architects require a broad understanding of the organization, including its:
• environment and industry trends,
• structure and reporting relationships,
• value streams,
• capabilities,
• processes,
• information and data stores, and
• how all these elements align to support the strategy of the organization.
Business architects play an important role in communicating and innovating for the strategy of the organization. They utilize blueprints, models, and insights provided by business architecture to continually advocate for the strategy of the organization and address individual stakeholder needs within the scope of the organization’s goals.
There are several factors central to a successful business architecture:
• support of the executive business leadership team,
• integration with clear and effective governance processes, including organizational decision-making authorities (for example, for investments, initiatives, and infrastructure decisions),
• integration with ongoing initiatives, (this might include participation in steering committees or other similar advisory groups), and
• access to senior leadership, departmental managers, product owners, solution architects, project business analysts, and project managers.

.5 Major Assumptions

To make business architecture useful to the organization, business analysts require:
• a view of the entire organization that is under analysis,
• full support from the senior leadership,
• participation of business owners and subject matter experts (SMEs),
• an organizational strategy to be in place, and
• a business imperative to be addressed.

11.3.2 Business Analysis Scope

.1 Change Sponsor

Ideally, the sponsor of a business architecture initiative is a senior executive or business owner within the organization. However, the sponsor may also be a line- of-business owner.

.2 Change Targets

The following list identifies the possible primary change targets resulting from a business architecture analysis:
• business capabilities,
• business value streams,
• initiative plans,
• investment decisions, and
• portfolio decisions.
The following groups of people use business architecture to guide change within the organization:
• management at all levels of the organization,
• product or service owners,
• operational units,
• solution architects,
• project managers, and
• business analysts working in other contexts (for example, at the project level).

.3 Business Analyst Position

The goal of a business analyst working within the discipline of business architecture is to:
• understand the entire enterprise context and provide balanced insight into all the elements and their relationship across the enterprise, and
• provide a holistic, understandable view of all the specialties within the organization.
Business architecture provides a variety of models of the organization. These models, or blueprints, provide holistic insight into the organization that becomes the basis for strategic decisions by the leaders of the organization. To develop a business architecture, the business analyst must understand, assimilate, and align a wide variety of specialties that are of strategic concern to the organization. To

do this they require insight, skills, and knowledge from:
• business strategy and goals,
• conceptual business information,
• enterprise IT architecture,
• process architecture, and
• business performance and intelligence architecture.
Business architecture supports the strategic advisory and planning groups that guide and make decisions regarding change within the organization. It provides guidance and insights into how decisions align to the strategic goals of the organization, and ensures this alignment throughout the various transition states as the change moves towards its future state.

.4 Business Analysis Outcomes

Business architecture provides a broad scope and a holistic view for business analysis.
The general outcomes of business architecture include:
• the alignment of the organization to its strategy,
• the planning of change in the execution of strategy, and
• ensuring that as change is implemented, it continues to align to the strategy.
These business architecture outcomes provide context for requirements analysis, planning and prioritization, estimation, and high-level system design. This provides insight and alignment with strategy, stakeholder needs, and business capabilities. Architectural views and blueprints provide information that may have otherwise been based on assumptions, and minimize the risk of duplication of efforts in creating capabilities, systems, or information that already exist elsewhere in the enterprise.
The various models and blueprints provided by business architecture are its key deliverables. These include, but are not limited to:
• business capability maps,
• value stream maps,
• organization maps,
• business information concepts,
• high-level process architecture, and
• business motivation models.

11.3.3 Reference Models and Techniques

.1 Reference Models

Reference models are predefined architectural templates that provide one or more viewpoints for a particular industry or function that is commonly found across multiple sectors (for example, IT or finance).
Reference models are frequently considered the default architecture ontology for the industry or function. They provide a baseline architecture starting point that business architects can adapt to meet the needs of their organization.
The follow table lists some of the common reference models.

Table 11.4.1: Business Architecture Reference Models

.2 Techniques
The following table lists techniques that are commonly used within the discipline of business architecture, and are not included in the Techniques section of the BABOK® Guide.

Table 11.4.2: Business Architecture Techniques

**

Table 11.4.2: Business Architecture Techniques (Continued)

11.3.4 Underlying Competencies
In addition to the underlying competencies, business analysts working in the discipline of business architecture require:
• a high tolerance for ambiguity and uncertainty,
• the ability to put things into a broader context,
• the ability to transform requirements and context into a concept or design of a solution.
• the ability to suppress unnecessary detail to provide higher level views,
• the ability to think in long time frames over multiple years,
• the ability to deliver tactical outcomes (short term), which simultaneously provide immediate value and contribute to achieving the business strategy (long term),
• the ability to interact with people at the executive level,
• the ability to consider multiple scenarios or outcomes,
• the ability to lead and direct change in organizations, and
• a great deal of political acumen.

11.3.5 Impact on Knowledge Areas

This section explains how specific business analysis practices within business architecture are mapped to business analysis tasks and practices as defined by the BABOK® Guide. This section describes how each knowledge area is applied or modified within the business architecture discipline.
Each knowledge area lists techniques relevant to a business architecture perspective. BABOK® Guide _techniques are found in the Techniques chapter of the _BABOK® Guide. Other business analysis techniques are not found in the Techniques chapter of the BABOK® _Guide _but are considered to be particularly useful to business analysts working in the discipline of business architecture. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.

.1 Business Analysis Planning and Monitoring

During Business Analysis Planning and Monitoring, the discipline of business architecture requires business analysts to understand the organization’s:
• strategy and direction,
• operating model and value proposition,
• current business and operational capabilities,
• stakeholders and their points of engagement,
• plans for growth, governance, and planning processes,
• culture and environment, and
• capacity for change.
Once these elements are understood the business analyst can then develop an understanding of which architectural viewpoints are relevant to the analysis.
Governance planning and monitoring activities primarily focus on:
• selecting which projects or initiatives will provide the most benefit in achieving the business strategies and outcomes, and
• determining which frameworks or models exist or are utilized within the organization.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Brainstorming (p.227)
• Business Capability Analysis (p.230)
• Decision Analysis (p.261)
• Estimation (p.271)
• Functional Decomposition (p.283)
• Interviews (p.290)
• ItemTracking(p.294)
• MetricsandKeyPerformanceIndicators (KPIs) (p.297)

• Non-Functional RequirementsAnalysis (p.302)
• Organizational Modelling (p.308)
• Process Modelling (p.318)
• Reviews (p.326)
• Risk Analysis and Management(p.329)
• RolesandPermissionsMatrix(p.333)

Other Business Analysis Techniques

• Business Process Architecture
• Capability Map
• Root Cause Analysis (p.335)
• Scope Modelling (p.338)
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p.350)
• Use Cases and Scenarios (p.356)
• User Stories (p.359)

• Project Portfolio Analysis
• Service-oriented Analysis

.2 Elicitation and Collaboration

Business analysts working in the discipline of business architecture typically deal with a great deal of ambiguity and uncertainty. When undertaking Elicitation and Collaborationtasks, business analysts consider changes in organizational direction based on external and internal forces and changes in marketplace environment. The types of changes can frequently be predicted, but external market pressures frequently make the pace of the change unpredictable.
As business architecture requires many inputs from across the organization, access to (and the availability of) stakeholders is critical to success. Business analysts elicit inputs such as strategy, value, existing architectures, and performance metrics.
Advocacy for the organization’s strategy is central to the communication strategy of business architects. As members of various steering committees and advisory groups, business architects utilize formal communication channels within projects, initiatives, and operational groups to communicate the organization’s strategy, explain the organizational context, and advocate alignment with the strategy.
Ensuring stakeholders understand and support the organization’s strategy is an essential function within the discipline of business architecture. Business architects may impose scope and constraints on a project or initiative as a means to ensure the activity aligns to the organization’s strategy, which may be viewed unfavourably. It is the role of the business architect to bridge the needs and desires of individual stakeholders, projects, and operational groups with the context and understanding of the organizational goals and strategy. The business architect’s goal is to optimize the enterprise’s goals and strategy, and discourage activities that achieve a narrow goal at the cost of sub-optimizing the entire objective. This is an exercise in both elicitation and in collaboration.
The business architect acquires a deep understanding of the strategy, drivers, motivations, and aspirations of the organization and those of the stakeholders. Once this level of understanding is achieved, the business architect collaborates

Perspectives The Business Architecture Perspective

with all levels of the organization including senior leadership, managers, the project management office (PMO), product owners, project managers, various business analysts, solution architects, and IT personnel to bridge gaps in understanding and communicating the importance of alignment with organizational strategy. Facilitating effective collaboration requires that the business architect is able to understand the wide variety of perspectives and contexts from which each stakeholder operates. The business architect must also be able to communicate with each of these stakeholders in a language that is mutually understood and supported.

BABOK® Guide Techniques

• Brainstorming (p.227)
• Document Analysis (p.269)
• Focus Groups (p.279)
• Functional Decomposition (p.283)
• Glossary (p.286)
• Interface Analysis (p.287)
• Interviews (p.290)

Other Business Analysis Techniques

• none
• ItemTracking(p.294)
• Observation (p.305)
• Prototyping (p.323)
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p.350)
• Workshops (p.363)

.3 Requirements Life Cycle Management

It is essential that business analysts working in the discipline of business architecture have executive support and agreement of the work to be undertaken. An architecture review board comprised of senior executives with decision-making powers can review and assess changes to the business architecture. This group will often also engage in portfolio management by making decisions regarding the investment in and prioritization of change based on their impact to business outcomes and strategy.
Business analysts working in the discipline of business architecture understand how projects impact the business architecture on an ongoing basis and work to continually expand, correct, or improve the business architecture. They also identify possible emerging changes in both internal and external situations (including market conditions), and decide on how to incorporate these changes into the business architecture of the organization.

BABOK® Guide Techniques

• Balanced Scorecard (p.223)
• Benchmarking and Market Analysis(p.226)
• Business Capability Analysis (p.230)
• Collaborative Games (p.243)
• Data Modelling (p.256)
• Decision Analysis (p.261)
• Estimation (p.271)

The Business Architecture Perspective Perspectives

• Interface Analysis (p.287)
• ItemTracking(p.294)
• Lessons Learned (p.296)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Organizational Modelling (p.308)
• Process Analysis (p.314)
• Process Modelling (p.318)

Other Business Analysis Techniques

• Archimate®
• Business Process Architecture
• Business Value Modelling
• Capability Map
• Enterprise Core Diagram
• Reviews (p.326)
• Risk Analysis and Management(p.329)
• RolesandPermissionsMatrix(p.333)
• Root Cause Analysis (p.335)
• Stakeholder List, Map, orPersonas(p.344)
• SWOT Analysis (p.353)

• Project Portfolio Analysis
• Roadmap
• Service-oriented Analysis
• Value Mapping

.4 Strategy Analysis

Business architecture can play a significant role in strategy analysis. It provides architectural views into the current state of the organization and helps to define both the future state and the transition states required to achieve the future state.
Business architects develop roadmaps based on the organization’s change strategy. Clearly defined transition states help ensure that the organization continues to deliver value and remain competitive throughout all the phases of the change. To keep competitive, the business must analyze such factors as:
• market conditions,
• which markets to move into,
• how the organization will compete in the transition state, and
• how to best position the organization’s brand proposition.
Business architecture provides the enterprise context and architectural views that allow an understanding of the enterprise so these questions can be analyzed in the context of cost, opportunity, and effort.

BABOK® Guide Techniques

• Balanced Scorecard (p.223)
• Benchmarking and Market Analysis(p.226)
• Brainstorming (p.227)
• Business Capability Analysis (p.230)
• Business Model Canvas (p.236)
• Business Rules Analysis (p.240)
• Collaborative Games (p.243)
• Data Modelling (p.256)
• Document Analysis (p.269)
• Estimation (p.271)
• Focus Groups (p.279)

• Glossary (p.286)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Organizational Modelling (p.308)
• Reviews (p.326)
• Risk Analysis and Management(p.329)

Other Business Analysis Techniques

• Archimate®
• Business Process Architecture
• Capability Map
• Customer Journey Map
• Enterprise Core Diagram
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p.350)
• SWOT Analysis (p.353)
• Workshops (p.363)

• Project Portfolio Analysis
• Roadmap
• Service-oriented Analysis
• Strategy Map
• Value Mapping

.5 Requirements Analysis and Design Definition

Business architecture provides individual architectural views into the organization through a variety of models that are selected for the stakeholders utilizing the view. These architectural views can be provided by capability and value maps, organizational maps, and information and business process models. Business analysts working in the discipline of business architecture employ expertise, judgment, and experience when deciding what is (and what is not) important to model. Models are intended to provide context and information that result in better requirements analysis and design.
The architectural context and the ability to reference readily available architectural views provides information that would have otherwise been based on assumptions that the analyst must make because no other information was available. By providing this information, business architecture minimizes the risk of duplication of efforts in creating capabilities, systems, or information that already exist elsewhere in the enterprise.
Design is done in conjunction with understanding needs and requirements. Business architecture provides the context to analyze the strategic alignment of proposed changes and the effects those changes have upon each other. Business architects synthesize knowledge and insights from multiple architectural views to determine if proposed changes work towards or conflict with the organization’s goals.
Business architecture attempts to ensure that the enterprise as a whole continues to deliver value to stakeholders both during normal operations and during change. Business analysts working in the discipline of business architecture focus on the value provided by the organization from a holistic view. They attempt to avoid local optimization where effort and resources are put into a single process or system improvement which does not align with the strategy and garners no meaningful impact to the enterprise as a whole—or worse, sub-optimizes the whole.

**

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Backlog Management (p.220)
• Balanced Scorecard (p.223)
• Benchmarking and Market Analysis(p.226)
• Brainstorming (p.227)
• Business Capability Analysis (p.230)
• Business Model Canvas (p.236)
• Business Rules Analysis (p.240)
• Collaborative Games (p.243)
• Data Dictionary (p.247)
• Data Flow Diagrams (p.250)
• Data Modelling (p.256)
• Decision Analysis (p.261)
• Document Analysis (p.269)
• Estimation (p.271)
• Focus Groups (p.279)
• Functional Decomposition (p.283)
• Glossary (p.286)
• Interface Analysis (p.287)
• ItemTracking(p.294)
• Lessons Learned (p.296)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)

Other Business Analysis Techniques

• Archimate®
• Business Process Architecture
• Capability Map
• Customer Journey Map
• Enterprise Core Diagram

• Non-Functional RequirementsAnalysis (p.302)
• Observation (p.305)
• Organizational Modelling (p.308)
• Process Analysis (p.314)
• Process Modelling (p.318)
• Prototyping (p.323)
• Reviews (p.326)
• Risk Analysis and Management(p.329)
• RolesandPermissionsMatrix(p.333)
• Root Cause Analysis (p.335)
• Scope Modelling (p.338)
• Sequence Diagrams (p.341)
• Stakeholder List, Map, orPersonas(p.344)
• State Modelling (p.348)
• Survey or Questionnaire (p.350)
• SWOT Analysis (p.353)
• Use Cases and Scenarios (p.356)
• User Stories (p.359)
• VendorAssessment (p.361)
• Workshops (p.363)

• Project Portfolio Analysis
• Roadmap
• Service-oriented Analysis
• Value Mapping

.6 Solution Evaluation

Business architecture asks fundamental questions about the business, including

the important question of how well the business is performing.
To answer this question, several other questions must be answered:
• What outcomes are the business, a particular initiative, or component expecting to achieve?
• How can those outcomes be measured in terms of SMART (Specific, Measurable, Achievable, Relevant, Time-bounded) objectives?
• What information is needed to measure those objectives?
• How do processes, services, initiatives, etc. need to be instrumented to collect that information?
• How is the performance information best presented in terms of reports, ad hoc queries, dashboards, etc.?
• How do we use this information to make investment decisions in the future?
For example, at a more detailed level, an important part of capability definition and process architecture is to identify the specific performance characteristics and outcome that those capabilities or processes are expected to achieve. The actual measurement is rarely conducted by business analysts. It is usually done by business owners, operational, or information technology managers.
Business analysts working in the discipline of business architecture analyze the results of measurements and factor these results into subsequent planning.

BABOK® Guide Techniques

• Balanced Scorecard (p.223)
• Benchmarking and Market Analysis(p.226)
• Brainstorming (p.227)
• Business Capability Analysis (p.230)
• Collaborative Games (p.243)
• Focus Groups (p.279)
• ItemTracking(p.294)
• Lessons Learned (p.296)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Observation (p.305)

Other Business Analysis Techniques

• Business Motivation Modelling
• Business Process Architecture
• Capability Map
• Organizational Modelling (p.308)
• Process Analysis (p.314)
• Process Modelling (p.318)
• Risk Analysis and Management(p.329)
• RolesandPermissionsMatrix(p.333)
• Root Cause Analysis (p.335)
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p.350)
• SWOT Analysis (p.353)

• Customer Journey Map
• Service-oriented Analysis
• Value Mapping

11.4 The Business Process Management Perspective

The Business Process Management Perspective highlights the unique characteristics of business analysis when practiced in the context of developing or improving business processes.
Business Process Management (BPM) is a management discipline and a set of enabling technologies that:
• focuses on how the organization performs work to deliver value across multiple functional areas to customers and stakeholders,
• aims for a view of value delivery that spans the entire organization, and
• views the organization through a process-centric lens.
A BPM initiative delivers value by implementing improvements to the way work is performed in an organization.
BPM determines how manual and automated processes are created, modified, cancelled, and governed. Organizations that hold a process-centric view treat BPM as an ongoing effort and an integral part of the ongoing management and operation of the organization.

11.4.1 Change Scope

Business analysts working within the BPM discipline may address a single process with limited scope or they may address all of the processes in the organization. Business analysts frequently focus on how the processes of an organization can be changed in order to improve and meet the objectives of the organization.
BPM life cycles generally include the following activities:
• Designing: the identification of processes and definition of their current state (as-is) and determining how we get to the future state (to-be). The gap between these states may be used to specify stakeholders’ expectations of how the business should be run.
• Modelling: the graphical representation of the process that documents the process as well as comparing current state (as-is) and future state (to-be). This phase of the BPM life cycle provides input to requirements and solution design specification, as well as analyzing their potential value. Simulation may use quantitative data so that the potential value of variations on the process can be analyzed and compared.
• Execution and Monitoring: provides the same type of input as modelling but in terms of the actual execution of processes. The data collected as a result of the actual business process flow is very reliable and objective which makes it a very strong asset in analyzing value and recommending alternatives for design improvement.
• Optimizing: the act of ongoing repetition or iteration of the previous phases. The results of business process execution and monitoring are utilized to modify models and designs so that all inefficiencies are removed

and more value is added. Optimization may be a source of requirements and solution design definitions that comes directly from stakeholders and the user community. Optimization of processes is also a good way to demonstrate the value of a suggested solution modification, and justify process and product improvement initiatives.

.1 Breadth of Change

The goal of BPM is to ensure that value delivery is optimized across end-to-end processes. A comprehensive BPM initiative can span the entire enterprise. A single BPM initiative can make an organization become more process-centric by providing insights into its processes. An organization’s processes define what the organization does and how it does it. Possessing a thorough understanding of its processes allows stakeholders to adjust these processes to meet the evolving needs of both the organization and its customers.
Individual initiatives may improve specific processes and sub-processes. Breaking down larger, more complex processes into smaller chunks (sub-processes) allows business analysts to better understand what each process is doing and how to optimize them.

.2 Depth of Change

Business analysts use BPM frameworks to facilitate the analysis and deep understanding of the organization’s processes. BPM frameworks are sets or descriptions of processes for a generic organization, specific industry, professional area, or type of value stream. BPM frameworks define particular levels of processes throughout the organization’s process architecture.
As an example, business analysts perform supply chain analysis as a means of evaluating specific processes in an organization. Analysis of the supply chain is frequently conducted by decomposing group-level processes into individual sub- components and then decomposing these down to individuals performing specific tasks.
Business analysts involved with business process management are frequently engaged in continuous improvement activities as they are often the ones most familiar with BPM.

.3 Value and Solutions Delivered

The goal of BPM is to improve operational performance (effectiveness, efficiency, adaptability, and quality) and to reduce costs and risks. Business analysts frequently consider transparency into processes and operations as a common core value of BPM initiatives. Transparency into processes and operations provides decision makers a clear view of the operational consequences of previous process related decisions. Business analysis efforts frequently begin with the identification of the business need of the customers. Needs are generally referred to as BPM drivers. BPM drivers include:
• cost reduction initiatives,
• increase in quality,

The Business Process Management Perspective Perspectives

• increase in productivity,
• emerging competition,
• risk management,
• compliance initiatives,
• next generation process automation,
• core system implementation,
• innovation and growth,
• post merger and acquisition rationalization,
• standardization initiatives,
• major transformation programs,
• establishment of a BPM Centre of Excellence,
• increased agility, and
• speed or faster processes.

.4 Delivery Approach

The delivery approach for BPM initiatives across organizations ranges from a set of tactical methods focused on improving individual processes to a management discipline that touches all the processes in an organization. The main purpose of process transformation is to help organizations identify, prioritize, and optimize their business processes to deliver value to stakeholders.
Organizations conduct periodic assessments of key processes and engage in ongoing continuous improvement to achieve and sustain process excellence. The success of BPM can be measured by how well the BPM initiative aligns to the objectives set for BPM in the organization.
There are several mechanisms that can be used to implement BPM:
• Business process re-engineering: methods that aim for major process redesign across the enterprise.
• Evolutionary forms of change: methods that have overall objectives set for the process and then individual changes aimed at bringing sub- processes in line with those goals are implemented.
• Substantial discovery: methods are used when organizational processes are undefined or if the documented version of the process is substantially different from the actual process in use. Substantial discovery is about revealing actual processes and is a method for organizational analysis.
• Process benchmarking: compares an organization’s business processes and performance metrics to industry best practices. Dimensions typically measured are quality, time, and cost.
• Specialized BPMS applications: are designed to support BPM initiatives and execute the process models directly. These applications are tools that

automate BPM activities. Often the organization’s processes are required to be changed to match the automated approach.
Process improvement approaches can be categorized in terms of their point of origin and whether their solutions are primarily organizational (people-based) or technological (IT-based). Organizations can better understand the process improvement methodology, as mentioned in the previous paragraph, to apply based on the following organizing principles:
• Top-down: initiatives are typically orchestrated from a central point of control by senior management and have organization spanning implications, targeted at end-to-end processes or major parts of the business.
• Bottom-up: initiatives are typically tactical approaches to improving individual processes and departmental workflows, or sub-processes in smaller parts of the organization.
• People-centric: initiatives where the principal change is to the activities and workflows in an organization.
• IT-centric: initiatives frequently focused on process automation.

.5 Major Assumptions

The following is a list of major assumptions from the BPM discipline:
• Processes are generally supported by information technology systems, but the development of those systems is not covered by most BPM methods. Business analysts may suggest additional business requirements based on existing IT systems.
• BPM initiatives have senior management support. The business analyst may be involved in suggesting additional business requirements based on organizational strategies.
• BPM systems require a tight integration with organizational strategy but most methods do not tackle the development of strategy which is outside the scope of this perspective.
• BPM initiatives are cross-functional and end-to-end in the organization.

11.4.2 Business Analysis Scope

.1 Change Sponsor

Enterprise-wide BPM initiatives are typically started by executives focusing on value and outcomes and then linking these strategic objectives to the corresponding business processes which most closely support the objectives.
BPM initiatives are frequently triggered by an external situation which generates a business need. Enterprise business analysis practices are applied to develop a business case for a BPM initiative.

Process improvements are typically initiated or at least managed by a process manager at any level of the organization. The scope of the process or sub-process usually determines the authority of the process manager.

.2 Change Targets

The possible primary change targets for a BPM initiative include:
• Customer: the key stakeholder in any BPM initiative. The principal focus is on the external customer but internal customers are also considered. Since BPM is customer-centric by nature, the customer is part of BPM initiatives in order to validate the effectiveness of the process change. Involving the customer early in the initiative minimizes the risk of failure by ensuring the goals of process delivery are aligned to the customer’s expectations.
• Regulator: a stakeholder in any BPM initiative due to evolving requirements towards compliance and risk management by some organizations. Regulators may trigger a BPM initiative due to changes in regulations on such concerns as public safety, transparency, equal opportunity, and non-discrimination.
• Process Owner: the key stakeholder in any BPM initiative and has the responsibility and authority to make the final decision regarding any changes to the affected processes. The process owner is also responsible for measuring the process performance.
• Process Participants: stakeholders who directly or indirectly participate in the process being evaluated. These participants define the activities of the process. In order to ensure that the interests of process participants are met, the process owner engages them during design of the process.
• Project Manager: manages the BPM initiative and is accountable for its delivery and driving decisions. The project manager works with a team including process analysts, process owners, and process designers. The project manager is responsible for planning, scheduling, communication management, change management, and risk management.
• Implementation Team: converts the plans of the BPM initiative into functioning business processes. The success of a BPM initiative is the ability to integrate all the functions that meet the needs of the customer.

.3 Business Analysis Position

Business analysts working within the discipline of business process management may assume a variety of roles:
• Process Architect: responsible for modelling, analyzing, deploying, monitoring, and continuously improving business processes. A process architect knows how to design business processes and how to enhance those processes either manually or for automated business process execution on a BPM platform. Process architects address and guide the decisions around what process knowledge, methodology, and technology is required to meet the objectives of the organization with respect to a

particular BPM initiative. Process architects enhance and transform business processes into technically enhanced and executable process templates.
Depending on the BPM initiative, process architects may be focused on managing business performance or on mapping technology to business operations. Process architects are responsible for developing and maintaining standards and the repository of reference models for products and services, business processes, key performance indicators (KPIs), and critical success factors (CSF). They are engaged in process analysis and transformation initiatives.
• Process Analyst/Designer: has detailed process knowledge, skills, and interest. They are experts in documenting and understanding process design along with performance trends. Process analysts/designers have an interest in business process optimization to increase overall business performance. This goal requires an understanding of the detailed process and includes performing the necessary analysis for process optimization. They perform analysis and assessment of as-is processes, evaluate alternate process design options, and make recommendations for change based on various frameworks.
• Process Modeller: captures and documents business (both the as-is and to-be) processes. The process modeller is frequently a process analyst working to document a process for implementation or support by an information technology system.
The process analyst/designer and the process modeller functions frequently reside within a single position.

Figure 11.5.1: Business Analyst Roles in a BPM Initiative

**

.4 Business Analysis Outcomes
Outcomes for business analysts working within the discipline of business process management include:
• business process models,
• business rules,
• process performance measures,
• business decisions, and
• process performance assessment.

Business Process Models

Business process models start at the highest level as an end-to-end model of the whole process and can become as specific as modelling specific work flow.
Business process models serve as both an output and a starting point for the analysis of the process. They are divided into current state (as-is) and future state (to-be) models. Current state models portray the process as it currently functions, without any improvements. The future state model envisions what the process would look like if all improvement options are incorporated. The benefit of developing the current state model is to justify the investment in the process by enabling the business analyst to measure the effect of the process improvements and prioritize changes to the process. Transition models describe the interim states required to move from the current state process to the future state process.

Business Rules

Business rules guide business processes and are intended to assert business structure or control the behaviour of business. Business rules are identified during requirements elicitation and process analysis and often focus on business calculations, access control issues, and policies of an organization. Classifying business rules can help decide how they will be best implemented. Business rules analysis provides insight into how the business functions and how the processes contribute to meeting the business’ goals and objectives. Business analysts analyze the reasons for the existence of a business rule and study its impact on the business process before improving or redesigning it. Business rules may, where appropriate, be mapped to individual processes through the decisions they influence unless they are related strictly to the performance of the process.

Process Performance Measures

Process performance measures are parameters that are used to identify process improvement opportunities. Process performance measures are defined and deployed to ensure that processes are aligned to the business needs and strategic objectives of the organization. Process performance measures can address many aspects of a process including quality, time, cost, agility, efficiency, effectiveness, responsiveness, adaptability, flexibility, customer satisfaction, velocity, variability, visibility, variety, rework, and volume. Many of the process performance measures seek to measure the effectiveness and efficiency of the process as well as the degree to which the process goals are achieved. When deployed across the

business, process performance measures can indicate the maturity level of process culture in an organization and generate a shared understanding of process performance across an organization. Performance measures are keys to defining service level agreements where an organization provides service to their customers.

Business Decisions

Business decisions are a specific kind of task or activity in a business process that determine which of a set of options will be acted upon by the process. Decisions must be made (using a task or activity) and then acted upon (often with a gateway or branch in the process). Decisions may be manual or automated, are modelled independently, and are best described using business rules. Decision rules, often implemented through a business rules engine, allow these business decisions to be automated.

Process Performance Assessment

The success of any BPM initiative rests on the intention and capability to continuously measure and monitor the performance of targeted business processes. The assessment can be static and be documented with assessment reports and scorecards, or dynamic and be delivered through dashboards. It provides necessary information to decision makers in an organization to redeploy and adjust resources in order to meet process performance goals.

11.4.3 Frameworks, Methodologies, and Techniques

.1 Frameworks

The following table lists frameworks that are commonly used within the discipline of business process management.

BPM Frameworks

**

BPM Frameworks (Continued)

.2 Methodologies

The following table lists methodologies that are commonly used within the discipline of business process management.

Table 11.5.1: BPM Methodologies

**

Table 11.5.1: BPM Methodologies (Continued)

.3 Techniques
The following table lists techniques, not included in the Techniques chapter of the
BABOK® _Guide _and are commonly used within the discipline of BPM.

Table 11.5.2: BPM Techniques

Table 11.5.2: BPM Techniques (Continued)

**

11.4.4 Underlying Competencies
Business analysts working within the discipline of business process management are required to challenge the status quo, dig to understand the root causes of a problem, assess why things are being done in a particular way, and encourage subject matter experts (SMEs) to consider new ideas and approaches to make their processes more efficient and effective. They are also required to understand, articulate, and move back and forth between internal and external views of the processes under analysis.
Due to the effects that changes to processes have on the working habits of individuals, interaction skills are valuable in a BPM initiative. Business analysts frequently negotiate and arbitrate between individuals with different opinions, and expose and resolve conflicts between different groups within the organization. The business analyst is a neutral and independent facilitator of the change.
BPM initiatives are likely to involve all levels of the organization and the business analyst is required to communicate across organizational boundaries as well as outside the organization.

11.4.5 Impact on Knowledge Areas

This section explains how specific business analysis practices within business process management are mapped to business analysis tasks and practices as defined by the BABOK® Guide. This section also describes how each knowledge area is applied or modified within the business process management discipline.
Each knowledge area lists techniques relevant to a business process management perspective. BABOK® Guide _techniques are found in the Techniques chapter of the _BABOK® Guide. Other business analysis techniques are not found in the chapter, but are considered to be particularly useful to business analysts working in the discipline of business process management. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.

.1 Business Analysis Planning and Monitoring

Progressive elaboration is common in the planning of BPM initiatives due to the fact that the amount of information available for full planning may be limited in the initial stages. BPM initiatives involve continuous improvement activities, and a common cause of failure of BPM initiatives is the failure to plan for ongoing monitoring of the effect of changes to the process. In BPM initiatives, the initial focus of business analysis work is on analyzing and improving the business process before looking at the technology used to support the process, and any changes that might be required to software applications or work procedures.

**

BABOK® Guide Techniques

• Estimation (p.271)
• ItemTracking(p.294)
• Process Modelling (p.318)

Other Business Analysis Techniques

• Inputs, Guide, Outputs, Enablers (IGOE)

• Reviews (p.326)
• Stakeholder List, Map, orPersonas(p.344)
• Workshops (p.363)

.2 Elicitation and Collaboration

For the BPM initiative to be successful, the scope of the initiative and the scope of the affected process must be defined and understood.
Process modelling and stakeholder analysis are generally utilized during the elicitation phase of a BPM initiative. During elicitation, the business analyst focuses on cause and effect of both changing existing processes and keeping the processes as they are through the elicitation and collaboration effort. As an existing process is changed, the effect of any process improvements identified on the organization, people, and technology are considered. Process maps are an important tool to drive elicitation in BPM initiatives and stakeholders are frequently consulted during their development. Effective elicitation and collaboration is critical in process modelling analysis and design work.
Process changes can have significant impacts across the organization, so managing stakeholders and their expectations is particularly critical. Without effective stakeholder management, process changes may not be successfully implemented or the changes may not meet the organization’s goals and objectives.

BABOK® Guide Techniques

• Brainstorming (p.227)
• Document Analysis (p.269)
• Focus Groups (p.279)
• Interface Analysis (p.287)
• Interviews (p.290)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)
• Observation (p.305)
• Process Modelling (p.318)
• Prototyping (p.323)

Other Business Analysis Techniques

• House of Quality/Voice of Customer
• Reviews (p.326)
• Root Cause Analysis (p.335)
• Scope Modelling (p.338)
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p.350)
• Use Cases and Scenarios (p.356)
• User Stories (p.359)
• Workshops (p.363)

.3 Requirements Life Cycle Management

BPM is a set of approaches that focus on ways to deliver value across multiple functional areas through a process-centric lens. Delivering additional value is often related to deliberately undertaking change but could also result from an ad hoc request or review of processes. The impact of BPM activities on requirements life cycle management is significant as it can drive out business requirements resulting in new design, coding, implementation, and post-implementation changes. It is the responsibility of the business analyst to maintain this connection and ensure that communication is effectively conducted with stakeholders and process owners who are the ultimate decision makers when it is about processes, change, and supporting solutions.
The documentation of business processes is available to all stakeholders as it is to be used in the daily operation of the business. If the process is automated through a BPMS, the representation of the process may be directly executable.

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Backlog Management (p.220)
• Brainstorming (p.227)
• Business Rules Analysis (p.240)
• Non-Functional RequirementsAnalysis (p.302)

Other Business Analysis Techniques

• none
• Prioritization (p.311)
• Process Analysis (p.314)
• Process Modelling (p.318)
• Prototyping (p.323)
• Scope Modelling (p.338)
• Workshops (p.363)

.4 Strategy Analysis

In a BPM context, strategy analysis involves understanding the role the process plays in an enterprise value chain. At a minimum, any process that interacts with the processes affected by the initiative must be considered.
The current state is likely to be described by the as-is value chain and the current performance measures for the business process. The future state will be described by the to-be value chain and target performance measures. Continuous improvement methods may simply focus on the performance measures to determine the strategy. The change strategy will involve the identification of possible process changes.

BABOK® Guide Techniques

• Document Analysis (p.269)
• Functional Decomposition (p.283)
• Interviews (p.290)
• Lessons Learned (p.296)
• Process Analysis (p.314)
• Process Modelling (p.318)

**

Other Business Analysis Techniques

• Drum-Buffer-Rope
• House of Quality/Voice of Customer

• Inputs, Guide, Outputs, Enablers (IGOE)
• TOC Thinking Processes

.5 Requirements Analysis and Design Definition

Requirements analysis and design definition will focus on defining the to-be process model. The requirements architecture is likely to include the process model, associated business rules and decisions, information requirements, and the organizational structure. Solution options typically include changes to IT needed to support the process, outsourcing of aspects of the process, and similar changes.

BABOK® Guide Techniques

• Benchmarking and MarketAnalysis(p.226)
• Business Rules Analysis (p.240)
• Decision Modelling (p.265)
• Estimation (p.271)
• Functional Decomposition (p.283)
• Metrics and Key PerformanceIndicators (KPIs) (p.297)

Other Business Analysis Techniques

• Prioritization (p.311)
• Prototyping (p.323)
• Scope Modelling (p.338)
• Stakeholder List, Map, orPersonas(p.344)
• Workshops (p.363)

• Kaizen Event • Process Simulation

.6 Solution Evaluation

Solution evaluation typically occurs repeatedly during BPM initiatives in order to assess the performance of the business process. As processes are evaluated for different scenarios, they can be refined and the results are monitored. Solution evaluation tasks provide insight into the understanding of the impact of process improvements and the value delivered by business process change. The solution may also involve process mining which uses such techniques as audit trails or transaction logs to obtain process details.
The analyze solution performance task is performed to understand the differences between potential value and actual value. This analysis is performed to discover why there is a variance between potential and actual value, to determine if a solution can perform better or realize more value. The evaluation examines opportunities or constraints of the implemented solution, how it satisfies needs, or how it could be improved. This may trigger further optimization of the process and a repeat of the BPM life cycle.

**

BABOK® Guide Techniques

• Acceptance and EvaluationCriteria(p.217)
• Balanced Scorecard (p.223)
• Benchmarking and Market Analysis(p.226)
• Brainstorming (p.227)
• Business Capability Analysis (p.230)
• Business Rules Analysis (p.240)
• Decision Analysis (p.261)
• Document Analysis (p.269)
• Estimation (p.271)
• Interviews (p.290)

Other Business Analysis Techniques

• Kaizen Event
• Failure Mode and Effect Analysis (FMEA)
• Process Simulation
• Value Stream Analysis

• MetricsandKeyPerformanceIndicators (KPIs) (p.297)
• Observation (p.305)
• Organizational Modelling (p.308)
• Process Modelling (p.318)
• Reviews (p.326)
• Risk Analysis and Management(p.329)
• Root Cause Analysis (p.335)
• Stakeholder List, Map, orPersonas(p.344)
• Survey or Questionnaire (p.350)
• SWOT Analysis (p.353)

Complimentary IIBA® Member Copy. Not for Distribution or Resale.

Glossary

Appendix A: Glossary

acceptance criteria: Criteria associated with requirements, products, or the delivery cycle that must be met in order to achieve stakeholder acceptance.
actor (business analysis): A human, device, or system that plays some specified role in interacting with a solution.
adaptive approach: An approach where the solution evolves based on a cycle of learning and discovery, with feedback loops which encourage making decisions as late as possible.
Agile Extension to the BABOK® Guide: A standard on the practice of business analysis in an agile context. The Agile Extension to the BABOK® Guide _version 1 was published in 2013 by IIBA®, in partnership with the Agile Alliance.
allocation: See _requirements allocation.
architecture: The design, structure, and behaviour of the current and future states of a structure in terms of its components, and the interaction between those components. See also business architecture, enterprise architecture, and requirements architecture.
artifact (business analysis): Any solution-relevant object that is created as part of business analysis efforts.
assumption: An influencing factor that is believed to be true but has not been confirmed to be accurate, or that could be true now but may not be in the future.

behavioural business rule: A business rule that places an obligation (or prohibition) on conduct, action, practice, or procedure; a business rule whose purpose is to shape (govern) day-to-day business activity. Also known as operative rule.
benchmarking: A comparison of a decision, process, service, or system’s cost, time, quality, or other metrics to those of leading peers to identify opportunities for improvement.
body of knowledge: The aggregated knowledge and generally accepted practices on a topic.
BPM: See business process management.
brainstorming: A team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.
business (business analysis): See enterprise.
business (business world): An economic system where any commercial, industrial, or professional activity is performed for profit.

Glossary

business analysis: The practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders.
business analysis information: Any kind of information at any level of detail that is used as an input to business analysis work, or as an output of business analysis work.
business analysis package: A document, presentation, or other collection of text, matrices, diagrams and models, representing business analysis information.
business analyst: Any person who performs business analysis, no matter their job title or organizational role. For more information, see Who is a Business Analyst? (p.2).
business analysis approach: The set of processes, rules, guidelines, heuristics, and activities that are used to perform business analysis in a specific context.
business analysis communication plan: A description of the types of communication the business analyst will perform during business analysis, the recipients of those communications, and the form and frequency of those communications.
business analysis effort: The scope of activities a business analyst is engaged in during the life cycle of an initiative.
business analysis plan: A description of the planned activities the business analyst will execute in order to perform the business analysis work involved in a specific initiative. See also requirements management plan.
business architecture: The design, structure, and behaviour of the current and future states of an enterprise to provide a common understanding of the organization. It is used to align the enterprise’s strategic objectives and tactical demands.
business case: A justification for a course of action based on the benefits to be realized by using the proposed solution, as compared to the cost, effort, and other considerations to acquire and live with that solution.
business decision: A decision that can be made based on strategy, executive judgment, consensus, and business rules, and that is generally made in response to events or at defined points in a business process.
business domain: See domain.
business goal: A state or condition that an organization is seeking to establish and maintain, usually expressed qualitatively rather than quantitatively.
business need: A problem or opportunity of strategic or tactical importance to be addressed.
business objective: An objective, measurable result to indicate that a business goal has been achieved.
business policy: A non-practicable directive that controls and influences the actions of an enterprise.

Glossary

business problem: An issue of strategic or tactical importance preventing an enterprise or organization from achieving its goals.
business process: An end-to-end set of activities which collectively responds to an event, and transforms information, materials, and other resources into outputs that deliver value directly to the customers of the process. It may be internal to an organization, or it may span several organizations.
business process management (BPM): A management discipline that determines how manual and automated processes are created, modified, cancelled, and governed.
business process re-engineering: Rethinking and redesigning business processes to generate improvements in performance measures.
business requirement: A representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed.
business rule: A specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behaviour, shaping judgments, or making decisions.

capability: The set of activities the enterprise performs, the knowledge it has, the products and services it provides, the functions it supports, and the methods it uses to make decisions.
cause-and-effect diagram: See fishbone diagram. change: The act of transformation in response to a need. change agent: One who is a catalyst for change.
change control: Controlling changes to requirements and designs so that the impact of requested changes is understood and agreed-to before the changes are made.
change management: Planned activities, tools, and techniques to address the human side of change during a change initiative, primarily addressing the needs of the people who will be most affected by the change.
change strategy: A plan to move from the current state to the future state to achieve the desired business objectives.
change team: A cross-functional group of individuals who are mandated to implement a change. This group may be comprised of product owners, business analysts, developers, project managers, implementation subject matter experts (SMEs), or any other individual with the relevant set of skills and competencies required to implement the change.
checklist (business analysis): A standard set of quality elements that reviewers use for requirements verification.
collaboration: The act of two or more people working together towards a common goal.

commercial off-the-shelf (COTS): A prepackaged solution available in the
Glossary

marketplace which address all or most of the common needs of a large group of buyers of those solutions. A commercial off-the-shelf solution may require some configuration to meet the specific needs of the enterprise.
competitive analysis: A structured assessment which captures the key characteristics of an industry to predict the long-term profitability prospects and to determine the practices of the most significant competitors.
component: A uniquely identifiable element of a larger whole that fulfills a clear function.
concept model: An analysis model that develops the meaning of core concepts for a problem domain, defines their collective structure, and specifies the appropriate vocabulary needed to communicate about it consistently.
constraint (business analysis): An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option.
context: The circumstances that influence, are influenced by, and provide understanding of the change.
core concept (business analysis): One of six ideas that are fundamental to the practice of business analysis: Change, Need, Solution, Context, Stakeholder, and Value.
cost-benefit analysis: An analysis which compares and quantifies the financial and non-financial costs of making a change or implementing a solution compared to the benefits gained.
COTS: See commercial off-the-shelf.
create, read, update, and delete matrix (CRUD matrix): A two-dimensional matrix showing which user roles have permission to access specific information entities, and to create new records in those entities, view the data in existing records, update or modify the data in existing records, or delete existing records. The same type of matrix can be used to show which processes, instead of users, have the create, read, update and delete rights.
CRUD matrix: See create, read, update, and delete matrix.
customer: A stakeholder who 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.

decision analysis: An approach to decision making that examines and models the possible consequences of different decisions, and assists in making an optimal decision under conditions of uncertainty.
decomposition: A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components.
defect: A deficiency in a product or service that reduces its quality or varies from a desired attribute, state, or functionality.

Glossary

definitional business rule: A rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge, or information. Also known as a structural rule.
deliverable: Any unique and verifiable work product or service that a party has agreed to deliver.
design: A usable representation of a solution. For more information see Key Terms (p. 14)and Requirements and Designs (p. 19).
document analysis (business analysis): An examination of the documentation of an existing system in order to elicit requirements.
domain: The sphere of knowledge that defines a set of common requirements, terminology, and functionality for any program or initiative solving a problem.
domain subject matter expert: A stakeholder with in-depth knowledge of a topic relevant to the business need or solution scope.
DSDM: See dynamic systems development method.
dynamic systems development method (DSDM): A project delivery framework which focuses on fixing cost, quality, and time at the beginning while contingency is managed by varying the features to be delivered.

elicitation: Iterative derivation and extraction of information from stakeholders or other sources.
end user: A stakeholder who directly interacts with the solution.
enterprise: A system of one or more organizations and the solutions they use to pursue a shared set of common goals.
enterprise architecture: A description of the business processes, information technology, people, operations, information, and projects of an enterprise and the relationships between them.
enterprise readiness assessment: An assessment that describes the enterprise is prepared to accept the change associated with a solution and is able to use it effectively.
entity-relationship diagram: A graphical representation of the entities relevant to a chosen problem domain and the relationships between them.
estimate: A quantitative assessment of a planned outcome, resource requirements, and schedule where uncertainties and unknowns are systematically factored into the assessment.
evaluation: The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time, and to identify ways to improve the solution to better meet objectives. See also indicator; metric, monitoring.

Glossary

event (business analysis): An occurrence or incident to which an organizational unit, system, or process must respond.
evolutionary prototype: A prototype that is continuously modified and updated in response to feedback from stakeholders.
experiment: Elicitation performed in a controlled manner to make a discovery, test a hypothesis, or demonstrate a known fact.
external interface: An interaction that is outside the proposed solution. It can be another hardware system, software system, or a human interaction with which the proposed solution will interact.

facilitation: The art of leading and encouraging people through systematic efforts toward agreed-upon objectives in a manner that enhances involvement, collaboration, productivity, and synergy.
feasibility study: An evaluation of proposed alternatives to determine if they are technically, organizationally, and economically possible within the constraints of the enterprise, and whether they will deliver the desired benefits to the enterprise.
feature: A distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders.
fishbone diagram: A diagramming technique used in root cause analysis to identify underlying causes of an observed problem, and the relationships that exist between those causes. Also known as an Ishikawa or cause-and- effect diagram.
focus group: A group formed to to elicit ideas and attitudes about a specific product, service, or opportunity in an interactive group environment. The participants share their impressions, preferences, and needs, guided by a moderator.
force field analysis: A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces, depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces.
functional requirement: A capability that a solution must have in terms of the behaviour and information the solution will manage.

gap analysis: A comparison of the current state and desired future state of an enterprise in order to identify differences that need to be addressed.
goal: See business goal.
governance process (change): A process by which appropriate decision makers use relevant information to make decisions regarding a change or solution, including the means for obtaining approvals and priorities.

Glossary

guideline (business analysis): An instruction or description on why or how to undertake a task.

horizontal prototype: A prototype that is used to explore requirements and designs at one level of a proposed solution, such as the customer-facing view or the interface to another organization.

impact analysis: An assessment of the effects a proposed change will have on a stakeholder or stakeholder group, project, or system.
implementation subject matter expert: A stakeholder who has specialized knowledge regarding the implementation of one or more solution components.
indicator: A specific numerical measurement that indicates progress toward achieving an impact, output, activity, or input. See also metric.
initiative: A specific project, program, or action taken to solve some business problem(s) or achieve some specific change objective(s).
input (business analysis): Information consumed or transformed to produce an output. An input is the information necessary for a task to begin.
inspection: A formal review of a work product by qualified individuals that follows a predefined process, and uses predefined criteria, for defect identification and removal.
interface: A shared boundary between any two persons and/or systems through which information is communicated.
interoperability: Ability of systems to communicate by exchanging data or services.
interview: Eliciting information from a person or group of people in an informal or formal setting by asking relevant questions and recording the responses.
Ishikawa diagram: See fishbone diagram.
iteration (business analysis): A single instance of progressive cycles of analysis, development, testing, or execution.

knowledge area (business analysis): An area of expertise that includes several specific business analysis tasks.

lessons learned process: A process improvement technique used to learn about and improve on a process or project. A lessons learned session involves a special meeting in which the team explores what worked, what didn’t work, what could be learned from the just-completed iteration, and how to adapt processes and techniques before continuing or starting anew.

Glossary

life cycle: A series of changes an item or object undergoes from inception to retirement

matrix: A textual form of modelling used to represent information that can be categorized, cross-referenced, and represented in a table format.
metadata: A description of data to help understand how to use that data, either in terms of the structure and specification of the data, or the description of a specific instance of an object.
methodology: A body of methods, techniques, procedures, working concepts, and rules used to solve a problem
metric: A quantifiable level of an indicator measured at a specified point in time. mission statement: A formal declaration of values and goals that expresses the
core purpose of the enterprise.
model: A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication, and understanding.
monitoring: Collecting data on a continuous basis from a solution in order to determine how well a solution is implemented compared to expected results. See also metric; indicator.

need: A problem or opportunity to be addressed.
non-functional requirement: A type of requirement that describes the performance or quality attributes a solution must meet. Non-functional requirements are usually measurable and act as constraints on the design of a solution as a whole.

objective: See business objective.
observation (business analysis): Studying and analyzing one or more stakeholders in their work environment in order to elicit requirements.
OLAP: See online analytical processing.
online analytical processing (OLAP): A business intelligence approach that allows users to analyze large amounts of data from different points of view.
operational support: A stakeholder who is responsible for the day-to-day management and maintenance of a system or product.
operative rule: See behavioural business rule.
organization: An autonomous group of people under the management of a single individual or board, that works towards common goals and objectives.

Glossary

organizational capability: A function inside the enterprise, made up of components such as processes, technologies, and information and used by organizations to achieve their goals.
organizational change management: See change management. organization modelling: The analysis technique used to describe roles,
responsibilities and reporting structures that exist within an enterprise.
organizational unit: Any recognized association of people within an organization or enterprise.

peer review: A formal or informal review of a work product to identify errors or opportunities for improvement. See also inspection.
plan: A detailed scheme for doing or achieving something usually comprising a set of events, dependencies, expected sequence, schedule, results or outcomes, materials and resources needed, and how stakeholders need to be involved.
policy: See business policy.
predictive approach: An approach where planning and baselines are established early in the life cycle of the initiative in order to maximize control and minimize risk.
prioritization: Determining the relative importance of a set of items in order to determine the order in which they will be addressed.
process: A set of activities designed to accomplish a specific objective by taking one or more defined inputs and turning them into defined outputs.
process model: A set of diagrams and supporting information about a process and factors that could influence the process. Some process models are used to simulate the performance of the process.
product (business analysis): A solution or component of a solution that is the result of an initiative.
product backlog: A set of user stories, requirements, or features that have been identified as candidates for potential implementation, prioritized, and estimated.
product scope: See solution scope.
product vision statement: A brief statement or paragraph that describes the goals of the solution and how it supports the strategy of the organization or enterprise.
project: A temporary endeavour undertaken to create a unique product, service, or result.
project manager: A stakeholder who is 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 constraints,

including scope, budget, schedule, resources, quality, and risk.
Glossary

project scope: The work that must be performed to deliver a product, service, or result with the specified features and functions.
proof of concept: A model created to validate the design of a solution without modelling the appearance, materials used in the creation of work, or processes and workflows ultimately used by the stakeholders.
prototype: A partial or simulated approximation of the solution for the purpose of eliciting or verifying requirements with stakeholders.

quality: The degree to which a set of inherent characteristics fulfills needs. quality assurance: A set of activities performed to ensure that a process will
deliver products that meet an appropriate level of quality.
quality attributes: A set of measures used to judge the overall quality of a system.
See also non-functional requirements.
questionnaire: A set of defined questions, with a choice of answers, used to collect information from respondents.

RACI matrix: See responsible, accountable, consulted, and informed matrix. regulator: A stakeholder from outside the organization who is responsible for the
definition and enforcement of standards.
repository: A real or virtual facility where all information on a specific topic is stored and is available for retrieval.
request for information (RFI): A formal elicitation method intended to collect information regarding a vendor’s capabilities or any other information relevant to a potential upcoming procurement.
request for proposal (RFP): A requirements document issued when an organization is seeking a formal proposal from vendors. An RFP typically requires that the proposals be submitted following a specific process and using sealed bids which will be evaluated against a formal evaluation methodology.
request for quote (RFQ): A procurement method of soliciting price and solution options from vendors.
request for tender (RFT): An open invitation to vendors to submit a proposal for goods or services.
requirement: A usable representation of a need.
requirements attribute: A characteristic or property of a requirement used to assist with requirements management.

Glossary

requirements allocation: The process of assigning requirements to be implemented by specific solution components.
requirements architecture: The requirements of an initiative and the interrelationships between these requirements.
requirements artifact: A business analysis artifact containing information about requirements such as a diagram, matrix, document or model.
requirements defect: A problem or error in a requirement. Defects may occur because a requirement is poor quality (see requirements verification) or because it does not describe a need that, if met, would provide value to stakeholders (see requirements validation).
requirements document: See requirements package.
requirements life cycle: The stages through which a requirement progresses from inception to retirement.
requirements management: Planning, executing, monitoring, and controlling any or all of the work associated with requirements elicitation and collaboration, requirements analysis and design, and requirements life cycle management.
requirements management plan: A subset of the business analysis plan for a specific change initiative, describing specific tools, activities, and roles and responsibilities that will be used on the initiative to manage the requirements. See business analysis plan.
requirements management tool: Special-purpose software that provides support for any combination of the following capabilities: elicitation and collaboration, requirements modelling and/or specification, requirements traceability, versioning and baselining, attribute definition for tracking and monitoring, document generation, and requirements change control.
requirements model: An abstract (usually graphical) representation of some aspect of the current or future state.
requirements package: A specialized form of a business analysis package primarily concerned with requirements. A requirements package may represent a baseline of a collection of requirements.
requirements traceability: The ability for tracking the relationships between sets of requirements and designs from the original stakeholder need to the actual implemented solution. Traceability supports change control by ensuring that the source of a requirement or design can be identified and other related requirements and designs potentially affected by a change are known.
requirements validation: Work done to evaluate requirements to ensure they support the delivery of the expected benefits and are within the solution scope.
requirements verification: Work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution

Glossary

development team can use them in the design, development, and implementation of the solution.
requirements workshop: A structured meeting in which a carefully selected group of stakeholders collaborate to define and/or refine requirements under the guidance of a skilled neutral facilitator.
residual risk: The risk remaining after action has been taken or plans have been put in place to deal with the original risk.
retrospective: See lessons learned process.
return on investment (ROI) (business analysis): A measure of the profitability of a project or investment.
responsible, accountable, consulted, and informed matrix (RACI matrix): A tool used to identify the responsibilities of roles or team members and the activities or deliverables in which they will participate, by being responsible (doing the work), accountable (approving the results), consulted (providing input) or informed of the completed item after it has been completed.
RFI: See request for information. RFP: See request for proposal.
RFQ: See request for quote. RFT: See request for tender.
risk (business analysis): The effect of uncertainty on the value of a change, a solution, or the enterprise. See also residual risk.
risk assessment: Identifying, analyzing and evaluating risks. ROI: See return on investment.
root cause: The cause of a problem having no deeper cause, usually one of several possible causes.
root cause analysis: A structured examination of an identified problem to understand the underlying causes.

scope: The boundaries of control, change, a solution, or a need.
scope model: A model that defines the boundaries of a business domain or solution.
secondary actor: An actor external to the system under design that supports the execution of a use case.
sequence diagram: A type of diagram that shows objects participating in interactions and the messages exchanged between them.
service (business analysis): The performance of any duties or work for a stakeholder, from the perspective of the stakeholder.
SIPOC: See suppliers, inputs, process, outputs and customers.

Glossary

SME: See subject matter expert. software engineer: See developer.
solution: A specific way of satisfying one or more needs in a context.
solution component: A sub-part of a solution that can be people, infrastructure, hardware, software, equipment, facilities, and process assets or any combination of these sub-parts.
solution option: One possible way to satisfy one or more needs in a context. solution requirement: A capability or quality of a solution that meets the
stakeholder requirements. Solution requirements can be divided into two
sub-categories: functional requirements and non-functional requirements or quality of service requirements.
solution life cycle: The stages through which a solution progresses from inception to retirement.
solution scope: The set of capabilities a solution must deliver in order to meet the business need.
SOW: See statement of work.
sponsor: A stakeholder who is 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.
stakeholder: A group or individual with a relationship to the change, the need, or the solution.
stakeholder analysis: Identifying and analyzing the stakeholders who may be impacted by the change and assess their impact, participation, and needs throughout the business analysis activities.
stakeholder list: A catalogue of the stakeholders affected by a change, business need, or proposed solution, and a description of their attributes and characteristics related to their involvement in the initiative.
stakeholder proxy (business analyst): The role a business analyst takes when representing the needs of a stakeholder or stakeholder group.
stakeholder requirement: A description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.
state diagram: An analysis model showing the life cycle of a data entity or class. stated requirement: A requirement articulated by a stakeholder that has not been
analyzed, verified, or validated. Stated requirements frequently reflect the
desires of a stakeholder rather than the actual need.
statement of work (SOW): A written description of the services or tasks that are required to be performed.

Glossary

strategy: A description of the chosen approach to apply the capabilities of an enterprise in order to reach a desired set of goals or objectives.
strengths, weaknesses, opportunities, and threats analysis (SWOT): An analysis model used to understand influencing factors and how they may affect an initiative. Also known as SWOT analysis.
structural rule: See definitional business rule.
subject matter expert (SME): See domain subject matter expert; implementation subject matter expert.
supplier: A stakeholder outside the boundary of a given organization or organizational unit who provides products or services to the organization and may have contractual or moral rights and obligations that must be considered.
suppliers, inputs, process, outputs, and customers (SIPOC): A tool used to describe relevant high-level elements of a process. May be used in conjunction with process mapping and ‘in/out of scope’ tools, to provide additional detail.
survey: Collecting and measuring the opinions or experiences of a group of people through a series of questions.
swimlane: A horizontal or vertical section of a process diagram that shows which activities are performed by a particular actor or role.
SWOT analysis: See strengths, weaknesses, opportunities and threats analysis.
system: A set of interdependent components that interact in various ways to produce a set of desired outcomes.

task (business analysis): A discrete piece of work that may be performed formally or informally as part of business analysis.
technique: A manner, method, or style for conducting a business analysis task or for shaping its output.
temporal event: An event based on time that can trigger the initiation of a process, evaluation of business rules, or some other response.
tester: An individual responsible for determining how to verify that the solution meets the requirements defined by the business analyst, and conducting the verification process.
throw-away prototype: A prototype used to quickly uncover and clarify requirements or designs using simple tools, sometimes just paper and pencil. It is intended to be discarded when the final system has been developed.
time-box: An agreed-upon period of time in which an activity is conducted or a defined deliverable is intended to be produced.
traceability: See requirements traceability.

Glossary

transition requirement: A requirement that describes the capabilities 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.

UAT: See user acceptance test.
UML®: See unified modelling language.
unified modelling language™ A notation specified by the Object Management Group for describing software application structure, behaviour, and architecture. It can also be used for describing business processes and data structures. The most common UML® diagrams used by business analysts are
use case diagrams, activity diagrams, state machine diagrams (also known as state diagrams), and class diagrams.
use case: A description of the observable interaction between an actor (or actors) and a solution that occurs when the actor uses the system to accomplish a specific goal.
use case diagram: A type of diagram defined by UML® that captures all actors and use cases involved with a system or product.
user: See end user.
user acceptance test (UAT): Assessing whether the delivered solution meets the needs of the stakeholder group that will be using the solution. The assessment is validated against identified acceptance criteria.
user requirement: See stakeholder requirement.
user story: A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.

validation (business analysis): The process of checking that a deliverable is suitable for its intended use. See also requirements validation.
validated requirement: A requirement that has been reviewed and is determined to support the delivery of the expected benefits, and is within the solution scope.
value (business analysis): The worth, importance, or usefulness of something to a stakeholder in a context.
value stream mapping: A complete, fact-based, time-series representation of the stream of activities required to deliver a product or service.
verification (business analysis): The process of determining that a deliverable or artifact meets an acceptable standard of quality. See also requirements verification.

Glossary

verified requirement: A requirement that has been reviewed and is determined to be defined correctly, adheres to standards or guidelines, and is at an acceptable level of detail.
vertical prototype: A prototype that is used to drill down into a proposed solution to uncover requirement and design considerations through multiple layers of a solution that are not easily understood or that are not discernible on the surface. It may include interaction between several solution components.
viewpoint: A set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related.
VSM: See value stream mapping.

walkthrough: A review in which participants step through an artifact or set of artifacts with the intention of validating the requirements or designs, and to identify requirements or design errors, inconsistencies, omissions, inaccuracies, or conflicts.
WBS: See work breakdown structure.
work breakdown structure (WBS): A deliverable-oriented hierarchical decomposition of the work to be executed to accomplish objectives and create the required deliverables. It organizes and defines the total scope of the project.
work product (business analysis): A document or collection of notes or diagrams used by the business analyst during the requirements development process.
Workshop: A facilitated and focused event attended by key stakeholders for the purpose of achieving a defined goal.

Techniques to Task Mapping

Appendix B: Techniques to Task Mapping

The following table shows each BABOK® _Guide _task in which the technique is included in the Techniques section.
This mapping is provided for reference purposes and does not preclude the creative use of any technique during the application of any other task in which it is not specifically listed.

Complimentary IIBA® Member Copy. Not for Distribution or Resale.

10.2. BacklogManagement

10.3. BalancedScorecard

5.3. PrioritizeRequirements

6.2. Define FutureState
6.4. Define ChangeStrategy
7.3. ValidateRequirements
7.6. Analyze PotentialValueandRecommendSolution
7.6. Analyze PotentialValueandRecommendSolution
Measures
8.3. Assess SolutionLimitations

10.5.
Brainstorming
3.1. Plan BusinessAnalysisApproach
3.2. Plan StakeholderEngagement
3.3. PlanBusinessAnalysisGovernance
3.4. PlanBusinessAnalysis InformationManagement
3.5. Identify Business Analysis PerformanceImprovements
4.1. PrepareforElicitation
4.2. ConductElicitation
6.2. DefineFutureState
6.3. AssessRisks
6.4. DefineChangeStrategy
7.5. DefineDesignOptions
7.6. Analyze PotentialValueandRecommendSolution
8.4. Assess EnterpriseLimitations

Complimentary IIBA® Member Copy. Not for Distribution or Resale.

10.7. BusinessCases

10.8. BusinessModelCanvas

10.9. BusinessRulesAnalysis
3.1. Plan BusinessAnalysisApproach

3.2. Plan StakeholderEngagement

4.2. ConductElicitation
5.3. PrioritizeRequirements
5.4. AssessRequirementsChanges

5.2. MaintainRequirements
5.4. AssessRequirementsChanges
6.1. AnalyzeCurrentState
6.2. DefineFutureState
6.3. AssessRisks
6.4. DefineChangeStrategy
6.1. AnalyzeCurrentState
6.2. DefineFutureState
6.4. Define ChangeStrategy
7.6. Analyze PotentialValueandRecommendSolution

7.1. Specify and ModelRequirements
7.6. Analyze PotentialValueandRecommendSolution
7.1. Specify and ModelRequirements
8.1. Measure SolutionPerformance

8.3. Assess SolutionLimitations

10.11. ConceptModelling

10.12. DataDictionary

10.13. DataFlowDiagrams

10.14. DataMining
4.2.ConductElicitation

4.1. PrepareforElicitation
4.2. ConductElicitation

5.2. MaintainRequirements
6.1. AnalyzeCurrentState

6.1. AnalyzeCurrentState
7.1. SpecifyandModelRequirements
7.1. SpecifyandModelRequirements
7.1. SpecifyandModelRequirements

8.1. MeasureSolutionPerformance
8.2. AnalyzePerformanceMeasures
8.3. AssessSolutionLimitations
8.4. AssessEnterpriseLimitations
8.5. Recommend Actions toIncreaseSolutionValue

Complimentary IIBA® Member Copy. Not for Distribution or Resale.

10.17. DecisionModelling

10.18. DocumentAnalysis

3.1. Plan BusinessAnalysisApproach
3.2. Plan StakeholderEngagement
3.3. PlanBusinessAnalysisGovernance

4.1. PrepareforElicitation
4.2. ConductElicitation
4.3. ConfirmElicitationResults

5.2. MaintainRequirements
5.4. AssessRequirementsChanges
6.2. Define FutureState

6.1. AnalyzeCurrent State
6.3. Assess Risks
7.1. SpecifyandModelRequirements
7.3. ValidateRequirements
7.5. Define DesignOptions

8.4. Assess EnterpriseLimitations

Solution

10.21. FocusGroups

10.22. FunctionalDecomposition

3.1. Plan BusinessAnalysis Approach
4.2. ConductElicitation

5.1. TraceRequirements
5.2. MaintainRequirements
6.1. AnalyzeCurrent State
6.4. Define ChangeStrategy

6.1. AnalyzeCurrentState
6.2. DefineFutureState
6.4. Define ChangeStrategy
7.6. Analyze PotentialValueandRecommendSolution

7.1. Specify and ModelRequirements
7.4. DefineRequirementsArchitecture
8.1. Measure SolutionPerformance
8.5. Recommend Actions to IncreaseSolution Value

10.23.Glossary 7.1. Specifyand
Model Requirements

Complimentary IIBA® Member Copy. Not for Distribution or Resale.

10.25. Interviews 3.1. Plan Business
Analysis Approach
3.2. Plan StakeholderEngagement
3.3. PlanBusinessAnalysisGovernance
3.4. PlanBusinessAnalysis InformationManagement
3.5. Identify Business Analysis PerformanceImprovements
4.1. PrepareforElicitation
4.2. ConductElicitation
4.3. ConfirmElicitationResults
4.4. CommunicateBusiness AnalysisInformation
5.3. PrioritizeRequirements
5.4. AssessRequirementsChanges
6.1. AnalyzeCurrentState
6.2. DefineFutureState
6.3. AssessRisks
6.4. DefineChangeStrategy
7.4. DefineRequirementsArchitecture
7.5. DefineDesignOptions
7.6. Analyze PotentialValueandRecommendSolution
8.2. AnalyzePerformanceMeasures
8.3. AssessSolutionLimitations
8.4. AssessEnterpriseLimitations

Complimentary IIBA® Member Copy. Not for Distribution or Resale.

3.2. Plan StakeholderEngagement
3.3. PlanBusinessAnalysis
Collaboration
6.2. DefineFutureState
6.3. AssessRisks
6.4. DefineChangeStrategy
8.4. Assess EnterpriseLimitations

10.30. Non- FunctionalRequirementsAnalysis
10.31.
Observation

10.32.
Organizational Modelling
Engagement
3.4. PlanBusinessAnalysis InformationManagement

3.5. Identify Business Analysis PerformanceImprovements

3.3. Plan Business AnalysisGovernance
4.2.ConductElicitation

4.2.ConductElicitation
6.2. DefineFutureState
6.3. AssessRisks
6.4. DefineChangeStrategy

6.1. AnalyzeCurrent State

6.1. AnalyzeCurrentState
6.2. DefineFutureState
6.4. Define ChangeStrategy

7.1. SpecifyandModelRequirements

7.1. SpecifyandModelRequirements
7.4. DefineRequirementsArchitecture

8.1.MeasureSolutionPerformance

8.1. MeasureSolutionPerformance
8.2. AnalyzePerformanceMeasures
8.4.AssessEnterpriseLimitations
8.4. AssessEnterpriseLimitations
8.5. Recommend Actions toIncreaseSolutionValue

Complimentary IIBA® Member Copy. Not for Distribution or Resale.

10.39. Roles and PermissionsMatrix
8.4. Assess EnterpriseLimitations

Complimentary IIBA® Member Copy. Not for Distribution or Resale.

10.41. ScopeModelling

10.42. SequenceDiagrams

10.43.
Stakeholder List, Map, orPersonas

10.44. StateModelling
3.2. Plan StakeholderEngagement

4.1. Prepare forElicitation
4.5. Manage StakeholderCollaboration
6.1. AnalyzeCurrentState
6.2. DefineFutureState
6.4. Define ChangeStrategy
7.1. Specify and ModelRequirements
7.4. DefineRequirementsArchitecture
7.1. SpecifyandModelRequirements
7.1. SpecifyandModelRequirements

7.1. SpecifyandModelRequirements

10.46. SWOTAnalysis

10.47. UseCasesandScenarios

10.48. UserStories
Engagement
3.3. PlanBusinessAnalysisGovernance
3.4. PlanBusinessAnalysis InformationManagement
3.5. Identify Business Analysis PerformanceImprovements

5.2. MaintainRequirements

5.2. MaintainRequirements
6.2. DefineFutureState
6.3. AssessRisks

6.1. AnalyzeCurrentState
6.2. DefineFutureState
6.4. Define ChangeStrategy
7.6. Analyze PotentialValueandRecommendSolution

7.6. Analyze PotentialValueandRecommendSolution

7.1. SpecifyandModelRequirements
7.1. SpecifyandModelRequirements
Performance
8.2. AnalyzePerformanceMeasures
8.3. AssessSolutionLimitations
8.4. AssessEnterpriseLimitations
8.5. Recommend Actions toIncreaseSolutionValue
8.4. Assess EnterpriseLimitations

8.1. MeasureSolutionPerformance

Complimentary IIBA® Member Copy. Not for Distribution or Resale.