Techniques

The Techniques chapter provides a high-level overview of the techniques referenced in the Knowledge Areas of the BABOK® Guide. Techniques are methods business analysts use to perform business analysis tasks.
The techniques described in the BABOK® Guide _are intended to cover the most common and widespread techniques practiced within the business analysis community. Business analysts apply their experience and judgment in determining which techniques are appropriate to a given situation and how to apply each
technique. This may include techniques that are not described in the _BABOK®
Guide. As the practice of business analysis evolves, techniques will be added, changed, or removed from future iterations of the BABOK® Guide.
In a number of cases, a set of conceptually similar approaches have been grouped into a single technique. Any approach within a technique may be used individually or in combination to accomplish the technique’s purpose.

10.1 Acceptance and Evaluation Criteria

10.1.1 Purpose

Acceptance criteria are used to define the requirements, outcomes, or conditions that must be met in order for a solution to be considered acceptable to key stakeholders. Evaluation criteria are the measures used to assess a set of requirements in order to choose between multiple solutions.

10.1.2 Description

Acceptance and evaluation criteria define measures of value attributes to be used for assessing and comparing solutions and alternative designs. Measurable and testable criteria allow for the objective and consistent assessment of solutions and designs. The Acceptance and Evaluation Criteria technique can apply at all levels of a project, from high-level to a more detailed level.
Acceptance criteria describe the minimum set of requirements that must be met in order for a particular solution to be worth implementing. They may be used to determine if a solution or solution component can meet a requirement.
Acceptance criteria are typically used when only one possible solution is being evaluated, and are generally expressed as a pass or fail.
Evaluation criteria define a set of measurements which allow for ranking of solutions and alternative designs according to their value for stakeholders. Each evaluation criterion represents a continuous or discrete scale for measuring a specific solution attribute such as cost, performance, usability, and how well the functionality represents the stakeholders’ needs. Attributes that cannot be measured directly are evaluated using expert judgment or various scoring techniques.
Both evaluation and acceptance criteria may be defined with the same value attributes. When evaluating various solutions, the solutions with lower costs and better performance may be rated higher. When accepting a solution, the criteria are written using minimum performance requirements and maximum cost limits in contractual agreements and user acceptance tests.

10.1.3 Elements

.1 Value Attributes

Value attributes are the characteristics of a solution that determine or substantially influence its value for stakeholders. They represent a meaningful and agreed-upon decomposition of the value proposition into its constituent parts, which can be described as qualities that the solution should either possess or avoid.
Examples of value attributes include:
• ability to provide specific information,
• ability to perform or support specific operations,
• performance and responsiveness characteristics,
• applicability of the solution in specific situations and contexts,
• availability of specific features and capabilities, and
• usability, security, scalability, and reliability.

Basing acceptance and evaluation criteria on value attributes ensures that they are valid and relevant to stakeholder needs and should be considered when accepting and evaluating the solution. Business analysts ensure that the definition of all value attributes are agreed upon by all stakeholders. Business analysts may design tools and instructions for performing the assessment as well as for recording and processing its results.

Figure 10.1.1: Acceptance and Evaluation Criteria

One Solution

Multiple Solutions

.2 Assessment

In order to assess a solution against acceptance or evaluation criteria, it must be constructed in a measurable format.

Testability

Acceptance criteria are expressed in a testable form. This may require breaking requirements down into an atomic form so that test cases can be written to verify the solution against the criteria. Acceptance criteria are presented in the form of statements which can be verified as true or false. This is often achieved through user acceptance testing (UAT).

Measures

Evaluation criteria provide a way to determine if features provide the value necessary to satisfy stakeholder needs. The criteria are presented as parameters that can be measured against a continuous or discrete scale. The definition of each criterion allows the solution to be measured through various methods such as benchmarking or expert judgment. Defining evaluation criteria may involve designing tools and instructions for performing the assessment, as well as for recording and processing its results.

10.1.4 Usage Considerations

.1 Strengths

• Agile methodologies may require that all requirements be expressed in the form of testable acceptance criteria.
• Acceptance criteria are necessary when the requirements express contractual obligations.
• Acceptance criteria provide the ability to assess requirements based on agreed- upon criteria.
• Evaluation criteria provide the ability to assess diverse needs based on agreed- upon criteria, such as features, common indicators, local or global benchmarks, and agreed ratios.
• Evaluation criteria assist in the delivery of expected return on investment (ROI) or otherwise specified potential value.
• Evaluation criteria helps in defining priorities.

.2 Limitations

• Acceptance criteria may express contractual obligations and as such may be difficult to change for legal or political reasons.
• Achieving agreement on evaluation criteria for different needs among diverse stakeholders can be challenging.

10.2 Backlog Management

10.2.1 Purpose

The backlog is used to record, track, and prioritize remaining work items.

10.2.2 Description

A backlog occurs when the volume of work items to be completed exceeds the capacity to complete them.
Backlog management refers to the planned approach to determine:
• what work items should be formally included in the backlog,
• how to describe the work items,
• how the work items should be tracked,
• how the work items should be periodically reviewed and prioritized in relation to all other items in the backlog,
• how the work items are eventually selected to be worked on, and
• how the work items are eventually removed from the backlog.

In a managed backlog, the items at the top have the highest business value and the highest priority. These are normally the next items to be selected to be worked on.
Periodic review of the entire backlog should occur because changes in stakeholder needs and priorities may necessitate changes to the priority of some of the backlog items. In many environments, the backlog is reviewed at planned intervals.
The changes to the number of items in the backlog are regularly monitored. The root causes for these changes are investigated: a growing backlog could indicate an increase in demand or a drop in productivity; a declining backlog could indicate a drop in demand or improvements in the production process.
There may be more than one backlog. For example, one backlog may be used to manage a global set of items, while a second backlog may be used to manage the items that are due to be worked on within the very near future.

10.2.3 Elements

.1 Items in the Backlog

Backlog items may be any kind of item which may have work associated with it. A backlog may contain, but is not limited to, any combination of the following items:

• use cases,
• user stories,
• functional requirements,
• non-functional requirements,
• designs,
• customer orders,
• risk items,
• change requests,
• defects,
• planned rework,
• maintenance,
• conducting a presentation, or
• completing a document.

An item is added to the backlog if it has value to a stakeholder. There may be one person with the authority to add new items to the backlog, or there could be a committee which adds new items based on a consensus. In some cases, the responsibility for adding new items may be delegated to the business analyst.
There may also be policies and rules which dictate what is to be added and when, as may be the case with major product defects.

.2 Prioritization

Items in the backlog are prioritized relative to each other. Over time, these priorities will change as stakeholders’ priorities change, or as dependencies between backlog items emerge. Rules on how to manage the backlog may also impact priority.
A multi-phased prioritization approach can also be used. When items are first added to the backlog, the prioritization may be very broad, using categories such

Backlog Management Techniques

as high, medium, or low. The high priority items tend to be reviewed more frequently since they are likely candidates for upcoming work. To differentiate between the high priority items, a more granular approach is used to specify the relative priority to other high priority items, such as a numerical ranking based on some measure of value.

.3 Estimation

The level of detail used to describe each backlog item may vary considerably. Items near the top of the backlog are usually described in more detail, with a correspondingly accurate estimate about their relative size and complexity that would help to determine the cost and effort to complete them. When an item is first added, there may be very little detail included, especially if the item is not likely to be worked on in the near term.
A minimal amount of work is done on each item while it is on the backlog; just enough to be able to understand the work involved to complete it. As the work progresses on other items in the backlog, an individual item’s relative priority may rise, leading to a need to review it and possibly further elaborate or decompose it to better understand and estimate its size and complexity.
Feedback from the production process about the cost and effort to complete earlier items can be used to refine the estimates of items still in the backlog.

.4 Managing Changes to the Backlog

Items make their way to the top of the backlog based on their relative priority to other items in the backlog. When new or changed requirements are identified, they are added to the backlog and ordered relative to the other items already there.
Whenever work capacity becomes available the backlog is reviewed and items are selected based on the available capacity, dependencies between items, current understanding of the size, and complexity.
Items are removed from the backlog when they are completed, or if a decision has been made to not do any more work on them. However, removed items can be re-added to the backlog for a variety of reasons, including:
• stakeholder needs could change significantly,
• it could be more time-consuming than estimated,
• other priority items could take longer to complete than estimated, or
• the resulting work product might have defects.

10.2.4 Usage Considerations

.1 Strengths

• An effective approach to responding to changing stakeholder needs and priorities because the next work items selected from the backlog are always

aligned with current stakeholder priorities.
• Only items near the top of the backlog are elaborated and estimated in detail; items near the bottom of the backlog reflect lower priorities and receive less attention and effort.
• Can be an effective communication vehicle because stakeholders can understand what items are about to be worked on, what items are scheduled farther out, and which ones may not be worked on for some time.

.2 Limitations

• Large backlogs may become cumbersome and difficult to manage.
• It takes experience to be able to break down the work to be done into enough detail for accurate estimation.
• A lack of detail in the items in the backlog can result in lost information over time.

10.3 Balanced Scorecard

10.3.1 Purpose

The balanced scorecard is used to manage performance in any business model, organizational structure, or business process.

10.3.2 Description

The balanced scorecard is a strategic planning and management tool used to measure organizational performance beyond the traditional financial measures. It is outcome focused and provides a balanced view of an enterprise by implementing the strategic plan as an active framework of objectives and performance measures. The underlying premise of the balanced scorecard is that the drivers of value creation are understood, measured, and optimized in order to create sustainable performance.
The balanced scorecard is composed of four dimensions:
• Learning and Growth,
• Business Process,
• Customer, and
• Financial.
The balanced scorecard includes tangible objectives, specific measures, and targeted outcomes derived from an organization’s vision and strategy. Balanced business scorecards can be used at multiple levels within an organization. This includes at an enterprise-wide level (macro level), departmental or function level, and even at the level of a project or initiative.

**

Figure 10.3.1: Balanced Scorecard

To succeed financially, how should we appear to our shareholders?
Financial
Objectives Measures Targets

To satisfy our

To achieve our vision, how should we appear to our customers?
Customer
Objectives Measures Targets Initiatives
Initiatives

Vision and Strategy
shareholders and customers, what business processes must we excel at?
Internal Business Process
Objectives Measures Targets Initiatives

Learning and Growth
Objectives Measures Targets Initiatives
To achieve our vision, how will we sustain our ability to change and improve?

10.3.3 Elements

.1 Learning and Growth Dimension

The Learning and Growth dimension includes measures regarding employee training and learning, product and service innovation, and corporate culture. Metrics guide the use of training funds, mentoring, knowledge sharing, and technology improvements.

.2 Business Process Dimension

The Business Process dimension includes metrics that indicate how well the enterprise is operating and if their products meet customer needs.

.3 Customer Dimension

The Customer dimension includes metrics on customer focus, satisfaction and delivery of value. These metrics capture how well customer needs are met, how satisfied they are with products and services, whether the delivery of those products and services meet their quality expectations, and their overall experience with the enterprise.

.4 Financial Dimension

The Financial dimension identifies what is financially necessary to realize the strategy. Examples of financial measures indicate profitability, revenue growth, and added economic value.

.5 Measures or Indicators

There are two basic types of measures or indicators: lagging indicators that provide results of actions already taken and leading indicators that provide information about future performance.
Objectives tend to have lagging indicators, but using related leading indicators can provide more real-time performance information.

10.3.4 Usage Considerations

In order for measures to be meaningful they should be quantitative, linked to strategy, and easily understood by all stakeholders. When defining measures, business analysts consider other relevant measures that are in place and ensure that any new or changed measures do not adversely impact any existing ones. At any time, any dimension of the balanced scorecard may be active, changing, and evolving. Each dimension affects and is affected by the others. The balanced scorecard allows the organization to establish monitoring and measuring of progress against objectives and to adapt strategy as needed.
Because scorecards are used to assess the performance of the enterprise or a business unit within the enterprise, changes to the measures can have wide reaching implications and must be clearly communicated and carefully managed.

.1 Strengths

• Facilitates holistic and balanced planning and thinking.
• Short-, medium-, and long-term goals can be harmonized into programs with incremental success measures.
• Strategic, tactical, and operational teams are more easily aligned in their work.
• Encourages forward thinking and competitiveness.

.2 Limitations

• A lack of a clear strategy makes aligning the dimensions difficult.
• Can be seen as the single tool for strategic planning rather than just one tool to be used in a suite of strategic planning tools.
• Can be misinterpreted as a replacement for strategic planning, execution, and measurement.

10.4 Benchmarking and Market Analysis

10.4.1 Purpose

Benchmarking and market analysis are conducted to improve organizational operations, increase customer satisfaction, and increase value to stakeholders.

10.4.2 Description

Benchmark studies are conducted to compare organizational practices against the best-in-class practices. Best practices may be found in competitor enterprises, in government, or from industry associations. The objective of benchmarking is to evaluate enterprise performance and ensure that the enterprise is operating efficiently. Benchmarking may also be performed against standards for compliance purposes. The results from the benchmark study may initiate change within an organization.
Market analysis involves researching customers in order to determine the products and services that they need or want, the factors that influence their decisions to purchase, and the competitors that exist in the market. The objective of market analysis is to acquire this information in order to support the various decision-making processes within an organization. Market analysis can also help determine when to exit a market. It may be used to determine if partnering, merging, or divesting are viable alternatives for an enterprise.

10.4.3 Elements

.1 Benchmarking

Benchmarking includes:
• identifying the areas to be studied,
• identifying enterprises that are leaders in the sector (including competitors),
• conducting a survey of selected enterprises to understand their practices,
• using a Request for Information (RFI) to gather information about capabilities,
• arranging visits to best-in-class organizations,
• determining gaps between current and best practices, and
• developing a project proposal to implement best practices.

.2 Market Analysis

Market Analysis requires that business analysts:
• identify customers and understand their preferences,
• identify opportunities that may increase value to stakeholders,
• identify competitors and investigate their operations,

• look for trends in the market, anticipate growth rate, and estimate potential profitability,
• define appropriate business strategies,
• gather market data,
• use existing resources such as company records, research studies, and books and apply that information to the questions at hand, and
• review data to determine trends and draw conclusions.

10.4.4 Usage Considerations

.1 Strengths

• Benchmarking provides organizations with information about new and different methods, ideas, and tools to improve organizational performance.
• An organization may use benchmarking to identify best practices by its competitors in order to meet or exceed its competition.
• Benchmarking identifies why similar companies are successful and what processes they used to become successful.
• Market analysis can target specific groups and can be tailored to answer specific questions.
• Market analysis may expose weaknesses within a certain company or industry.
• Market analysis may identify differences in product offerings and services that are available from a competitor.

.2 Limitations

• Benchmarking is time-consuming; organizations may not have the expertise to conduct the analysis and interpret useful information.
• Benchmarking cannot produce innovative solutions or solutions that will produce a sustainable competitive advantage because it involves assessing solutions that have been shown to work elsewhere with the goal of reproducing them.
• Market analysis can be time-consuming and expensive, and the results may not be immediately available.
• Without market segmentation, market analysis may not produce the expected results or may provide incorrect data about a competitor’s products or services.

10.5 Brainstorming

10.5.1 Purpose

Brainstorming is an excellent way to foster creative thinking about a problem. The aim of brainstorming is to produce numerous new ideas, and to derive from them themes for further analysis.

10.5.2 Description

Brainstorming is a technique intended to produce a broad or diverse set of options.
It helps answer specific questions such as (but not limited to):
• What options are available to resolve the issue at hand?
• What factors are constraining the group from moving ahead with an approach or option?
• What could be causing a delay in activity ‘A’?
• What can the group do to solve problem ‘B’?
Brainstorming works by focusing on a topic or problem and then coming up with many possible solutions to it. This technique is best applied in a group as it draws on the experience and creativity of all members of the group. In the absence of a group, one could brainstorm on one’s own to spark new ideas. To heighten creativity, participants are encouraged to use new ways of looking at things and freely associate in any direction. When facilitated properly, brainstorming can be fun, engaging, and productive.

Figure 10.5.1: Brainstorming

1. Preparation

2. Session

3. Wrap-up

**

10.5.3 Elements

.1 Preparation

• Develop a clear and concise definition of the area of interest.
• Determine a time limit for the group to generate ideas; the larger the group, the more time required.
• Identify the facilitator and participants in the session (aim for six to eight participants who represent a range of backgrounds and experience with the topic).
• Set expectations with participants and get their buy-in to the process.
• Establish the criteria for evaluating and rating the ideas.

.2 Session

• Share new ideas without any discussion, criticism, or evaluation.
• Visibly record all ideas.
• Encourage participants to be creative, share exaggerated ideas, and build on the ideas of others.
• Don’t limit the number of ideas as the goal is to elicit as many as possible within the time period.

.3 Wrap-up

• Once the time limit is reached, discuss and evaluate the ideas using the predetermined evaluation criteria.
• Create a condensed list of ideas, combine ideas where appropriate, and eliminate duplicates.
• Rate the ideas, and then distribute the final list of ideas to the appropriate parties.

10.5.4 Usage Considerations

.1 Strengths

• Ability to elicit many ideas in a short time period.
• Non-judgmental environment enables creative thinking.
• Can be useful during a workshop to reduce tension between participants.

.2 Limitations

• Participation is dependent on individual creativity and willingness to participate.
• Organizational and interpersonal politics may limit overall participation.
• Group participants must agree to avoid debating the ideas raised during brainstorming.

10.6 Business Capability Analysis

10.6.1 Purpose

Business capability analysis provides a framework for scoping and planning by generating a shared understanding of outcomes, identifying alignment with strategy, and providing a scope and prioritization filter.

10.6.2 Description

Business capability analysis describes what an enterprise, or part of an enterprise, is able to do. Business capabilities describe the ability of an enterprise to act on or transform something that helps achieve a business goal or objective. Capabilities may be assessed for performance and associated risks to identify specific performance gaps and prioritize investments. Many product development efforts are an attempt to improve the performance of an existing business capability or to deliver a new one. As long as an enterprise continues to perform similar functions, the capabilities required by the enterprise should remain constant—even if the method of execution for those capabilities undergoes significant change.

10.6.3 Elements

.1 Capabilities

Capabilities are the abilities of an enterprise to perform or transform something that helps achieve a business goal or objective. Capabilities describe the purpose or outcome of the performance or transformation, not how the performance or transformation is performed. Each capability is found only once on a capability map, even if it is possessed by multiple business units.

.2 Using Capabilities

Capabilities impact value through increasing or protecting revenue, reducing or preventing cost, improving service, achieving compliance, or positioning the company for the future. Not all capabilities have the same level of value. There are various tools that can be used to make value explicit in a capability assessment.

.3 Performance Expectations

Capabilities can be assessed to identify explicit performance expectations. When a capability is targeted for improvement, a specific performance gap can be identified. The performance gap is the difference between the current performance and the desired performance, given the business strategy.

.4 Risk Model

Capabilities alone do not have risks—the risks are in the performance of the capability, or in the lack of performance.

These risks fall into the usual business categories:
• business risk,
• technology risk,
• organizational risk, and
• market risk.

.5 Strategic Planning

Business capabilities for the current state and future state of an enterprise can be used to determine where that enterprise needs to go in order to accomplish its strategy. A business capability assessment can produce a set of recommendations or proposals for solutions. This information forms the basis of a product roadmap and serves as a guide for release planning. At the strategic level, capabilities should support an enterprise in establishing and maintaining a sustainable competitive advantage and a distinct value proposition.

.6 Capability Maps

Capability maps provide a graphical view of elements involved in business capability analysis. The following examples demonstrate one element of a capability map that would be part of a larger capabilities grid.
There is no set standard for the notation of capabilities maps. The following images show two different methods for creating a capability map. The first two images are the first example and the third image is the second example.

Figure 10.6.1: Sample Capability Map Example 1 Cell

**

Business Value
Explicit Performance Gaps

ustomer Value
**

usiness Risk
echnology Risk rganizational Risk

Business Value Analysis Centre of Excellence

10.6.4 Usage Considerations

.1 Strengths

• Provides a shared articulation of outcomes, strategy, and performance, which help create very focused and aligned initiatives.
• Helps align business initiatives across multiple aspects of the organization.
• Useful when assessing the ability of an organization to offer new products and services.

.2 Limitations

• Requires an organization to agree to collaborate on this model.

• When created unilaterally or in a vacuum it fails to deliver on the goals of alignment and shared understanding.
• Requires a broad, cross–functional collaboration in defining the capability model and the value framework.

10.7 Business Cases

10.7.1 Purpose

A business case provides 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.

10.7.2 Description

A business case captures the rationale for undertaking a change. A business case is frequently presented in a formal document, but may also be presented through informal methods. The amount of time and resources spent on the business case should be proportional to the size and importance of its potential value. The business case provides sufficient detail to inform and request approval without providing specific intricacies about the method and/or approach to the implementation. It may also be the catalyst for one or many initiatives in order to implement the change.
A business case is used to:
• define the need,
• determine the desired outcomes,
• assess constraints, assumptions, and risks, and
• recommend a solution.

10.7.3 Elements

.1 Need Assessment

The need is the driver for the business case. It is the relevant business goal or objective that must be met. Objectives are linked to a strategy or the strategies of the enterprise. The need assessment identifies the problem or the potential opportunity. Throughout the development of the business case, different alternatives to solve the problem or take advantage of the opportunity will be assessed.

.2 Desired Outcomes

The desired outcomes describe the state which should result if the need is fulfilled. They should include measurable outcomes that can be utilized to determine the success of the business case or the solution. Desired outcomes

Techniques Business Cases

should be revisited at defined milestones and at the completion of the initiative (or initiatives) to fulfill the business case. They should also be independent of the recommended solution. As solution options are assessed, their ability to achieve the desired outcomes will help determine the recommended solution.

.3 Assess Alternatives

The business case identifies and assesses various alternative solutions. Alternatives may include (but are not limited to) different technologies, processes, or business models. Alternatives may also include different ways of acquiring these and different timing options. They will be affected by constraints such as budget, timing, and regulatory. The ‘do-nothing’ alternative should be assessed and considered for the recommended solution.
Each alternative should be assessed in terms of:
• Scope: defines the alternative being proposed. Scope can be defined using organizational boundaries, system boundaries, business processes, product lines or geographic regions. Scope statements clearly define what will be included and what will be excluded. The scope of various alternatives may be similar or have overlap but may also differ based on the alternative.
• Feasibility: The organizational and technical feasibility should be assessed for each alternative. It includes organizational knowledge, skills, and capacity, as well as technical maturity and experience in the proposed technologies.
• Assumptions, Risks, and Constraints: Assumptions are agreed-to facts that may have influence on the initiative. Constraints are limitations that may restrict the possible alternatives. Risks are potential problems that may have a negative impact on the solution. Agreeing to and documenting these factors facilitates realistic expectations and a shared understanding amongst stakeholders.
• Financial Analysis and Value Assessment: The financial analysis and value assessment includes an estimate of the costs to implement and operate the alternative, as well as a quantified financial benefit from implementing the alternative. Benefits of a non-financial nature (such as improved staff morale, increased flexibility to respond to change, improved customer satisfaction, or reduced exposure to risk) are also important and add significant value to the organization. Value estimates are related back to strategic goals and objectives.

.4 Recommended Solution

The recommended solution describes the most desirable way to solve the problem or leverage the opportunity. The solution is described in sufficient detail for decision makers to understand the solution and determine if the recommendation will be implemented. The recommended solution may also include some estimates of cost and duration to implement the solution.
Measurable benefits/outcomes will be identified to allow stakeholders to assess

the performance and success of the solution after implementation and during operation.

10.7.4 Usage Considerations

.1 Strengths

• Provides an amalgamation of the complex facts, issues, and analysis required to make decisions regarding change.
• Provides a detailed financial analysis of cost and benefits.
• Provides guidance for ongoing decision making throughout the initiative.

.2 Limitations

• May be subject to the biases of authors.
• Frequently not updated once funding for the initiative is secured.
• Contains assumptions regarding costs and benefits that may prove invalid upon further investigation.

10.8 Business Model Canvas

10.8.1 Purpose

A business model canvas describes how an enterprise creates, delivers, and captures value for and from its customers.

10.8.2 Description

A business model canvas is comprised of nine building blocks that describe how an organization intends to deliver value:

• Key Partnerships,
• Key Activities,
• Key Resources,
• Value Proposition,
• Customer Relationships,
• Channels,
• Customer Segments,
• Cost Structure, and
• Revenue Streams.

These building blocks are arranged on a business canvas that shows the relationship between the organization’s operations, finance, customers, and offerings. The business model canvas also serves as a blueprint for implementing a strategy.

Figure 10.8.1: Business Model Canvas

A business model canvas can be used as a diagnostic and planning tool regarding strategy and initiatives. As a diagnostic tool, the various elements of the canvas are used as a lens into the current state of the business, especially with regards to the relative amounts of energy, time, and resources the organization is currently investing in various areas. As a planning and monitoring tool, the canvas can be used as a guideline and framework for understanding inter-dependencies and priorities among groups and initiatives.
A business model canvas allows for the mapping of programs, projects, and other initiatives (such as recruitment or talent retention) to the strategy of the enterprise. In this capacity, the canvas can be used to view where the enterprise is investing, where a particular initiative fits, and any related initiatives.
A business model canvas can also be used to demonstrate where the efforts of various departments and work groups fit and align to the overall strategy of the enterprise.

.1 Elements Key Partnerships

Key partnerships frequently involve some degree of sharing of proprietary information, including technologies. An effective key partnership can, in some cases, lead to more formalized relationships such as mergers and acquisitions.
The benefits in engaging in key partnerships include:
• optimization and economy,
• reduction of risk and uncertainty,
• acquisition of particular resources and activities, and
• lack of internal capabilities.

Key Activities

Key activities are those that are critical to the creation, delivery, and maintenance of value, as well as other activities that support the operation of the enterprise.
Key activities can be classified as:
• Value-add: characteristics, features, and business activities for which the customer is willing to pay.
• Non-value-add: aspects and activities for which the customer is not willing to pay.
• Business non-value-add: characteristics that must be included in the offering, activities performed to meet regulatory and other needs, or costs associated with doing business, for which the customer is not willing to pay.

Key Resources

Resources are the assets needed to execute a business model. Resources may be different based on the business model.
Resources can be classified as:
• Physical: applications, locations, and machines.
• Financial: what is needed to fund a business model, such as cash and lines of credit.
• Intellectual: any proprietary aspects that enable a business model to thrive, such as knowledge, patents and copyrights, customer databases, and branding.
• Human: the people needed to execute a particular business model.

Value Proposition

A value proposition represents what a customer is willing to exchange for having their needs met. The proposition may consist of a single product or service, or may be comprised of a set of goods and services that are bundled together to address the needs of a customer or customer segment to help them solve their problem.

Customer Relationships

In general, customer relationships are classified as customer acquisition and customer retention. The methods used in establishing and maintaining customer relationships vary depending on the level of interaction desired and the method of communication. For example, some relationships can be highly personalized, while others are automated and promote a self-serve approach. The relationships can also be formal or informal.
Organizations interact with their customers in different ways depending on the relationship they want to establish and maintain.

Channels

Channels are the different ways an enterprise interacts with and delivers value to its customers. Some channels are very communication-oriented (for example, marketing channel), and some are delivery-oriented (for example, distribution channel). Other examples include sales channels and partnering channels.
Enterprises use channels to:
• raise awareness about their offerings,
• help customers evaluate the value proposition,
• allow customers to purchase a good or service,
• help the enterprise deliver on the value proposition, and
• provide support.
Understanding channels involves identifying the processes, procedures, technologies, inputs, and outputs (and their current impact), as well as understanding the relationship of the various channels to the strategies of the organization.

Customer Segments

Customer segments group customers with common needs and attributes so that the enterprise can more effectively and efficiently address the needs of each segment.
An organization within an enterprise may consider defining and targeting distinct customer segments based on:
• different needs for each segment,
• varying profitability between segments,
• different distribution channels, and
• formation and maintenance of customer relationships.

Cost Structure

Every entity, product, or activity within an enterprise has an associated cost. Enterprises seek to reduce, minimize, or eliminate costs wherever possible. Reducing costs may increase the profitability of an organization and allow those funds to be used in other ways to create value for the organization and for customers. Therefore, it is important to understand the type of business models, the differences in the types of costs and their impact, and where the enterprise is focusing its efforts to reduce costs.

Revenue Streams

A revenue stream is a way or method by which revenue comes into an enterprise from each customer segment in exchange for the realization of a value proposition. There are two basic ways revenue is generated for an enterprise:

revenue resulting from a one-time purchase of a good or service and recurring revenue from periodic payments for a good, service, or ongoing support.
Some types of revenue streams include:
• Licensing or Subscription fees: the customer pays for the right to access a particular asset, either as a one-time fee or as a recurring cost.
• Transaction or Usage fees: the customer pays each time they use a good or service.
• Sales: the customer is granted ownership rights to a specific product.
• Lending, Renting, or Leasing: the customer has temporary rights to use an asset.

.2 Usage Considerations Strengths

• It is a widely used and effective framework that can be used to understand and optimize business models.
• It is simple to use and easy to understand.

Limitations

• Does not account for alternative measures of value such as social and environmental impacts.
• The primary focus on value propositions does not provide a holistic insight for business strategy.
• Does not include the strategic purpose of the enterprise within the canvas.

10.9 Business Rules Analysis

10.9.1 Purpose

Business rules analysis is used to identify, express, validate, refine, and organize the rules that shape day-to-day business behaviour and guide operational business decision making.

10.9.2 Description

Business policies and rules guide the day-to-day operation of the business and its processes, and shape operational business decisions. A business policy is a directive concerned with broadly controlling, influencing, or regulating the actions of an enterprise and the people in it. A business rule is a specific, testable directive that serves as a criterion for guiding behaviour, shaping judgments, or making decisions. A business rule must be practicable (needing no further

Techniques Business Rules Analysis

interpretation for use by people in the business) and is always under the control of the business.
Analysis of business rules involves capturing business rules from sources, expressing them clearly, validating them with stakeholders, refining them to best align with business goals, and organizing them so they can be effectively managed and reused. Sources of business rules may be explicit (for example, documented business policies, regulations, or contracts) or tacit (for example, undocumented stakeholder know-how, generally accepted business practices, or norms of the corporate culture). Business rules should be explicit, specific, clear, accessible, and single sourced. Basic principles for business rules include:
• basing them on standard business vocabulary to enable domain subject matter experts to validate them,
• expressing them separately from how they will be enforced,
• defining them at the atomic level and in declarative format,
• separating them from processes they support or constrain,
• mapping them to decisions the rule supports or constrains, and
• maintaining them in a manner such that they can be monitored and adapted as business circumstances evolve over time.
A set of rules for making an operational business decision may be expressed as a decision table or decision tree, as described in Decision Analysis (p. 261). The number of rules in such a set can be quite large, with a high level of complexity.

10.9.3 Elements

Business rules require consistent use of business terms, a glossary of definitions for the underlying business concepts, and an understanding of the structural connections among the concepts. Reuse of existing terminology from external industry associations or internal business glossaries is often advised. Sometimes definitions and structures from data dictionaries or data models can be helpful (see Data Dictionary (p. 247)and Data Modelling (p. 256)). Business rules should be expressed and managed independently of any implementation technology since they need to be available for reference by business people. In addition, they sometimes will be implemented in multiple platforms or software components. There are frequently exceptions to business rules; these should be treated simply as additional business rules. Existing business rules should be challenged to ensure they align with business goals and remain relevant, especially when new solutions emerge.

.1 Definitional Rules

Definitional rules shape concepts, or produce knowledge or information. They indicate something that is necessarily true (or untrue) about some concept, thereby supplementing its definition. In contrast to behavioural rules, which are about the behaviour of people, definitional rules represent operational

knowledge of the organization. Definitional rules cannot be violated but they can be misapplied. An example of a definitional rule is:
A customer must be considered a Preferred Customer if they place more than 10 orders per month.

Definitional rules often prescribe how information may be derived, inferred or calculated based on information available to the business. An inference or calculation may be the result of multiple rules, each building on something inferred or calculated by some other(s). Sets of definitional rules are often used to make operational business decisions during some process or upon some event. An example of a calculation rule is:
An order’s local jurisdiction tax amount must be calculated as (sum of the prices of all the order’s taxable ordered items) × local jurisdiction tax rate amount.

.2 Behavioural Rules

Behavioural rules are people rules–even if the behaviour is automated. Behavioural rules serve to shape (govern) day-to-day business activity. They do so by placing some obligation or prohibition on conduct, action, practice, or procedure.
Behavioural rules are rules the organization chooses to enforce as a matter of policy, often to reduce risk or enhance productivity. They frequently make use of the information or knowledge produced by definitional rules (which are about shaping knowledge or information). Behavioural rules are intended to guide the actions of people working within the organization, or people who interact with it. They may oblige individuals to perform actions in a certain way, prevent them from carrying out actions, or prescribe the conditions under which something can be correctly done. An example of a behavioural rule is:
An order must not be placed when the billing address provided by the customer does not match the address on file with the credit card provider.

In contrast to definitional rules, behavioural rules are rules that can be violated directly. By definition, it is always possible to violate a behavioural rule—even if there are no circumstances under which the organization would approve that, and despite the fact that the organization takes extraordinary precautions in its solution to prevent it. Because of this, further analysis should be conducted to determine how strictly the rule needs to be enforced, what kinds of sanctions should be imposed when it is violated, and what additional responses to a violation might be appropriate. Such analysis often leads to specification of additional rules.
Various levels of enforcement may be specified for a behavioural rule. For example:
• Allow no violations (strictly enforced).
• Override by authorized actor.

• Override with explanation.
• No active enforcement.
A behavioural rule for which there is no active enforcement is simply a guideline that suggests preferred or optimal business behaviour.

10.9.4 Usage Considerations

.1 Strengths

• When enforced and managed by a single enterprise-wide engine, changes to business rules can be implemented quickly.
• A centralized repository creates the ability to reuse business rules across an organization.
• Business rules provide structure to govern business behaviours.
• Clearly defining and managing business rules allows organizations to make changes to policy without altering processes or systems.

.2 Limitations

• Organizations may produce lengthy lists of ambiguous business rules.
• Business rules can contradict one another or produce unanticipated results when combined unless validated against one another.
• If available vocabulary is insufficiently rich, not business-friendly, or poorly defined and organized, resulting business rules will be inaccurate or contradictory.

10.10 Collaborative Games

10.10.1 Purpose

Collaborative games encourage participants in an elicitation activity to collaborate in building a joint understanding of a problem or a solution.

10.10.2 Description

Collaborative games refer to several structured techniques inspired by game play and are designed to facilitate collaboration. Each game includes rules to keep participants focused on a specific objective. The games are used to help the participants share their knowledge and experience on a given topic, identify hidden assumptions, and explore that knowledge in ways that may not occur during the course of normal interactions. The shared experience of the collaborative game encourages people with different perspectives on a topic to work together in order to better understand an issue and develop a shared model

of the problem or of potential solutions. Many collaborative games can be used to understand the perspectives of various stakeholder groups.
Collaborative games often benefit from the involvement of a neutral facilitator who helps the participants understand the rules of the game and enforces those rules. The facilitator’s job is to keep the game moving forward and to help ensure that all participants play a role. Collaborative games usually involve a strong visual or tactile element. Activities such as moving sticky notes, scribbling on whiteboards, or drawing pictures help people to overcome inhibitions, foster creative thinking, and think laterally.

10.10.3 Elements

.1 Game Purpose

Each different collaborative game has a defined purpose—usually to develop a better understanding of a problem or to stimulate creative solutions—that is specific to that type of game. The facilitator helps the participants in the game understand the purpose and work toward the successful realization of that purpose.

.2 Process

Each type of collaborative game has a process or set of rules that, when followed, keeps the game moving toward its goal. Each step in the game is often limited by time.
Games typically have at least three steps:
Step 1. an opening step, in which the participants get involved, learn the rules of the game, and start generating ideas,
Step 2. the exploration step, in which participants engage with one another and look for connections between their ideas, test those ideas, and experiment with new ideas, and
Step 3. a closing step, in which the ideas are assessed and participants work out which ideas are likely to be the most useful and productive.

.3 Outcome

At the end of a collaborative game, the facilitator and participants work through the results and determine any decisions or actions that need to be taken as a result of what the participants have learned.

.4 Examples of Collaborative Games

There are many types of collaborative games available, including (but not limited to) the following:

Table 10.10.1: Examples of Collaborative Games

10.10.4 Usage Considerations

.1 Strengths
• May reveal hidden assumptions or differences of opinion.
• Encourages creative thinking by stimulating alternative mental processes.
• Challenges participants who are normally quiet or reserved to take a more active role in team activities.
• Some collaborative games can be useful in exposing business needs that aren’t being met.

.2 Limitations

• The playful nature of the games may be perceived as silly and make participants with reserved personalities or cultural norms uncomfortable.
• Games can be time-consuming and may be perceived as unproductive, especially if the objectives or outcomes are unclear.
• Group participation can lead to a false sense of confidence in the conclusions reached.

10.11 Concept Modelling

10.11.1 Purpose

A concept model is used to organize the business vocabulary needed to consistently and thoroughly communicate the knowledge of a domain.

10.11.2 Description

A concept model starts with a glossary, which typically focuses on the core noun concepts of a domain. Concept models put a premium on high-quality, design- independent definitions that are free of data or implementation biases. Concept models also emphasize rich vocabulary.
A concept model identifies the correct choice of terms to use in communications, including all business analysis information. It is especially important where high precision and subtle distinctions need to be made.
Concept models can be effective where:
• the enterprise seeks to organize, retain, build-on, manage, and communicate core knowledge,
• the initiative needs to capture large numbers of business rules,
• there is resistance from stakeholders about the perceived technical nature of data models, class diagrams, or data element nomenclature and definition,
• innovative solutions are sought when re-engineering business processes or other aspects of business capability, and
• the enterprise faces regulatory or compliance challenges.
A concept model differs from a data model. The goal of a concept model is to support the expression of natural language statements, and supply their semantics. Concept models are not intended to unify, codify, and simplify data. Therefore the vocabulary included in a concept model is far richer, as suits knowledge-intensive domains. Concept models are often rendered graphically.

10.11.3 Elements

.1 Noun Concepts

The most basic concepts in a concept model are the noun concepts of the domain, which are simply ‘givens’ for the space.

.2 Verb Concepts

Verb concepts provide basic structural connections between noun concepts. These verb concepts are given standard wordings, so they can be referenced unambiguously. These wordings by themselves are not necessarily sentences; rather, they are the building blocks of sentences (such as business rule statements). Sometimes verb concepts are derived, inferred, or computed by definitional rules. This is how new knowledge or information is built up from more basic facts.

.3 Other Connections

Since concept models must support rich meaning (semantics), other types of standard connections are used besides verb concepts.

These include but are not limited to:
• categorizations,
• classifications,
• partitive (whole-part) connections, and
• roles.

10.11.4 Usage Considerations

.1 Strengths

• Provide a business-friendly way to communicate with stakeholders about precise meanings and subtle distinctions.
• Is independent of data design biases and the often limited business vocabulary coverage of data models.
• Proves highly useful for white-collar, knowledge-rich, decision-laden business processes.
• Helps ensure that large numbers of business rules and complex decision tables are free of ambiguity and fit together cohesively.

.2 Limitations

• May set expectations too high about how much integration based on business semantics can be achieved on relatively short notice.
• Requires a specialized skill set based on the ability to think abstractly and non- procedurally about know-how and knowledge.
• The knowledge-and-rule focus may be foreign to stakeholders.
• Requires tooling to actively support real-time use of standard business terminology in writing business rules, requirements, and other forms of business communication.

10.12 Data Dictionary

10.12.1 Purpose

A data dictionary is used to standardize a definition of a data element and enable a common interpretation of data elements.

10.12.2 Description

A data dictionary is used to document standard definitions of data elements, their meanings, and allowable values. A data dictionary contains definitions of each data element and indicates how those elements combine into composite data elements. Data dictionaries are used to standardize usage and meanings of data elements between solutions and between stakeholders.

Data Dictionary Techniques

Data dictionaries are sometimes referred to as metadata repositories and are used to manage the data within the context of a solution. As organizations adopt data mining and more advanced analytics, a data dictionary may provide the metadata required by these more complex scenarios. A data dictionary is often used in conjunction with an entity relationship diagram (see DataModelling(p.256)) and may be extracted from a data model.
Data dictionaries can be maintained manually (as a spreadsheet) or via automated tools.

Figure 10.12.1: Example of a Data Dictionary

First Name |

Middle Name |

Last Name | | Alias Alternate name referenced by stakeholders |

Given Name |

Middle Name |

Surname | | Values/Meanings Enumerated list or description of data element | Minimum 2 characters |

Can be omitted | Minimum 2 characters | |

Description
Definition |

First Name |

Middle Name |

Family Name | | Composite |

Customer Name = First Name + Middle Name + Family Name | | |

10.12.3 Elements

.1 Data Elements
Data dictionaries describe data element characteristics including the description of the data element in the form of a definition that will be used by stakeholders. Data dictionaries include standard definitions of data elements, their meanings, and allowable values. A data dictionary contains definitions of each primitive data element and indicates how those elements combine into composite data elements.

.2 Primitive Data Elements

The following information must be recorded about each data element in the data

dictionary:
• Name: a unique name for the data element, which will be referenced by the composite data elements.
• Aliases: alternate names for the data element used by various stakeholders.
• Values/Meanings: a list of acceptable values for the data element. This may be expressed as an enumerated list or as a description of allowed formats for the data (including information such as the number of characters). If the values are abbreviated this will include an explanation of the meaning.
• Description: the definition of the data element in the context of the solution.

.3 Composite Elements

Composite data elements are built using data elements to build composite structures, which may include:
• Sequences: required ordering of primitive data elements within the composite structure. For example, a plus sign indicates that one element is followed by or concatenated with another element: Customer Name = First Name+Middle Name+Family Name.
• Repetitions: whether one or more data elements may be repeated multiple times.
• Optional Elements: may or may not occur in a particular instance of the composite element.

10.12.4 Usage Considerations

.1 Strengths

• Provides all stakeholders with a shared understanding of the format and content of relevant information.
• A single repository of corporate metadata promotes the use of data throughout the organization in a consistent manner.

.2 Limitations

• Requires regular maintenance, otherwise the metadata could become obsolete or incorrect.
• All maintenance is required to be completed in a consistent manner in order to ensure that stakeholders can quickly and easily retrieve the information they need. This requires time and effort on the part of the stewards responsible for the accuracy and completeness of the data dictionary.
• Unless care is taken to consider the metadata required by multiple scenarios, it may have limited value across the enterprise.

10.13 Data Flow Diagrams

10.13.1 Purpose

Data flow diagrams show where data comes from, which activities process the data, and if the output results are stored or utilized by another activity or external entity.

10.13.2 Description

Data flow diagrams portray the transformation of data. They are useful for depicting a transaction-based system and illustrating the boundaries of a physical, logical, or manual system.
A data flow diagram illustrates the movement and transformation of data between externals (entities) and processes. The output from one external or process is the input to another. The data flow diagram also illustrates the temporary or permanent repositories (referred to as data stores or terminators) where data is stored within a system or an organization. The data defined should be described in a data dictionary (see DataDictionary(p.247)).
Data flow diagrams can consist of multiple layers of abstraction. The highest level diagram is a context diagram which represents the entire system. Context diagrams show the system in its entirety, as a transformation engine with externals as the source or consumer of data.

Figure 10.13.1: Context Diagram Gane-Sarson Notation

The next level of data flow diagrams is the level 1 diagram. Level 1 diagrams illustrate the processes related to the system with the respective input data, output transformed data, and data stores.

Figure 10.13.2: Level 1 Diagram Yourdon Notation

Further levels of the data flow diagram (level 2, level 3 and so forth) break down the major processes from the level 1 diagram. Level 1 diagrams are useful to show the internal partitioning of the work and the data that flows between the partitions, as well as the stored data used by each of the partitions. Each of the partitions can be further decomposed if needed. The externals remain the same and additional flows and stores are defined.
Logical data flow diagrams represent the future or essential state—that is, what transformations need to occur regardless of the current physical limitations.
Physical data flow diagrams model all of the data stores, printers, forms, devices, and other manifestations of data. The physical diagram can show either the current state or how it will be implemented.

10.13.3 Elements

.1 Externals (Entity, Source, Sink)

An external (entity, source, sink) is a person, organization, automated system, or any device capable of producing data or receiving data. An external is an object which is outside of the system under analysis. Externals are the sources and/or destinations (sinks) of the data. Each external must have at least one data flow going to or coming from it. Externals are represented by using a noun inside a rectangle and are found within context-level diagrams as well as lower levels of abstraction.

.2 Data Store

A data store is a collection of data where data may be read repeatedly and where it can be stored for future use. In essence, it is data at rest. Each data store must have at least one data flow going to or coming from it. A data store is represented as either two parallel lines or as an open-ended rectangle with a label.

.3 Process

A process can be a manual or automated activity performed for a business reason. A process transforms the data into an output. Naming standards for a process should contain a verb and a noun. Each process must have at least one data flow going to it and one data flow coming from it. A data process is represented as a circle or rectangle with rounded corners.

.4 Data Flow

The movement of data between an external, a process, and a data store is represented by data flows. The data flows hold processes together. Every data flow will connect to or from a process (transformation of the data). Data flows show the inputs and outputs of each process. Every process transforms an input into an output. Data flows are represented as a line with an arrow displayed between processes. The data flow is named using a noun.

Figure 10.13.3: Data Flow Diagram Gane-Sarson Notation

Input Data from parent diagram (System Input 1)
Output Data from
parent diagram (System Output 1)

Figure 10.13.4: Data Flow Diagram Yourdon Notation

Input Data
**

10.13.4 Usage Considerations

.1 Strengths
• May be used as a discovery technique for processes and data or as a Technique for the verification of functional decompositions or data models.
• Are excellent ways to define the scope of a system and all of the systems, interfaces, and user interfaces that attach to it. Allows for estimation of the effort needed to study the work.
• Most users find these data flow diagrams relatively easy to understand.
• Helps to identify duplicated data elements or misapplied data elements.
• Illustrates connections to other systems.
• Helps define the boundaries of a system.
• Can be used as part of system documentation.
• Helps to explain the logic behind the data flow within a system.

.2 Limitations

• Using data flow diagrams for large-scale systems can become complex and difficult for stakeholders to understand.
• Different methods of notation with different symbols could create challenges pertaining to documentation.
• Does not illustrate a sequence of activities.
• Data transformations (processes) say little about the process or stakeholder.

10.14 Data Mining

10.14.1 Purpose

Data mining is used to improve decision making by finding useful patterns and insights from data.

10.14.2 Description

Data mining is an analytic process that examines large amounts of data from different perspectives and summarizes the data in such a way that useful patterns and relationships are discovered.
The results of data mining techniques are generally mathematical models or equations that describe underlying patterns and relationships. These models can be deployed for human decision making through visual dashboards and reports, or for automated decision-making systems through business rule management systems or in-database deployments.

Data mining can be utilized in either supervised or unsupervised investigations. In a supervised investigation, users can pose a question and expect an answer that can drive their decision making. An unsupervised investigation is a pure pattern discovery exercise where patterns are allowed to emerge, and then considered for applicability to business decisions.
Data mining is a general term that covers descriptive, diagnostic, and predictive techniques:
• Descriptive: such as clustering make it easier to see the patterns in a set of data, such as similarities between customers.
• Diagnostic: such as decision trees or segmentation can show why a pattern exists, such as the characteristics of an organization’s most profitable customers.
• Predictive: such as regression or neural networks can show how likely something is to be true in the future, such as predicting the probability that a particular claim is fraudulent.
In all cases it is important to consider the goal of the data mining exercise and to be prepared for considerable effort in securing the right type, volume, and quality of data with which to work.

10.14.3 Elements

.1 Requirements Elicitation

The goal and scope of data mining is established either in terms of decision requirements for an important identified business decision, or in terms of a functional area where relevant data will be mined for domain-specific pattern discovery. This top-down versus a bottom-up mining strategy allows analysts to pick the correct set of data mining techniques.
Formal decision modelling techniques (see Decision Modelling (p. 265)) are used to define requirements for top-down data mining exercises. For bottom-up pattern discovery exercises it is useful if the discovered insight can be placed on existing decision models, allowing rapid use and deployment of the insight.
Data mining exercises are productive when managed as an agile environment. They assist rapid iteration, confirmation, and deployment while providing project controls.

.2 Data Preparation: Analytical Dataset

Data mining tools work on an analytical dataset. This is generally formed by merging records from multiple tables or sources into a single, wide dataset. Repeating groups are typically collapsed into multiple sets of fields. The data may be physically extracted into an actual file or it may be a virtual file that is left in the database or data warehouse so it can be analyzed. Analytical datasets are split into a set to be used for analysis, a completely independent set for confirming that the model developed works on data not used to develop it, and a validation set for final confirmation. Data volumes can be very large, sometimes resulting in

the need to work with samples or to work in-datastore so that the data does not have to be moved around.

.3 Data Analysis

Once the data is available, it is analyzed. A wide variety of statistical measures are typically applied and visualization tools used to see how data values are distributed, what data is missing, and how various calculated characteristics behave. This step is often the longest and most complex in a data mining effort and is increasingly the focus of automation. Much of the power of a data mining effort typically comes from identifying useful characteristics in the data. For instance, a characteristic might be the number of times a customer has visited a store in the last 80 days. Determining that the count over the last 80 days is more useful than the count over the last 70 or 90 is key.

.4 Modelling Techniques

There are a wide variety of data mining techniques. Some examples of data mining techniques are:
• classification and regression trees (CART), C5 and other decision tree analysis techniques,
• linear and logistic regression,
• neural networks,
• support sector machines, and
• predictive (additive) scorecards.
The analytical dataset and the calculated characteristics are fed into these algorithms which are either unsupervised (the user does not know what they are looking for) or supervised (the user is trying to find or predict something specific). Multiple techniques are often used to see which is most effective. Some data is held out from the modelling and used to confirm that the result can be replicated with data that was not used in the initial creation.

.5 Deployment

Once a model has been built, it must be deployed to be useful. Data mining models can be deployed in a variety of ways, either to support a human decision maker or to support automated decision-making systems. For human users, data mining results may be presented using visual metaphors or as simple data fields. Many data mining techniques identify potential business rules that can be deployed using a business rules management system. Such executable business rules can be fitted into a decision model along with expert rules as necessary.
Some data mining techniques—especially those described as predictive analytic techniques—result in mathematical formulas. These can also be deployed as executable business rules but can also be used to generate SQL or code for deployment. An increasingly wide range of in-database deployment options allow such models to be integrated into an organization’s data infrastructure.

10.14.4 Usage Considerations

.1 Strengths

• Reveal hidden patterns and create useful insight during analysis—helping determine what data might be useful to capture or how many people might be impacted by specific suggestions.
• Can be integrated into a system design to increase the accuracy of the data.
• Can be used to eliminate or reduce human bias by using the data to determine the facts.

.2 Limitations

• Applying some techniques without an understanding of how they work can result in erroneous correlations and misapplied insight.
• Access to big data and to sophisticated data mining tool sets and software may lead to accidental misuse.
• Many techniques and tools require specialist knowledge to work with.
• Some techniques use advanced math in the background and some stakeholders may not have direct insights into the results. A perceived lack of transparency can cause resistance from some stakeholders.
• Data mining results may be hard to deploy if the decision making they are intended to influence is poorly understood.

10.15 Data Modelling

10.15.1 Purpose

A data model describes the entities, classes or data objects relevant to a domain, the attributes that are used to describe them, and the relationships among them to provide a common set of semantics for analysis and implementation.

10.15.2 Description

A data model usually takes the form of a diagram that is supported by textual descriptions. It visually represents the elements that are important to the business (for example, people, places, things, and business transactions), the attributes associated with those elements, and the significant relationships among them. Data models are frequently used in elicitation and requirements analysis and design, as well as to support implementation and continuous improvement.
There are several variations of data models:
• Conceptual data model: is independent of any solution or technology and can be used to represent how the business perceives its information. It can be used to help establish a consistent vocabulary describing business

information and the relationships within that information.
• Logical data model: is an abstraction of the conceptual data model that incorporates rules of normalization to formally manage the integrity of the data and relationships. It is associated with the design of a solution.
• Physical data model: is used by implementation subject matter experts to describe how a database is physically organized. It addresses concerns like performance, concurrency, and security.
The conceptual, logical, and physical data models are developed for different purposes and may be significantly different even when depicting the same domain.
At the conceptual level, different data modelling notations are likely to produce broadly similar results and can be thought of as a single technique (as presented here). Logical and physical data models include elements specific to the solutions they support, and are generally developed by stakeholders with expertise in implementing particular technical solutions. For instance, logical and physical entity-relationship diagrams (ERDs) would be used to implement a relational database, whereas a logical or physical class diagram would be used to support object-oriented software development.
Object diagrams can be used to illustrate particular instances of entities from a data model. They can include actual sample values for the attributes, making object diagrams more concrete and more easily understood.

10.15.3 Elements

.1 Entity or Class

In a data model, the organization keeps data on entities (or classes or data objects). An entity may represent something physical (such as a Warehouse), something organizational (such as a Sales Area), something abstract (such as a Product Line), or an event (such as an Appointment). An entity contains attributes and has relationships to other entities in the model.
In a class diagram, entities are referred to as classes. Like an entity in a data model, a class contains attributes and has relationships with other classes. A class also contains operations or functions that describe what can be done with the class, such as generating an invoice or opening a bank account.
Each instance of an entity or class will have a unique identifier that sets it apart from other instances.

.2 Attribute

An attribute defines a particular piece of information associated with an entity, including how much information can be captured in it, its allowable values, and the type of information it represents. Attributes can be described in a data dictionary (see Data Dictionary (p. 247)). Allowable values may be specified through business rules (see Business Rules Analysis (p. 240)).

Attributes can include such values as:
• Name: a unique name for the attribute. Other names used by stakeholders may be captured as aliases.
• Values/Meanings: a list of acceptable values for the attribute. This may be expressed as an enumerated list or as a description of allowed formats for the data (including information such as the number of characters). If the values are abbreviated this will include an explanation of the meaning.
• Description: the definition of the attribute in the context of the solution.

.3 Relationship or Association

The relationships between entities provide structure for the data model, specifically indicating which entities relate to which others and how.
Specifications for a relationship typically indicate the number of minimum and maximum occurrences allowed on each side of that relationship (for example, every customer is related to exactly one sales area, while a sales area may be related to zero, one, or many customers). The term cardinality is used to refer to the minimum and maximum number of occurrences to which an entity may be related. Typical cardinality values are zero, one, and many.
The relationship between two entities may be read in either direction, using this format:
Each occurrence (of this entity) is related to (minimum, maximum) (of this other entity).

In a class model, the term association is used instead of relationship and multiplicity is used instead of cardinality.

.4 Diagrams

Both data models and class models may have one or more diagrams that show entities, attributes, and relationships.
The diagram in a data model is called an entity-relationship diagram (ERD). In a class model, the diagram is called a class diagram.

Figure 10.15.1: Entity-Relationship Diagram (Crow’s Foot Notation)

**

Figure 10.15.2: Class Diagram (UML®)

.5 Metadata
A data model optionally contains metadata describing what the entities represent, when and why they were created or changed, how they should be used, how often they are used, when, and by whom. There could be restrictions on their creation or use, as well as security, privacy, and audit constraints on specific entities or whole groups of entities.

10.15.4 Usage Considerations

.1 Strengths

• Can be used to define and communicate a consistent vocabulary used by domain subject matter experts and implementation subject matter experts.
• Review of a logical data model helps to ensure that the logical design of persistent data correctly represents the business need.
• Provides a consistent approach to analyzing and documenting data and its relationships.

• Offers the flexibility of different levels of detail, which provides just enough information for the respective audience.
• Formal modelling of the information held by the business may expose new requirements as inconsistencies are identified.

.2 Limitations

• Following data modelling standards too rigorously may lead to models that are unfamiliar to people without a background in IT.
• May extend across multiple functional areas of the organization, and so beyond the business knowledge base of individual stakeholders.

10.16 Decision Analysis

10.16.1 Purpose

Decision analysis formally assesses a problem and possible decisions in order to determine the value of alternate outcomes under conditions of uncertainty.

10.16.2 Description

Decision analysis examines and models the possible consequences of different decisions about a given problem. A decision is the act of choosing a single course of action from several uncertain outcomes with different values. The outcome value may take different forms depending on the domain, but commonly include financial value, scoring, or a relative ranking dependent on the approach and evaluation criteria used by the business analyst.
Decisions are often difficult to assess when:
• the problem is poorly defined,
• the action leading to a desired outcome is not fully understood,
• the external factors affecting a decision are not fully understood, or
• the value of different outcomes is not understood or agreed upon by the various stakeholders and does not allow for direct comparison.
Decision analysis helps business analysts evaluate different outcome values under conditions of uncertainty or in highly complex situations. A variety of decision analysis approaches are available. The appropriate approach depends on the level of uncertainty, risk, quality of information, and available evaluation criteria.
Effective decision analysis requires an understanding of:
• the values, goals, and objectives that are relevant to the decision problem,
• the nature of the decision that must be made,
• the areas of uncertainty that affect the decision, and
• the consequences of each potential decision.

Decision analysis approaches use the following activities:
1. Define Problem Statement: clearly describe the decision problem to be addressed.
2. Define Alternatives: identify possible propositions or courses of action.
3. Evaluate Alternatives: determine a logical approach to analyze the alternatives. An agreement of evaluation criteria can also be determined at the beginning of this activity.
4. Choose Alternative to Implement: the stakeholders responsible for making the decision choose which alternative will be implemented based on the decision analysis results.
5. Implement Choice: implement the chosen alternative.
There are a number of decision analysis tools available to assist the business analyst and decision makers in making objective decisions. Some of the tools and techniques are best for deciding between two alternatives, while others handle multiple alternatives.
Some general decision analysis tools and techniques include:
• pro versus con considerations,
• force field analysis,
• decision tables,
• decision trees,
• comparison analysis,
• analytical hierarchy process (AHP),
• totally-partially-not (TPN),
• multi-criteria decision analysis (MCDA), and
• computer-based simulations and algorithms.

10.16.3 Elements

.1 Components of Decision Analysis

General components of decision analysis include:
• Decision to be Made or Problem Statement: a description of what the decision question or problem is about.
• Decision Maker: person or people responsible for making the final decision.
• Alternative: a possible proposition or course of action.
• Decision Criteria: evaluation criteria used to evaluate the alternatives.

.2 Decision Matrices

The tables below provide examples of a a simple decision matrix and a weighted decision matrix.
A simple decision matrix checks whether or not each alternate meets each criterion being evaluated, and then totals the number of criteria matched for each alternate. In this example, Alternate 1 would likely be selected because it matches the most criteria.

Table 10.16.1: Simple Decision Matrix

A weighted decision matrix assesses options in which each criterion is weighted based on importance. The higher the weighting, the more important the criterion. In this example, the criteria are weighted on a scale of 1-5, where 5 indicates the most important. The alternates are ranked per criterion on a scale of 1-5, where 5 indicates the best match. In this example, Alternate 3 would likely be selected due to its high weighted score.

Table 10.16.2: Weighted Decision Matrix

.3 Decision Trees
A decision tree is a method of assessing the preferred outcome where multiple sources of uncertainty may exist. A decision tree allows for assessment of responses to uncertainty to be factored across multiple strategies.
Decision trees include:
• Decision Nodes: that include different strategies.
• Chance Nodes: that define uncertain outcomes.
• Terminator or End Nodes: that identify a final outcome of the tree.

.4 Trade-offs

Trade-offs become relevant whenever a decision problem involves multiple, possibly conflicting, objectives. Because more than one objective is relevant, it is not sufficient to simply find the maximum value for one variable (such as the financial benefit for the organization). When making trade-offs, effective methods include:
• Elimination of dominated alternatives: a dominated alternative is any option that is clearly inferior to some other option. If an option is equal to or worse than some other option when rated against the objectives, the other option can be said to dominate it. In some cases, an option may also be dominated if it only offers very small advantages but has significant disadvantages.
• Ranking objectives on a similar scale: one method of converting rankings to a similar scale is proportional scoring. Using this method, the best outcome is assigned a rating of 100, the worst a rating of 0, and all other outcomes are given a rating based on where they fall between those two scores. If the outcomes are then assigned weights based on their relative importance, a score can be assigned to each outcome and the best alternative assigned using a decision tree.

10.16.4 Usage Considerations

.1 Strengths

• Provides business analysts with a prescriptive approach for determining alternate options, especially in complex or uncertain situations.
• Helps stakeholders who are under pressure to assess options based on criteria, thus reducing decisions based on descriptive information and emotions.
• Requires stakeholders to honestly assess the importance they place on different alternate outcomes in order to help avoid false assumptions.
• Enables business analysts to construct appropriate metrics or introduce relative rankings for outcome evaluation in order to directly compare both the financial and non-financial outcome evaluation criteria.

.2 Limitations

• The information to conduct proper decision analysis may not be available in time to make the decision.
• Many decisions must be made immediately, without the luxury of employing a formal or even informal decision analysis process.
• The decision maker must provide input to the process and understand the assumptions and model limitations. Otherwise, they may perceive the results provided by the business analyst as more certain than they are.
• Analysis paralysis can occur when too much dependence is placed on the decision analysis and in determining probabilistic values.

• Some decision analysis models require specialized knowledge (for example, mathematical knowledge in probability and strong skills with decision analysis tools).

10.17 Decision Modelling

10.17.1 Purpose

Decision modelling shows how repeatable business decisions are made.

10.17.2 Description

Decision models show how data and knowledge are combined to make a specific decision. Decision models can be used for both straightforward and complex decisions. Straightforward decision models use a single decision table or decision tree to show how a set of business rules that operate on a common set of data elements combine to create a decision. Complex decision models break down decisions into their individual components so that each piece of the decision can be separately described and the model can show how those pieces combine to make an overall decision. The information that needs to be available to make the decision and any sub-decisions can be decomposed. Each sub-decision is described in terms of the business rules required to make that part of the decision.
A comprehensive decision model is an overarching model that is linked to processes, performance measures, and organizations. It shows where the business rules come from and represents decisions as analytical insight.
The business rules involved in a given decision may be definitional or behavioural. For instance, a decision ‘Validate order’ might check that the tax amount is calculated correctly (a definitional rule) and that the billing address matches the credit card provided (a behavioural rule).
Decision tables and decision trees define how a specific decision is made. A graphical decision model can be constructed at various levels. A high-level model may only show the business decisions as they appear in business processes, while a more detailed model might show as-is or to-be decision making in enough detail to act as a structure for all the relevant business rules.

10.17.3 Elements

.1 Types of Models and Notations

There are several different approaches to decision modelling. Decision tables represent all the rules required to make an atomic decision. Decision trees are common in some industries, but are generally used much less often than decision tables. Complex decisions require the combination of multiple simple decisions into a network. This is shown using dependency or requirements notations.

Decision Modelling Techniques

All of these approaches involve three key elements:
• decision,
• information, and
• knowledge.

Decision Tables

Business decisions use a specific set of input values to determine a particular outcome by using a defined set of business rules to select one from the available outcomes. A decision table is a compact, tabular representation of a set of these rules. Each row (or column) is a rule and each column (or row) represents one of the conditions of that rule. When all the conditions in a particular rule evaluate to true for a set of input data, the outcome or action specified for that rule is selected.
Decision tables generally contain one or more condition columns that map to specific data elements, as well as one or more action or outcome columns. Each row can contain a specific condition in each condition column. These are evaluated against the value of the data element being considered. If all the cells in a rule are either blank or evaluate to true, the rule is true and the result specified in the action or outcome column occurs.

Figure 10.17.1: Decision Table

Decision Trees
Decision trees are also used to represent a set of business rules. Each path on a decision tree leaf node is a single rule. Each level in the tree represents a specific data element; the downstream branches represent the different conditions that must be true to continue down that branch. Decision trees can be very effective for representing certain kinds of rule sets, especially those relating to customer segmentation.
As with decision tables, a decision tree selects one of the available actions or outcomes (a leaf node shown on the far right or bottom of the tree) based on the

specific values passed to it by the data elements that represent the branching nodes.
In the following decision tree, the rules in the tree share conditions (represented by earlier nodes in the tree).

Figure 10.17.2: Decision Tree

Decision Requirements Diagrams

A decision requirements diagram is a visual representation of the information, knowledge, and decision making involved in a more complex business decision.
Decision requirement diagrams contain the following elements:
• Decisions: shown as rectangles. Each decision takes a set of inputs and selects from a defined set of possible outputs by applying business rules and other decision logic.
• Input Data: shown as ovals, representing data that must be passed as an input to a decision on the diagram.
• Business Knowledge Models: shown as a rectangle with the corners cut off, representing sets of business rules, decision tables, decision trees, or even predictive analytic models that describe precisely how to make a decision.
• Knowledge Sources: shown as a document, representing the original source documents or people from which the necessary decision logic can be or has been derived.
These nodes are linked together into a network to show the decomposition of complex decision making into simpler building blocks. Solid arrows show the information requirements for a decision. These information requirements might link input data to a decision, to show that this decision requires that data to be available, or might link two decisions together.
Business knowledge models which describe how to make a specific decision can be linked to that decision with dashed arrows to display knowledge requirements. Knowledge sources can be linked to decisions with a dashed, rounded arrow to show that a knowledge source (for example, a document or person) is an authority for the decision. This is called an authority requirement.

Figure 10.17.3: Decision Requirements Diagram

10.17.4 Usage Considerations

.1 Strengths
• Decision models are easy to share with stakeholders, facilitate a shared understanding, and support impact analysis.
• Multiple perspectives can be shared and combined, especially when a diagram is used.
• Simplifies complex decision making by removing business rules management from the process.
• Assists with managing large numbers of rules in decision tables by grouping rules by decision. This also helps with reuse.
• These models work for rules-based automation, data mining, and predictive analytics, as well as for manual decisions or business intelligence projects.

.2 Limitations

• Adds a second diagram style when modelling business processes that contain decisions.This may add unnecessary complexity if the decision is simple and tightly coupled with the process.
• May limit rules to those required by known decisions and so limit the capture of rules not related to a known decision.
• Defining decision models may allow an organization to think it has a standard way of making decisions when it does not. May lock an organization into a current-state decision-making approach.
• Cuts across organizational boundaries, which can make it difficult to acquire any necessary sign-off.
• May not address behavioural business rules in a direct fashion.

• Business terminology must be clearly defined and shared definitions developed to avoid data quality issues affecting automated decisions.

10.18 Document Analysis

10.18.1 Purpose

Document analysis is used to elicit business analysis information, including contextual understanding and requirements, by examining available materials that describe either the business environment or existing organizational assets.

10.18.2 Description

Document analysis may be used to gather background information in order to understand the context of a business need, or it may include researching existing solutions to validate how those solutions are currently implemented. Document analysis may also be used to validate findings from other elicitation efforts such as interviews and observations. Data mining is one approach to document analysis that is used to analyze data in order to determine patterns, group the data into categories, and determine opportunities for change. The purpose, scope, and topics to be researched through document analysis are determined based on the business analysis information being explored. When performing document analysis, business analysts methodically review the materials and determine whether the information should be recorded within a work product.
Background research gathered through document analysis may include reviewing materials such as marketing studies, industry guidelines or standards, company memos, and organizational charts. By researching a wide variety of source materials, the business analyst can ensure the need is fully understood in terms of the environment in which it exists. Document analysis about an existing solution may include reviewing business rules, technical documentation, training documentation, problem reports, previous requirements documents, and procedure manuals in order to validate both how the current solution works and why it was implemented in its current form. Document analysis can also help address information gaps that may occur when the subject matter experts (SMEs) for the existing solution are no longer present or will not be available for the duration of the elicitation process.

10.18.3 Elements

.1 Preparation

Document analysis materials may originate from public or proprietary sources. When assessing source documents for analysis, business analysts consider:
• whether or not the source’s content is relevant, current, genuine, and credible,

• whether or not the content is understandable and can be easily conveyed to stakeholders as needed, and
• defining both the data to be mined (based on the classes of data needed) and the data clusters that provide items grouped by logical relationships.

.2 Document Review and Analysis

Performing document analysis includes:
• Conducting a detailed review of each document’s content and recording relevant notes associated with each topic. Notes can be recorded using a document analysis chart that includes the topic, type, source, verbatim details, a paraphrased critique, and any follow-up issues or actions for each document that is reviewed.
• Identifying if any notes conflict or are duplicates.
• Noting any gaps in knowledge in which the findings about certain topics are limited. It may be necessary to perform additional research to revisit these topics, or to drill down at a sub-topic level.

.3 Record Findings

When the information elicited through document analysis is used in a work product, the business analyst considers:
• if the content and level of detail is appropriate for the intended audience, and
• if the material should be transformed into visual aids such as graphs, models, process flows, or decision tables in order to help improve understanding.

10.18.4 Usage Considerations

.1 Strengths

• Existing source material may be used as a basis for analysis.
• The business analyst does not need to create content.
• Existing sources, although possibly outdated, can be used as a point of reference to determine what is current and what has changed.
• Results can be used to validate against the results of other requirements elicitation techniques.
• Findings can be presented in formats that permit ease of review and reuse.

.2 Limitations

• Existing documentation may be out of date or invalid (incorrect, missing information, unreadable, unreviewed or unapproved).
• Authors may not be available for questions.

• Primarily helpful only for evaluating the current state, via review of as-is documentation.
• If there is a wide range of sources, the effort may be very time-consuming and lead to information overload and confusion.

10.19 Estimation

10.19.1 Purpose

Estimation is used by business analysts and other stakeholders to forecast the cost and effort involved in pursuing a course of action.

10.19.2 Description

Estimation is used to support decision making by predicting attributes such as:

• cost and effort to pursue a course of action,
• expected solution benefits,
• project cost,
• business performance,
• potential value anticipated from a solution, and
• costs of creating a solution,
• costs of operating a solution,
• potential risk impact.

The result of estimation is sometimes expressed as a single number. Representing the results of estimation as a range, with minimum and maximum values along with probability, may present a higher degree of effectiveness for stakeholders. This range is referred to as a confidence interval and serves as a measure of the level of uncertainty. The less information that is available to the estimator, the wider the confidence interval will be.
Estimation is an iterative process. Estimates are reviewed as more information becomes available, and are also revised (if appropriate). Many estimation techniques rely on historical performance records from the organization in order to calibrate estimates against prior experience. Each estimate can include an assessment of its associated level of uncertainty.

10.19.3 Elements

.1 Methods

Various methods of estimation are used for specific situations. In each case it is important for the estimators to have an agreed-upon description of the elements to be estimated, often in the form of a work breakdown structure or some other decomposition of all the work being estimated. When developing and delivering an estimate, constraints and assumptions also need to be clearly communicated.
Common estimation methods include:
• Top-down: examining the components at a high level in a hierarchical breakdown.

• Bottom-up: using the lowest-level elements of a hierarchical breakdown to examine the work in detail and estimate the individual cost or effort, and then summing across all elements to provide an overall estimate.
• Parametric Estimation: use of a calibrated parametric model of the element attributes being estimated. It is important that the organization uses its own history to calibrate any parametric model, since the attribute values reflect the skills and abilities of both its staff and the processes used to do work.
• Rough Order of Magnitude (ROM): a high-level estimate, generally based on limited information, which may have a very wide confidence interval.
• Rolling Wave: repeated estimates throughout an initiative or project, providing detailed estimates for near-term activities (such as an iteration of the work) extrapolated for the remainder of the initiative or project.
• Delphi: uses a combination of expert judgment and history. There are several variations on this process, but they all include individual estimates, sharing the estimates with experts, and having several rounds of estimation until consensus is reached. An average of the three estimates is used.
• PERT: each component of the estimate is given three values: (1) Optimistic value, representing the best-case scenario, (2) Pessimistic value, representing the worst-case scenario, (3) Most Likely value. Then a PERT value for each estimated component is computed as a weighted average: (Optimistic + Pessimistic + (4 times Most Likely))/6.

.2 Accuracy of the Estimate

The accuracy of an estimate is a measure of uncertainty that evaluates how close an estimate is to the actual value measured later. It can be calculated as a ratio of the width of the confidence interval to its mean value and then expressed as a percentage. When there is little information, such as early in the development of a solution approach, a Rough Order of Magnitude (ROM) estimate is delivered, which is expected to have a wide range of possible values and a high level of uncertainty.
ROM estimates are often no more than +50% to -50% accurate. A definitive estimate, which is much more accurate, can be made as long as more real-world data is collected. Definitive estimates that are used for predicting timelines, final budgets, and resource needs should ideally be accurate within 10% or less.
Teams can combine the use of ROM estimates and definitive estimates throughout a project or initiative using rolling wave estimates. A team creates a definitive estimate for the next iteration or phase (for which they have adequate information), while the remainder of the work is given a ROM estimate. As the end of the iteration or phase approaches, a definitive estimate is made for the work of the next iteration or phase and the ROM estimate for remaining activities is refined.

.3 Sources of Information

Estimators consider available information from prior experience along with the attributes being estimated.
Some common sources of information include:
• Analogous Situations: using an element (project, initiative, risk, or other) that is like the element being estimated.
• Organization History: previous experiences of the organization with similar work. This is most helpful if the prior work was done by the same or a similarly-skilled team and by using the same techniques.
• Expert Judgment: leveraging the knowledge of individuals about the element being estimated. Estimating often relies on the expertise of those who have performed the work in the past, internal or external to the organization. When using external experts, estimators take into account the relevant skills and abilities of those doing the work being estimated.

.4 Precision and Reliability of Estimates

When multiple estimates are made for a particular attribute, the precision of the resulting estimate is a measure of agreement between the estimates (how close they are to each other). By examining measures of imprecision such as variance or standard deviation, estimators can determine their level of agreement.
The reliability of an estimate (its repeatability) is reflected in the variation of estimates made by different methods of estimating or by different estimators.
To illustrate the level of reliability and precision, an estimate is often expressed as a range of values with an associated confidence level. That is, for a given summary estimate value and confidence level, the range of values is the expected range of possible values based on the estimates provided. For example, if a team estimated that some task would take 40 hours, a 90% confidence interval might be 36 to 44 hours, depending on what they gave as individual estimates. A 95% confidence interval might be 38 to 42 hours. In general, the higher the confidence level in the estimate, the narrower the range would be.
To provide estimates with a particular level of confidence, estimators can use a technique such as PERT. Using the multiple estimates for each component of the estimate, a probability distribution can be constructed. This distribution provides a way to compute an overall estimate (incorporating all of the estimated elements) as a range of values, with an associated level of confidence.

.5 Contributors to Estimates

The estimators of an element are frequently those responsible for that element. The estimate of a team is usually more accurate than the estimate of one individual, since it incorporates the expertise of all team members.
In some cases, an organization has a group that performs estimation for much of the work of the organization. This is done with care, so that the estimate reflects the likely context of the element being estimated.

When an organization needs a high level of confidence in the estimate of some critical element, it may call on an external expert to perform or review the estimate. The organization may compare an independent estimate against their internal estimate to determine what adjustments may be needed.

10.19.4 Usage Considerations

.1 Strengths

• Estimates provide a rationale for an assigned budget, time frame, or size of a set of elements.
• Without an estimate, teams making a change may be provided an unrealistic budget or schedule for their work.
• Having a small team of knowledgeable individuals provide an estimate by following a defined technique generally results in a closer predictor of the actual value than if an estimate was made by one individual.
• Updating an estimate throughout a work cycle, in which the estimated elements are refined over time, incorporates knowledge and helps ensure success.

.2 Limitations

• Estimates are only as accurate as the level of knowledge about the elements being estimated. Without organization or local knowledge, estimates can vary widely from the actual values determined later.
• Using just one estimation method may lead stakeholders to have unrealistic expectations.

10.20 Financial Analysis

10.20.1 Purpose

Financial analysis is used to understand the financial aspects of an investment, a solution, or a solution approach.

10.20.2 Description

Financial analysis is the assessment of the expected financial viability, stability, and benefit realization of an investment option. It includes a consideration of the total cost of the change as well as the total costs and benefits of using and supporting the solution.
Business analysts use financial analysis to make a solution recommendation for an investment in a specific change initiative by comparing one solution or solution approach to others, based on analysis of the:
• initial cost and the time frame in which those costs are incurred,
• expected financial benefits and the time frame in which they will be incurred,
• ongoing costs of using the solution and supporting the solution,

• risks associated with the change initiative, and
• ongoing risks to business value of using that solution.
A combination of analysis techniques are typically used because each provides a different perspective. Executives compare the financial analysis results of one investment option with that of other possible investments to make decisions about which change initiatives to support.
Financial analysis deals with uncertainty, and as a change initiative progresses through its life cycle, the effects of that uncertainty become better understood. Financial analysis is continuously applied during the initiative to determine if the change is likely to deliver enough business value such that it should continue. A business analyst may recommend that a change initiative be adjusted or stopped if new information causes the financial analysis results to no longer support the initial solution recommendation.

10.20.3 Elements

.1 Cost of the Change

The cost of a change includes the expected cost of building or acquiring the solution components and the expected costs of transitioning the enterprise from the current state to the future state. This could include the costs associated with changing equipment and software, facilities, staff and other resources, buying out existing contracts, subsidies, penalties, converting data, training, communicating the change, and managing the roll out. These costs may be shared between organizations within the enterprise.

.2 Total Cost of Ownership (TCO)

The total cost of ownership (TCO) is the cost to acquire a solution, the cost of using the solution, and the cost of supporting the solution for the foreseeable future, combined to help understand the potential value of a solution. In the case of equipment and facilities, there is often a generally agreed to life expectancy. However, in the case of processes and software, the life expectancy is often unknown. Some organizations assume a standard time period (for example, three to five years) to understand the costs of ownership of intangibles like processes and software.

.3 Value Realization

Value is typically realized over time. The planned value could be expressed on an annual basis, or could be expressed as a cumulative value over a specific time period.

.4 Cost-Benefit Analysis

Cost-benefit analysis (sometimes called benefit-cost analysis) is a prediction of the expected total benefits minus the expected total costs, resulting in an expected net benefit (the planned business value).
Assumptions about the factors that make up the costs and benefits should be clearly stated in the calculations so they can be reviewed, challenged and

approved. The costs and benefits will often be estimated based on those assumptions, and the estimating methodology should be described so that it can be reviewed and adjusted if necessary.
The time period of a cost-benefit analysis should look far enough into the future that the solution is in full use, and the planned value is being realized. This will help to understand which costs will be incurred and when, and when the expected value should be realized.

Table 10.20.1: Example of a Cost-Benefit Analysis

Some benefits may not be realized until future years. Some project and operating costs may be recognized in future years. The cumulative net benefits could be negative for some time until the future.
In some organizations, all or part of the costs associated with the change may be amortized over several years, and the organization may require the cost-benefit

Techniques Financial Analysis

analysis to reflect this.
During a change initiative, as the expected costs become real costs, the business analyst may re-examine the cost-benefit analysis to determine if the solution or solution approach is still viable.

.5 Financial Calculations

Organizations use a combination of standard financial calculations to understand different perspectives about when and how different investments deliver value. These calculations take into consideration the inherent risks in different investments, the amount of upfront money to be invested compared to when the benefits will be realized, a comparison to other investments the organization could make, and the amount of time it will take to recoup the original investment.
Financial software, including spreadsheets, typically provide pre-programmed functions to correctly perform these financial calculations.

Return on Investment

The return on investment (ROI) of a planned change is expressed as a percentage measuring the net benefits divided by the cost of the change. One change initiative, solution, or solution approach may be compared to that of others to determine which one provides the greater overall return relative to the amount of the investment.
The formula to calculate ROI is:
Return on Investment = (Total Benefits – Cost of the Investment) / Cost of the Investment.

The higher the ROI, the better the investment.
When making a comparison between potential investments, the business analyst should use the same time period for both.

Discount Rate

The discount rate is the assumed interest rate used in present value calculations. In general, this is similar to the interest rate that the organization would expect to earn if it invested its money elsewhere. Many organizations use a standard discount rate, usually determined by its finance officers, to evaluate potential investments such as change initiatives using the same assumptions about expected interest rates. Sometimes a larger discount rate is used for time periods that are more than a few years into the future to reflect greater uncertainty and risk.

Present Value

Different solutions and different solution approaches could realize benefits at different rates and over a different time. To objectively compare the effects of these different rates and time periods, the benefits are calculated in terms of

present-day value. The benefit to be realized sometime in the future is reduced by the discount rate to determine its worth today.
The formula to calculate present value is:
Present Value = Sum of (Net Benefits in that period / (1 + Discount Rate for that period)) for all periods in the cost-benefit analysis.

Present value is expressed in currency. The higher the present value, the greater the total benefit.
Present value does not consider the cost of the original investment.

Net Present Value

Net present value (NPV) is the present value of the benefits minus the original cost of the investment. In this way, different investments, and different benefit patterns can be compared in terms of present day value. The higher the NPV, the better the investment.
The formula to calculate net present value is:
Net Present Value = Present Value – Cost of Investment

Net present value is expressed in currency. The higher the NPV, the better the investment.

Internal Rate of Return

The internal rate of return (IRR) is the interest rate at which an investment breaks even, and is usually used to determine if the change, solution or solution approach is worth investing in. The business analyst may compare the IRR of one solution or solution approach to a minimum threshold that the organization expects to earn from its investments (called the hurdle rate). If the change initiative’s IRR is less than the hurdle rate, then the investment should not be made.
Once the planned investment passes the hurdle rate, it could be compared to other investments of the same duration. The investment with the higher IRR would be the better investment. For example, the business analyst could compare two solution approaches over the same time period, and would recommend the one with the higher IRR.
The IRR is internal to one organization since it does not consider external influencers such as inflation or fluctuating interest rates or a changing business context.
The IRR calculation is based on the interest rate at which the NPV is 0:
Net Present Value = (-1 x Original Investment) + Sum of (net benefit for that period / (1 + IRR) for all periods) = 0.
_

Payback Period

The payback period provides a projection on the time period required to generate enough benefits to recover the cost of the change, irrespective of the discount rate. Once the payback period has passed the initiative would normally show a net financial benefit to the organization, unless operating costs rise. There is no standard formula for calculating the payback period. The time period is usually expressed in years or years and months.

10.20.4 Usage Considerations

.1 Strengths

• Financial analysis allows executive decision makers to objectively compare very different investments from different perspectives.
• Assumptions and estimates built into the benefits and costs, and into the financial calculations, are clearly stated so that they may be challenged or approved.
• It reduces the uncertainty of a change or solution by requiring the identification and analysis of factors that will influence the investment.
• If the context, business need, or stakeholder needs change during a change initiative, it allows the business analyst to objectively re-evaluate the recommended solution.

.2 Limitation

• Some costs and benefits are difficult to quantify financially.
• Because financial analysis is forward looking, there will always be some uncertainty about expected costs and benefits
• Positive financial numbers may give a false sense of security—they may not provide all the information required to understand an initiative.

10.21 Focus Groups

10.21.1 Purpose

A focus group is a means to elicit ideas and opinions about a specific product, service, or opportunity in an interactive group environment. The participants, guided by a moderator, share their impressions, preferences, and needs.

10.21.2 Description

A focus group is composed of pre-qualified participants whose objective is to discuss and comment on a topic within a context. The participants share their perspectives and attitudes about a topic and discuss them in a group setting. This

sometimes leads participants to re-evaluate their own perspectives in light of others’ experiences. A trained moderator manages the preparation of the session, assists in selecting participants, and facilitates the session. If the moderator is not the business analyst, he/she may work with the business analyst to analyze the results and produce findings that are reported to the stakeholders. Observers may be present during the focus group session, but do not typically participate.
A focus group can be utilized at various points in an initiative to capture information or ideas in an interactive manner. If the group’s topic is a product under development, the group’s ideas are analyzed in relationship to the stated requirements. This may result in updating existing requirements or uncovering new requirements. If the topic is a completed product that is ready to be launched, the group’s report could influence how to position the product in the market. If the topic is a product in production, the group’s report may provide direction on the revisions to the next release of requirements. A focus group may also serve as a means to assess customer satisfaction with a product or service.
A focus group is a form of qualitative research. The activities are similar to that of a brainstorming session, except that a focus group is more structured and focused on the participants’ perspectives concerning a specific topic. It is not a interview session conducted as a group; rather, it is a discussion during which feedback is collected on a specific subject. The session results are usually analyzed and reported as themes and perspectives rather than numerical findings.

10.21.3 Elements

.1 Focus Group Objective

A clear and specific objective establishes a defined purpose for the focus group. Questions are formulated and discussions are facilitated with the intent of meeting the objective.

.2 Focus Group Plan

The focus group plan ensures that all stakeholders are aware of the purpose of the focus group and agree on the expected outcomes, and that the session meets the objectives.
The focus group plan defines activities that include:
• Purpose: creating questions that answer the objective, identifying key topics to be discussed, and recommending whether or not discussion guides will be used.
• Location: identifying whether the session will be in-person or online, as well as which physical or virtual meeting place will be used.
• Logistics: identifying the size and set up of the room, other facilities that may be required, public transportation options, and the time of the session.
• Participants: identifying the demographics of those actively engaged in the discussion, if any observers are required, and who the moderators and

recorders will be. Consideration may also be given to incentives for participants.
• Budget: outlining the costs of the session and ensuring that resources are allocated appropriately.
• Timelines: establishing the period of time when the session or sessions will be held, as well as when any reports or analysis resulting from the focus group are expected.
• Outcomes: identifying how the results will be analyzed and communicated and the intended actions based on the results.

.3 Participants

A successful focus group session has participants who are willing to both offer their insights and perspectives on a specific topic and listen to the opinions of the other participants. A focus group typically has 6 to 12 attendees. It may be necessary to invite additional individuals to compensate for those who do not attend the session due to scheduling conflicts, emergencies, or other reasons. If many participants are needed, it may be necessary to run more than one focus group. Often participants of a focus group are paid for their time.
The demographics of the participants are determined based on the objective of the focus group.

.4 Discussion Guide

A discussion guide provides the moderator with a prepared script of specific questions and topics for discussion that meet the objective of the session.
Discussion guides also include the structure or framework that the moderator will follow. This includes obtaining general feedback and comments before delving into specifics. Discussion guides also remind the moderator to welcome and introduce the participants, as well as to explain the objectives of the session, how the session will be conducted, and how the feedback will be used.

.5 Assign a Moderator and Recorder

The moderator is both skilled at keeping the session on track and knowledgeable about the initiative. Moderators are able to engage all participants and are adaptable and flexible. The moderator is an unbiased representative of the feedback process.
The recorder takes notes to ensure the participant’s opinions are accurately recorded.
The business analyst can fill the role of either the moderator or the recorder. The moderator and recorder are not considered active participants in the focus group session and do not submit feedback.

.6 Conduct the Focus Group

The moderator guides the group’s discussion, follows a prepared script of specific issues, and ensures that the objectives are met. However, the group discussion

should appear free-flowing and relatively unstructured to the participants. A session is typically one to two hours in length. A recorder captures the group’s comments.

.7 After the Focus Group

The results of the focus group are transcribed as soon as possible after the session has ended. The business analyst analyzes and documents the participants’ agreements and disagreements, looks for trends in the responses, and creates a report that summarizes the results.

10.21.4 Usage Considerations

.1 Strengths

• The ability to elicit data from a group of people in a single session saves both time and costs as compared to conducting individual interviews with the same number of people.
• Effective for learning people’s attitudes, experiences, and desires.
• Active discussion and the ability to ask others questions creates an environment in which participants can consider their personal view in relation to other perspectives.
• An online focus group is useful when travel budgets are limited and participants are distributed geographically.
• Online focus group sessions can be recorded easily for playback.

.2 Limitations

• In a group setting, participants may be concerned about issues of trust or may be unwilling to discuss sensitive or personal topics.
• Data collected about what people say may not be consistent with how people actually behave.
• If the group is too homogeneous their responses may not represent the complete set of requirements.
• A skilled moderator is needed to manage group interactions and discussions.
• It may be difficult to schedule the group for the same date and time.
• Online focus groups limit interaction between participants.
• It is difficult for the moderator of an online focus group to determine attitudes without being able to read body language.
• One vocal participant could sway the results of the focus group.

10.22 Functional Decomposition

10.22.1 Purpose

Functional decomposition helps manage complexity and reduce uncertainty by breaking down processes, systems, functional areas, or deliverables into their simpler constituent parts and allowing each part to be analyzed independently.

10.22.2 Description

Functional decomposition approaches the analysis of complex systems and concepts by considering them as a set of collaborating or related functions, effects, and components. This isolation helps reduce the complexity of the analysis. Breaking down larger components into sub-components allows scaling, tracking, and measuring work effort for each of them. It also facilitates evaluation of the success of each sub-component as it relates to other larger or smaller components.
The depth of decomposition may vary depending on the nature of components and objectives. Functional decomposition assumes that sub-components can and do completely describe their parent components. Any sub-component can have only one parent component when developing the functional hierarchy.
The diagram below provides an example of how a function can be broken down to manageable, measurable sub-components.

Figure 10.22.1: Functional Decomposition Diagram

**

10.22.3 Elements

.1 Decomposition Objectives
Objectives of functional decomposition both drive the process of decomposition and define what to decompose, how to decompose, and how deeply to decompose.
The objectives may include:
• Measuring and Managing: to isolate specific manageable factors that contribute to the overall result, or to identify important metrics and indicators.
• Designing: to simplify a design problem by reducing and isolating the object of design.
• Analyzing: to study the essential properties and behaviours of an artifact or phenomenon in isolation from its encompassing environment.
• Estimating and Forecasting: to decrease the level of uncertainty by breaking down a complex value into its constituent factors.
• Reusing: to create a reusable solution building block that serves a specific function for various processes.
• Optimization: to detect or alleviate a bottleneck, reduce function cost, or improve process quality.
• Substitution: to make a specific implementation of a solution component or a function easily replaceable without impacting the system as a whole.
• Encapsulation: combining elements to make one element.

.2 Subjects of Decomposition

Functional decomposition applies to a wide variety of versatile subjects, such as:
• Business Outcomes: for example, income, profit, expenses, volume of service, or volume of production.
• Work to be Done: this decomposition (known as a Work Breakdown Structure or WBS) breaks endeavours into phases, milestones, work activities, tasks, work items, and deliverables.
• Business Process: to identify its constituent parts for the purposes of measuring, managing, optimizing, or reusing the process or its components.
• Function: to enable its optimization or implementation.
• Business Unit: to enable its reverse engineering and design.
• Solution Component: to enable its design, implementation, or change.
• Activity: to enable its implementation, modification, optimization, measurement, and estimation.
• Products and Services: to design, implement, and improve them.

• Decisions: for enabling, improving, or supporting them by identifying their inputs, underlying models, dependencies, and outcomes.

.3 Level of Decomposition

The appropriate level of functional decomposition defines where, why, and when to stop decomposing the subject in order to meet the analysis objectives. The process of functional decomposition continues until the business analyst has just enough understanding and detail to proceed and can apply the results of decomposition in the execution of other tasks.

.4 Representation of Decomposition Results

Representations of functional decomposition results allow business analysts to both validate and verify the results and to use them to solve other tasks. The results can be expressed as a combination of plain textual descriptions, hierarchical lists, descriptions using special formal notations (for example, mathematical formulas, Business Process Execution Language, or programming languages), and visual diagrams. A wide variety of diagramming techniques can be used to represent functional decomposition, including:
• Tree diagrams: represent hierarchical partitioning of work, activities, or deliverables.
• Nested diagrams: illustrate hierarchical part-to-whole relationships between decomposition results.
• Use Case diagrams: represent decomposition of a higher-level use case.
• Flow diagrams: depict results of a process or function decomposition.
• State Transition diagrams: explain the behaviour of an object inside its composite state.
• Cause-Effect diagrams: elaborate on events, conditions, activities, and effects involved in producing a complex outcome or phenomenon.
• Decision Trees: detail the structure of a complex decision and its potential outcomes.
• Mind Maps: represent information in categories.
• Component diagram: depicts how components are wired together to form larger components and/or software systems.
• Decision Model and Notation: is used to analyze the business logic to ensure that it has inferential and business integrity.

10.22.4 Usage Considerations

.1 Strengths

• Makes complex endeavours possible by breaking down complex problems into feasible parts.

Glossary Techniques

• Provides a structured approach to building a shared understanding of complex matters among a diverse group of stakeholders.
• Simplifies measurement and estimation of the amount of work involved in pursuing a course of action, defining scope of work, and defining process metrics and indicators.

.2 Limitations

• Missing or incorrect information at the time decomposition is performed may later cause a need to revise the results of decomposition partially or entirely.
• Many systems cannot be fully represented by simple hierarchical relationships between components because the interactions between components cause emergent characteristics and behaviours.
• Every complex subject allows multiple alternative decompositions. Exploring all alternatives can be a challenging and time-consuming task, while sticking with a single alternative may disregard important opportunities and result in a sub- optimal solution.
• Performing functional decomposition may involve deep knowledge of the subject and extensive collaboration with diverse stakeholders.

10.23 Glossary

10.23.1 Purpose

A glossary defines key terms relevant to a business domain.

10.23.2 Description

Glossaries are used to provide a common understanding of terms that are used by stakeholders. A term may have different meanings for any two people. A list of terms and established definitions provides a common language that can be used to communicate and exchange ideas. A glossary is organized and continuously accessible to all stakeholders.

10.23.3 Elements

A glossary is a list of terms in a particular domain with definitions for those terms and their common synonyms. Organizations or industries may use a term differently than how it is generally understood.
A term is included in the glossary when:
• the term is unique to a domain,
• there are multiple definitions for the term,
• the definition implied is outside of the term’s common use, or
• there is a reasonable chance of misunderstanding.

Techniques Interface Analysis

The creation of a glossary should take place in the early stages of a project in order to facilitate knowledge transfer and understanding. A point of contact responsible for the maintenance and distribution of the glossary throughout the initiative is identified. Organizations that maintain glossaries often find additional uses for this information and are able to leverage the glossary for future initiatives.
Consider the following when developing a glossary:
• definitions should be clear, concise, and brief,
• acronyms should be spelled out if used in a definition,
• stakeholders should have easy and reliable access to glossaries, and
• the editing of a glossary should be limited to specific stakeholders.

10.23.4 Usage Considerations

.1 Strengths

• A glossary promotes common understanding of the business domain and better communication among all stakeholders.
• Capturing the definitions as part of an enterprise’s documentation provides a single reference and encourages consistency.
• Simplifies the writing and maintenance of other business analysis information including but not limited to requirements, business rules, and change strategy.

.2 Limitations

• A glossary requires an owner to perform timely maintenance, otherwise it becomes outdated and may be ignored.
• It may be challenging for different stakeholders to agree on a single definition for a term.

10.24 Interface Analysis

10.24.1 Purpose

Interface analysis is used to identify where, what, why, when, how, and for whom information is exchanged between solution components or across solution boundaries.

10.24.2 Description

An interface is a connection between two components or solutions. Most solutions require one or more interfaces to exchange information with other solution components, organizational units, or business processes.

Interface Analysis Techniques

Interface types include:
• user interfaces, including human users directly interacting with the solution within the organization,
• people external to the solution such as stakeholders or regulators,
• business processes,
• data interfaces between systems,
• application programming interfaces (APIs), and
• any hardware devices.
Interface analysis defines and clarifies the following:
• who will use the interface,
• what information is being exchanged through the interface, as well as the volume of the data,
• when information will be exchanged and how frequently,
• where the information exchange will occur,
• why the interface is needed, and
• how the interface is or should be implemented.
The early identification of interfaces allows the business analyst to provide the context for eliciting more detailed stakeholder requirements, thus determining adequate functional coverage of the solution to meet stakeholder needs. Early identification of interfaces reveals which stakeholders will benefit from or depend on the various components of the solution, which can help the business analyst determine which stakeholders should be present for other elicitation techniques.

Figure 10.24.1: Interface Analysis

Interface

Input Message

Message
**

10.24.3 Elements

.1 Preparing for Identification

The business analyst can leverage other techniques, such as document analysis, observation, scope modelling, and interviews, in order to understand which interfaces need to be identified. A context diagram can reveal high-level

interfaces between human actors, organizational units, business processes, or other solution components. The results of this analysis can reveal how frequently any existing interfaces are being used and any problems with them that may strengthen the case for change. The results may also help identify any key issues that need to be resolved in order for an interface solution to be created.

.2 Conduct Interface Identification

Business analysts identify what interfaces are needed in the future state for each stakeholder or system that interacts with the system. The relationship between stakeholders and interfaces can be many-to-many or, in some cases, one-to-one. Some interfaces may be less obvious or less frequent such as an interface used for regulatory functions or auditing, or for employee training. Identified interfaces can include interfaces from solutions other than the operational solution.
For each interface, business analysts:
• describe the function of the interface,
• assess the frequency of the interface usage,
• evaluate which type of interface may be appropriate, and
• elicit initial details about the interface.

.3 Define Interfaces

Requirements for an interface are primarily focused on describing the inputs to and outputs from that interface, any validation rules that govern those inputs and outputs, and events that might trigger interactions. There may be a large number of possible interaction types, each of which needs to be specified. Interactions may be triggered by the typical or alternate flow of inputs and outputs in the business solution, or by exceptional events such as failures.
Business analysts consider who will use the interface, what information is passed over the interface, and when and where the interface takes place. The interface defines user workflow between systems, user roles and privileges, and any management objectives for the interface. Interface definition is dependent upon usability guidelines, such as accessibility requirements or general workflow requirements.
In order to identify any major design issues, interfaces between solution or process components and people require detailed analysis of the interface to be conducted upfront. Interface definition includes:
• the name of the interface,
• the coverage or span of the interface,
• the exchange method between the two entities,
• the message format, and
• the exchange frequency.

10.24.4 Usage Considerations

.1 Strengths

• By engaging in interface analysis early on, increased functional coverage is provided.
• Clear specification of the interfaces provides a structured means of allocating requirements, business rules, and constraints to the solution.
• Due to its broad application, it avoids over analysis of fine detail.

.2 Limitations

• Does not provide insight into other aspects of the solution since the analysis does not assess the internal components.

10.25 Interviews

10.25.1 Purpose

An interview is a systematic approach designed to elicit business analysis information from a person or group of people by talking to the interviewee(s), asking relevant questions, and documenting the responses. The interview can also be used for establishing relationships and building trust between business analysts and stakeholders in order to increase stakeholder involvement or build support for a proposed solution.

10.25.2 Description

The interview is a common technique for eliciting requirements. It involves direct communication with individuals or groups of people who are part of an initiative.
In an interview, the interviewer directs questions to stakeholders in order to obtain information. One-on-one interviews are the most common. In a group interview (with more than one interviewee in attendance), the interviewer is careful to elicit responses from each participant.
There are two basic types of interviews used to elicit business analysis information:
• Structured Interview: in which the interviewer has a predefined set of questions.
• Unstructured Interview: in which the interviewer does not have a predetermined format or order of questions. Questions may vary based on interviewee responses and interactions.
In practice, business analysts may use a combination of the two types by adding, dropping, and varying the order of questions as needed.

Successful interviewing depends on factors such as:
• level of understanding of the domain by the interviewer,
• experience of the interviewer in conducting interviews,
• skill of the interviewer in documenting discussions,
• readiness of the interviewee to provide the relevant information and the interviewer to conduct the interview,
• degree of clarity in the interviewee’s mind about the goal of the interview, and
• rapport of the interviewer with the interviewee.

10.25.3 Elements

.1 Interview Goal

When planning interviews, business analysts consider:
• the overall purpose of performing a set of interviews, based on a business need, and
• the individual goals for each interview, based on what the interviewee can provide.
The goals are to be clearly expressed and communicated to each interviewee.

.2 Potential Interviewees

Potential interviewees are identified with the help of the project manager, project sponsors, and other stakeholders, based on the goals for the interview.

.3 Interview Questions

Interview questions are designed according to the interview goals, such as:
• collecting data,
• researching the stakeholder’s view of the change or proposed solution,
• developing a proposed solution, or
• building rapport with or support for the proposed solution from the interviewee.
Open-ended questions are used to elicit a dialogue or series of steps and cannot be answered in a yes or no fashion. Open-ended questions are a good tool to allow the interviewee to provide information of which the interviewer may be unaware.
Closed questions are used to elicit a single response such as yes, no, or a specific number. Closed questions can be used to clarify or confirm a previous answer.
The interview questions are often organized based on priority and significance. Examples of question order include general to specific, start to finish, and detailed to summary. Questions can also be organized based on factors such as the interviewee’s level of knowledge and the subject of the interview.

Interview questions may be customized when the purpose of the interview is to gather information that is unique to the perspective of the interviewee.
Standardized questions may be used when the interview results will be summarized and analyzed, such as when interview results will be tallied using a check sheet.
Interview questions can be compiled in an interview guide, which includes the interview questions, proposed timing, and follow-up questions. This will all be based on the interview type, according to the interview goals, mode of communication, and duration. The interview guide can be a document where the interviewee’s responses are easily recorded. The interview guide should identify which interview questions may be omitted based upon time constraints.

.4 Interview Logistics

Ensuring a successful interview requires attention to logistics that include:
• The location for the interview. The interview is adapted to the schedule and availability of the interviewee and the mode of communication (in-person, phone, or online conferencing).
• Whether or not to record the interview, which may require the use of a scribe.
• Whether or not to send the questions to the interviewees in advance. Sending questions in advance is advisable only when the interviewee needs to collect information to prepare for the interview.
• Whether the interview results will be confidential and, if so, how the results will be summarized to avoid identifying individual interviewees.

.5 Interview Flow

Opening the interview includes:
• describing the purpose of the interview, including why the interviewees’ time is needed,
• confirming the interviewees’ roles and addressing any initial concerns raised by the interviewees, and
• explaining how information from the interview will be recorded and shared with the interviewees and other stakeholders during the project.
During the interview, the interviewer:
• maintains focus on the established goals and predefined questions, and adapts based upon the information provided and non-verbal communication from the interviewees,
• considers both the willingness of the interviewees to participate in the interview and to provide the required information,
• considers that several meetings might be required to conduct the entire interview,
• manages concerns raised by the interviewees by addressing them during the interview or documenting them for follow-up,

• practices active listening to confirm what the interviewer has said, and
• takes written notes or records the interview as appropriate. Closing the interview includes:
• asking the interviewees for areas that may have been overlooked in the
session,
• providing contact information for the interviewees to follow up with additional information after the meeting as needed,
• summarizing the session,
• outlining the process for how the interview results will be used, and
• thanking the interviewees for their time.

.6 Interview Follow-Up

It is important for the interviewer to organize the information and confirm results with the interviewees as soon as possible after the interview. Sharing the information that has been learned allows the interviewees to point out any missed or incorrectly recorded items.

10.25.4 Usage Considerations

.1 Strengths

• Encourages participation by and establishes rapport with stakeholders.
• Simple, direct technique that can be used in a variety of situations.
• Allows the interviewer and participant to have full discussions and explanations of the questions and answers.
• Enables observations of non-verbal behaviour.
• The interviewer can ask follow-up and probing questions to confirm their own understanding.
• Maintains focus through the use of clear objectives for the interview that are agreed upon by all participants and can be met in the time allotted.
• Allows interviewees to express opinions in private that they may be reluctant to express in public, especially when interview results are kept confidential.

.2 Limitations

• Significant time is required to plan for and conduct interviews.
• Requires considerable commitment and involvement of the participants.
• Training is required to conduct effective interviews.
• Based on the level of clarity provided during the interview, the resulting documentation may be subject to the interviewer’s interpretation.
• There is a risk of unintentionally leading the interviewee.

10.26 Item Tracking

10.26.1 Purpose

Item tracking is used to capture and assign responsibility for issues and stakeholder concerns that pose an impact to the solution.

10.26.2 Description

Item tracking is an organized approach used by business analysts to address stakeholder concerns. Stakeholders may identify such item types as actions, assumptions, constraints, dependencies, defects, enhancements, and issues.
When a stakeholder concern is first raised, it is assessed to determine if it is viable. If viable, the concern is classified as a specific item type so that it can be better tracked and controlled by a process that works towards the item’s closure. During its life cycle, an item is assigned to one or more stakeholders who are responsible for its resolution.
Item tracking tracks the item from the initial recording of the concern and its degree of impact to its agreed-upon closure. The item tracking record may be shared with stakeholders to ensure transparency and visibility into the status and progress of items in the record.

10.26.3 Elements

.1 Item Record

Each recorded item may contain all or any of the following attributes for item tracking. These items may be recorded using various software applications or manually catalogued for sharing between an agreed set of stakeholders.
• Item Identifier: a unique identifier that distinguishes one item from another.
• Summary: a brief description of the item.
• Category: a grouping of items with similar properties.
• Type: the kind of item raised.
• Date Identified: the date the item was raised as a concern.
• Identified By: the person who initially raised the concern.
• Impact: the possible consequences if the item is not resolved by the resolution due date. Impact can be assessed in relation to the initiative’s time, cost, scope, or quality.
• Priority: the importance of this item to the impacted stakeholders.
• Resolution Date: the date by which the item must be resolved (or closed).
• Owner: the stakeholder assigned to manage the item to its closure.

• Resolver: the stakeholder assigned to resolve the item.
• Agreed Strategy: agreed-upon strategy for the item. Examples include accept, pursue, ignore, mitigate, and avoid.
• Status: the current status of the item within its life cycle. Examples include open, assigned, resolved, and cancelled.
• Resolution Updates: a running log of details about how the item’s resolution is proceeding towards closure, as well as approval of its completion.
• Escalation Matrix: a level of escalation in case the item is not resolved by the given due date.

.2 Item Management

Each item’s resolution is undertaken as prescribed by stakeholder needs and according to any organizational process standards. In some cases, one item may cause another item to be recorded and tracked. In these situations, close attention is needed so that item resolution efforts are not duplicated and are progressing in coordination. Each item must be tracked to its closure or resolution.

.3 Metrics

All stakeholders benefit from the detailed information that is maintained about any item and its progress. These items can be looked at individually for resolution or even used to define key performance indicators tailored to the item tracking process.
By reviewing this output, stakeholders can determine how well:
• items are being resolved by the proper resources,
• the initiative is progressing, and
• the item tracking process is being utilized.

10.26.4 Usage Considerations

.1 Strengths

• Ensures concerns around stakeholder requirements are captured, tracked, and resolved to the stakeholder’s satisfaction.
• Allows stakeholders to rank the importance of outstanding items.

.2 Limitations

• If not careful, the copious recording of data about items may outweigh any benefits realized.
• It may use time that could be better spent on other efforts and stakeholders could become mired in details and statistics.

10.27 Lessons Learned

10.27.1 Purpose

The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases.

10.27.2 Description

A lessons learned session (also known as a retrospective) helps identify either changes to business analysis processes and deliverables or successes that can be incorporated into future work. These techniques can also be beneficial at the close of any milestone within the effort.
Lessons learned sessions can include any format or venue that is acceptable to the key stakeholders and can be either formal facilitated meetings with set agendas and meeting roles or informal working sessions. If there are noteworthy successes, a celebration may be included in a lessons learned session.

10.27.3 Elements

Sessions can include a review of:
• business analysis activities or deliverables,
• the final solution, service, or product,
• automation or technology that was introduced or eliminated,
• impact to organizational processes,
• performance expectations and results,
• positive or negative variances,
• root causes impacting performance results, and
• recommendations for behavioural approaches.

10.27.4 Usage Considerations

.1 Strengths

• Useful in identifying opportunities or areas of improvement.
• Assists in building team morale after a difficult period.
• Reinforces positive experiences and successes.
• Reduces risks for future actions.
• Provides tangible value or metrics as a result of the effort.
• Recognizes strengths or shortcomings with the project structure, methodology, or tools that were used.

.2 Limitations

• Honest discussion may not occur if participants try to assign blame during these sessions.
• Participants may be reluctant to document and discuss problems.
• Proactive facilitation may be required to ensure that the discussions remain focused on solutions and improvement opportunities.

10.28 Metrics and Key Performance Indicators (KPIs)

10.28.1 Purpose

Metrics and key performance indicators measure the performance of solutions, solution components, and other matters of interest to stakeholders.

10.28.2 Description

A metric is a quantifiable level of an indicator that an organization uses to measure progress. An indicator identifies a specific numerical measurement that represents the degree of progress toward achieving a goal, objective, output, activity, or further input. A key performance indicator (KPI) is one that measures progress towards a strategic goal or objective. Reporting is the process of informing stakeholders of metrics or indicators in specified formats and at specified intervals.
Metrics and reporting are key components of monitoring and evaluation. Monitoring is a continuous process of data collection used to determine how well a solution has been implemented as compared to the expected results. Evaluation is the systematic and objective assessment of a solution both to determine its status and effectiveness in meeting objectives over time and to identify ways to improve the solution to better meet objectives. The top priorities of a monitoring and evaluation system are the intended goals and effects of a solution, as well as inputs, activities, and outputs.

10.28.3 Elements

.1 Indicators

An indicator displays the result of analyzing one or more specific measures for addressing a concern about a need, value, output, activity, or input in a table or graphical form. Each concern requires at least one indicator to measure it properly, but some may require several.
A good indicator has six characteristics:
• Clear: precise and unambiguous.
• Relevant: appropriate to the concern.

• Economical: available at reasonable cost.
• Adequate: provides a sufficient basis on which to assess performance.
• Quantifiable: can be independently validated.
• Trustworthy and Credible: based on evidence and research.
In addition to these characteristics, stakeholder interests are also important. Certain indicators may help stakeholders perform or improve more than others. Over time, weaknesses in some indicators can be identified and improved.
Not all factors can be measured directly. Proxies can be used when data for direct indicators are not available or when it is not feasible to collect at regular intervals. For example, in the absence of a survey of client satisfaction, an organization might use the proportion of all contracts renewed as an indicator.
When establishing an indicator, business analysts will consider its source, method of collection, collector, and the cost, frequency, and difficulty of collection.
Secondary sources of data may be the most economical, but to meet the other characteristics of a good indicator, primary research such as surveys, interviews, or direct observations may be necessary. The method of data collection is the key driver of a monitoring, evaluation, and reporting system’s cost.

.2 Metrics

Metrics are quantifiable levels of indicators that are measured at a specified point in time. A target metric is the objective to be reached within a specified period. In setting a metric for an indicator, it is important to have a clear understanding of the baseline starting point, resources that can be devoted to improving the factors covered by the indicator, and political concerns.
A metric can be a specific point, a threshold, or a range. A range can be useful if the indicator is new. Depending on the need, the scope of time to reach the target metric can be multi-year, annual, quarterly, or even more frequent.

.3 Structure

Establishing a monitoring and evaluation system requires a data collection procedure, a data analysis procedure, a reporting procedure, and the collection of baseline data. The data collection procedure covers units of analysis, sampling procedures, data collection instruments to use, collection frequency, and responsibility for collection. The analysis method specifies both the procedures for conducting the analysis and the data consumer, who may have strong interests in how the analysis is conducted. The reporting procedure covers the report templates, recipients, frequency, and means of communication. Baseline information is the data provided immediately before or at the beginning of a period to measure. Baseline data is used both to learn about recent performance and to measure progress from that point forward. It needs to be collected, analyzed, and reported for each indicator.
There are three key factors in assessing the quality of indicators and their metrics: reliability, validity, and timeliness. Reliability is the extent to which the data collection approach is stable and consistent across time and space. Validity is the

extent to which data clearly and directly measures the performance the organization intends to measure. Timeliness is the fit of the frequency and latency of data to the management’s need.

.4 Reporting

Typically, reports compare the baseline, current metrics, and target metrics with calculations of the differences presented in both absolute and relative terms. In most situations, trends are more credible and important than absolute metrics. Visual presentations tend to be more effective than tables, particularly when using qualitative text to explain the data.

10.28.4 Usage Considerations

.1 Strengths

• Establishing a monitoring and evaluation system allows stakeholders to understand the extent to which a solution meets an objective, as well as how effective the inputs and activities of developing the solution (outputs) were.
• Indicators, metrics, and reporting also facilitate organizational alignment, linking goals to objectives, supporting solutions, underlying tasks, and resources.

.2 Limitations

• Gathering excessive amounts of data beyond what is needed will result in unnecessary expense in collecting, analyzing, and reporting. It will also distract project members from other responsibilities. On Agile projects, this will be particularly relevant.
• A bureaucratic metrics program fails from collecting too much data and not generating useful reports that will allow timely action. Those charged with collecting metric data must be given feedback to understand how their actions are affecting the quality of the project results.
• When metrics are used to assess performance, the individuals being measured are likely to act to increase their performance on those metrics, even if this causes sub-optimal performance on other activities.

10.29 Mind Mapping

10.29.1 Purpose

Mind mapping is used to articulate and capture thoughts, ideas, and information.

10.29.2 Description

Mind mapping is a form of note taking that captures thoughts, ideas, and information in a non-linear diagram. Mind maps use images, words, colour, and

connected relationships to apply structure and logic to thoughts, ideas, and information. A mind map has a central main idea supported by secondary ideas (or topics), followed by as many layers of ideas (or sub-topics) as necessary to fully capture and articulate the concept. Connections are made between ideas by branches that typically have a single keyword associated with them that explain the connection.
Mind maps can be developed individually or as a collaboration exercise. They can be created on paper or with the use of specialized software.
Business analysts use mind maps to:
• think through and generate ideas on complex concepts or problems,
• explore relationships between the various facets of a problem in a way that inspires creative and critical thinking, and
• present a consolidated view of complex concepts or problems.
There is no standardized format for a mind map. The intent of a mind map is to capture information in a fashion closely resembling how our minds process information. The following image is intended to illustrate the general structure and usage of mind maps.

Figure 10.29.1: The Taxonomy of a Mind Map

Sub-topic 1.1 Sub-topic 3.1

10.29.3 Elements

.1 Main Topic

The main topic of a mind map is the thought or concept that is being articulated. The main topic is positioned in the centre of the images so that multiple topics and associations can branch off. Images are frequently used as the main topic because they contain a great deal of information and can be useful in stimulating associated topics.

.2 Topics

Topics are thoughts or concepts that expound upon or further articulate the main topic. Their association with the main topic is expressed through a branch (connected line) that has a keyword associated with it. There can be as many or as few topics as required to fully explore the thought or concept of the main topic.

.3 Sub-topics

Sub-topics are thoughts or concepts that expound upon or further articulate the topic and directly relate to the main topic. Their association with the topic is expressed through a branch (connected line) that has a keyword associated with it. There can be as many or as few sub-topics as required to fully explore the thought or concept of the main topic.

.4 Branches

Branches are the associations between the main topic, topics, and sub-topics. Branches include a keyword that clearly articulates the nature of the association.

.5 Keywords

Keywords are single words used to articulate the nature of the association of topics or sub-topics connected by a branch. The keywords are useful for both categorizing topics and for triggering additional associations.

.6 Colour

Colour may be used to categorize, prioritize, and analyze topics, sub-topics, and their associations. There is no defined colour coding standard for mind maps.
Each mind map creator applies colour in a way that best suits their mode of thinking.

.7 Images

Images can be used in mind maps to express larger volumes of information that are unable to be expressed in short topic headings. Images are useful in stimulating creativity and innovation by generating additional thoughts, ideas, and associations.

10.29.4 Usage Considerations

.1 Strengths

• Can be used as an effective collaboration and communication tool.
• Summarizes complex thoughts, ideas, and information in a way that shows the overall structure.
• Associations and sub-topics facilitate understanding and decision making.
• Enable creative problem solving by articulating associations and generating new associations.
• Can be helpful in preparing and delivering presentations.

.2 Limitations

• Can be misused as a brainstorming tool, and the related documenting of ideas and creating associations may inhibit idea generation.
• A shared understanding of a mind map can be difficult to communicate.

10.30 Non-Functional Requirements Analysis

10.30.1 Purpose

Non-functional requirements analysis examines the requirements for a solution that define how well the functional requirements must perform. It specifies criteria that can be used to judge the operation of a system rather than specific behaviours (which are referred to as the functional requirements).

10.30.2 Description

Non-functional requirements (also known as quality attributes or quality of service requirements) are often associated with system solutions, but they also apply more broadly to both process and people aspects of solutions. They augment the functional requirements of a solution, identify constraints on those requirements, or describe quality attributes a solution must exhibit when based on those functional requirements.
Non-functional requirements are generally expressed in textual formats as declarative statements or in matrices. Declarative non-functional requirements statements will typically have a constraining factor to them. For example, errors must not exceed X per use of the process, transactions must be at least X% processed after S seconds, or the system must be available X% of the time.

10.30.3 Elements

.1 Categories of Non-Functional Requirements

Common categories of non-functional requirements include:
• Availability: degree to which the solution is operable and accessible when required for use, often expressed in terms of percent of time the solution is available.
• Compatibility: degree to which the solution operates effectively with other components in its environment, such as one process with another.
• Functionality: degree to which the solution functions meet user needs, including aspects of suitability, accuracy, and interoperability.
• Maintainability: ease with which a solution or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment.
• Performance Efficiency: degree to which a solution or component performs its designated functions with minimum consumption of resources. Can be defined based on the context or period, such as high-peak, mid- peak or off-peak usage.
• Portability: ease with which a solution or component can be transferred from one environment to another.
• Reliability: ability of a solution or component to perform its required functions under stated conditions for a specified period of time, such as mean time to failure of a device.
• Scalability: degree with which a solution is able to grow or evolve to handle increased amounts of work.
• Security: aspects of a solution that protect solution content or solution components from accidental or malicious access, use, modification, destruction, or disclosure.
• Usability: ease with which a user can learn to use the solution.
• Certification: constraints on the solution that are necessary to meet certain standards or industry conventions.
• Compliance: regulatory, financial, or legal constraints which can vary based on the context or jurisdiction.
• Localization: requirements dealing with local languages, laws, currencies, cultures, spellings, and other characteristics of users, which requires attention to the context.
• Service Level Agreements: constraints of the organization being served by the solution that are formally agreed to by both the provider and the user of the solution.
• Extensibility: the ability of a solution to incorporate new functionality.

.2 Measurement of Non-Functional Requirements

Non-functional requirements often describe quality characteristics in vague terms, such as “the process must be easy to learn”, or “the system must respond quickly”. To be useful to developers of a solution and to be verifiable, non- functional requirements must be quantified whenever possible. Including an appropriate measure of success provides the opportunity for verification.
For example:
• “The process must be easy to learn” can be expressed as “90% of operators must be able to use the new process after no more than six hours of training”, and
• “The system must respond quickly” can be expressed as “The system must provide 90% of responses in no more than two seconds”.
Measurement of the other categories of non-functional requirements is guided by the source of the requirement.
For example:
• certification requirements are generally specified in measurable detail by the organization setting the standard or convention, such as ISO Certification standards,
• compliance requirements and localization requirements are set in measurable detail by their providers,
• effective service level agreements state clearly the measures of success required, and
• an organization’s enterprise architecture generally defines the solution environment requirements and specifies exactly which platform or other attribute of the environment is required.

.3 Context of Non-Functional Requirements

Depending on the category of non-functional requirements, the context may have to be considered. For example, a regulatory agency may impose context- impacting compliance and security requirements, or an organization that is expanding operations abroad may have to consider localization and scalability requirements. Determining the optimal portfolio of non-functional requirements in a given organizational context is central to delivering value to stakeholders.
The assessment of a non-functional requirement, such as localization or maintainability, may impose contextual pressures on other non-functional requirements. For instance, regulations or resources in one jurisdiction may affect the maintainability of a solution in that region, and so it may justify a lower performance efficiency or reliability measure of success than in another jurisdiction.
Context is dynamic by nature and non-functional requirements may need to be adjusted or removed outright. Business analysts consider the relative stability of the context when evaluating non-functional requirements.

10.30.4 Usage Considerations

.1 Strengths

• Clearly states the constraints that apply to a set of functional requirements.
• Provides measurable expressions of how well the functional requirements must perform, leaving it to the functional requirements to express what the solution must do or how it must behave. This will also have a strong influence on whether the solution is accepted by the users.

.2 Limitations

• The clarity and usefulness of a non-functional requirement depends on what the stakeholders know about the needs for the solution and how well they can express those needs.
• Expectations of multiple users may be quite different, and getting agreement on quality attributes may be difficult because of the users’ subjective perception of quality. For example, what might be ‘too fast’ to one user might be ‘too slow’ to another.
• A set of non-functional requirements may have inherent conflicts and require negotiation. For example, some security requirements may require compromises on performance requirements.
• Overly strict requirements or constraints can add more time and cost to the solution, which may have negative impacts and weaken adoption by users.
• Many non-functional requirements are qualitative and therefore may be difficult to be measured on a scale, and may garner a degree of subjectivity by the users as to how they believe the particular requirements ultimately meet their needs.

10.31 Observation

10.31.1 Purpose

Observation is used to elicit information by viewing and understanding activities and their context. It is used as a basis for identifying needs and opportunities, understanding a business process, setting performance standards, evaluating solution performance, or supporting training and development.

10.31.2 Description

Observation of activities, also known as job shadowing, involves examining a work activity firsthand as it is performed. It can be conducted in either natural work environments or specially constructed laboratory conditions. The objectives of the observation dictate how it is planned for and methodically conducted.

There are two basic approaches for observation:
• Active/Noticeable: while observing an activity the observer asks any questions as they arise. Despite this interruption to the work flow, the observer can more quickly understand the rationale and hidden processes underlying the activity, such as decision making. A variation of this method may involve even stronger intervention into actors’ activities by stimulating them to perform specific tasks. This kind of facilitated observation allows focus on the observer’s objectives in order to shorten observation time or elicit specific information.
• Passive/Unnoticeable: during the activity the observer does not interrupt the work. Any concerns are raised once the observation is over. This allows observation of a natural flow of events without intervention by the observer, as well as measurement of the time and quality of work. A variation of this method is video recording the activity and then reviewing it with the person being observed so they may provide further clarification.
Inspection of a person’s work environment helps in discovering any tools and information assets involved in performing their activities. This supports understanding of the activities, especially with the purpose of identifying needs and opportunities. This kind of observation is an important part of the technique’s variation, and is known as Contextual Inquiry.

10.31.3 Elements

.1 Observation Objectives

A clear and specific objective establishes a defined purpose of the observation session.
Objectives of an observation session may include:
• understanding the activity and its elements such as tasks, tools, events, and interactions,
• identifying opportunities for improvement,
• establishing performance metrics, or
• assessing solutions and validating assumptions.

.2 Prepare for Observation

Preparing for an observation session involves planning the observation approach based on the objectives and deciding who should be viewed performing which activities at what times. While preparing for an observation session, business analysts consider the skill and experience levels of participants, the frequency of the activities being observed, and any existing documentation and analysis related to the work activity. Preparing for observation also includes creating a schedule of observations.
The plan for observation ensures that all stakeholders are aware of the purpose of the observation session, they agree on the expected outcomes, and that the session meets their expectations.

.3 Conduct the Observation Session

Before the observation session:
• explain why the observation is being conducted,
• reassure the participant that their personal performance is not being judged and that the results of this observation, among others, will be evaluated as a whole,
• inform the participant that they can stop the observation at any time, and
• recommend the sharing of any reasoning or concerns while performing the activity or soon afterwards.
During the observation session:
• attentively watch the person perform the activity and note typical and atypical tasks or steps, the manner in which any tools are used, and information content,
• record what is seen, the time taken to perform the work, its quality, any process anomalies, and the observer’s own concerns or questions, and
• ask probing questions either while the work is being performed or soon after the observation session.

.4 Confirm and Present Observation Results

After the observation session, business analysts review the notes and data recorded from the observation and follow up with the participant to obtain answers to any remaining questions or to fill any gaps. Sharing these notes and data with participants may be helpful in obtaining answers to any questions or easing any concerns the participant may have.
The validated notes and data are collated with other related observations to identify similarities, differences, and trends. Findings are aggregated, summarized, and analyzed against the objectives of the session. Needs and opportunities for improvement are communicated to stakeholders.

10.31.4 Usage Considerations

.1 Strengths

• Observers can gain realistic and practical insight about the activities and their tasks within an overall process.
• Instances of informally performed tasks as well as any workarounds can be identified.
• Productivity can be viewed firsthand and realistically compared against any established performance standards or metrics.
• Recommendations for improvement are supported by objective and quantitative evidence.

.2 Limitations

• May be disruptive to the performance of the participant and the overall organization.
• Can be threatening and intrusive to the person being observed.
• While being observed, a participant may alter their work practices.
• Significant time is required to plan for and conduct observations.
• Not suitable for evaluating knowledge-based activities since these are not directly observable.

10.32 Organizational Modelling

10.32.1 Purpose

Organizational modelling is used to describe the roles, responsibilities, and reporting structures that exist within an organization and to align those structures with the organization’s goals.

10.32.2 Description

An organizational model defines how an organization or organizational unit is structured. The purpose of an organizational unit is to bring together a group of people to fulfill a common purpose. The group may be organized because the people share a common set of skills and knowledge or to serve a particular market.
An organizational model is a visual representation of the organizational unit which defines:
• the boundaries of the group (who is in the group),
• the formal relationships between members (who reports to whom),
• the functional role for each person, and
• the interfaces (interaction and dependencies) between the unit and other units or stakeholders.

10.32.3 Elements

.1 Types of Organizational Models

There are three pre-eminent organizational models:
• Functionally-oriented: group staff together based on shared skills or areas of expertise and generally encourage a standardization of work or processes within the organization. Functional organizations are beneficial because they seem to facilitate cost management and reduce duplication of work, but are prone to develop communication and cross-functional

coordination problems (known informally as “silos”).

Figure 10.32.1: Functionally-oriented Organizational Model

**

Staff Function Incumbent Name
Staff Function Incumbent Name

Staff Function Incumbent Name

• Market-oriented: may be intended to serve particular customer groups, geographical areas, projects, or processes rather than grouping employees by common skills or expertise. Market-oriented structures permit the organization to meet the needs of its customers, but are prone to developing inconsistencies in how work is performed. Some may discover they are performing duplicate work in multiple areas.

Figure 10.32.2: Market-oriented Organizational Model

**

• The Matrix Model: has separate managers for each functional area and for each product, service, or customer group. Employees report to a line manager, who is responsible for the performance of a type of work and for identifying opportunities for efficiency in the work, and to a market (or product, service, or project) manager, who is responsible for managing the product or service across multiple functional areas. A challenge of the matrix model is that each employee has two managers (who are focused on different goals) and accountability is difficult to maintain.

Figure 10.32.3: Matrix Organizational Model

.2 Roles
An organizational unit includes a number of defined roles. Each role requires a certain set of skills and knowledge, has specific responsibilities, performs certain kinds of work, and has defined relationships with other roles in the organization.

.3 Interfaces

Each organizational unit has interfaces with other organizational units. Interfaces (interactions) may be in the form of communication with people in other roles and work packages that the organizational unit receives from or delivers to other units.

.4 Organizational Charts

The fundamental diagram used in organizational modelling is the organizational chart (org chart).
There is no recognized standard for org charts, although there are some conventions that most org charts follow:
• A box depicts:
• Organizational Unit: people, teams, departments, or divisions. An org

chart may mix organizational units and show a mix of people, teams, and higher-level divisions.
• Roles and People: the roles within an organization and the people assigned to each role.
• A line depicts:
• Lines of Reporting: accountability and control between units. A solid line typically denotes direct authority, while a dotted line indicates information transfer or situational authority. Lines of reporting depict the relationship between a manager and an organizational unit

.5 Influencers

Organizational charts are the primary tool for beginning organizational modelling. Organizational charts represent the formal structure of the organization. Business analysts also identify informal lines of authority, influence, and communication which may not directly align with the formal organizational chart.
Determining all of the influencers is important in planning communication and making provisions for user acceptance. One method of identifying influencers may be to ask stakeholders, “Who can I ask…” and note the answers. An influencer may be a person everyone goes to for information, direction, and advice. Another method is to note who speaks for the group in meetings.

10.32.4 Usage Considerations

.1 Strengths

• Organizational models are common in most organizations.
• Including an organizational model in business analysis information allows team members to provide support. Future projects may benefit from knowing who was involved in this project and what their role entailed.

.2 Limitations

• Organizational models are sometimes out of date.
• Informal lines of authority, influence, and communication not reflected in the org chart are more difficult to identify and may conflict with the organizational chart.

10.33 Prioritization

10.33.1 Purpose

Prioritization provides a framework for business analysts to facilitate stakeholder decisions and to understand the relative importance of business analysis information.

10.33.2 Description

Prioritization is a process used to determine the relative importance of business analysis information. The importance may be based on value, risk, difficulty of implementation, or other criteria. These priorities are used to determine which business analysis information should be targeted for further analysis, which requirements should be implemented first, or how much time or detail should be allocated to the requirements.
There are many approaches to prioritization. For the purpose of this technique, prioritization is classified into one of four approaches:
• Grouping,
• Ranking,
• Time boxing/Budgeting, and
• Negotiation.
When choosing a prioritization approach, business analysts consider the audience, their needs, and their opinions on the value a requirement or business analysis information brings to a stakeholder’s respective area.
Business analysts revisit priorities and utilize different approaches when changes occur in the business environment, to the stakeholders, and to the business analysis information.

Figure 10.33.1: Approaches to Prioritization

**

10.33.3 Elements

.1 Grouping
Grouping consists of classifying business analysis information according to predefined categories such as high, medium, or low priority. Many requirements management tools support listing the priority category as an attribute of a requirement.

.2 Ranking

Ranking consists of ordering business analysis information from most to least important. Some adaptive approaches involve the explicit sequencing of requirements in an ordered list (a product backlog).

.3 Time Boxing/Budgeting

Time boxing or budgeting prioritizes business analysis information based on the allocation of a fixed resource. It is frequently used when the solution approach has been determined. Time boxing is used to prioritize requirements based on the amount of work that the project team is capable of delivering in a set period of time. Budgeting is used when the project team has been allocated a fixed amount of money. This approach is most often used when a fixed deadline must be met or for solutions that are enhanced on a regular and frequent basis.

.4 Negotiation

The negotiation approach involves establishing a consensus among stakeholders as to which requirements will be prioritized.

10.33.4 Usage Considerations

.1 Strengths

• Facilitates consensus building and trade-offs and ensures that solution value is realized and initiative timelines are met.

.2 Limitations

• Some stakeholders may attempt to avoid difficult choices and fail to recognize the necessity for making trade-offs.
• The solution team may intentionally or unintentionally try to influence the result of the prioritization process by overestimating the difficulty or complexity of implementing certain requirements.
• Metrics and key performance indicators are often not available when prioritizing business analysis information; therefore, a stakeholder’s perspective of the importance may be subjective.

10.34 Process Analysis

10.34.1 Purpose

Process analysis assesses a process for its efficiency and effectiveness, as well as its ability to identify opportunities for change.

10.34.2 Description

Process analysis is used for various purposes including:
• recommending a more efficient or effective process,
• determining the gaps between the current and future state of a process,
• understanding factors to be included in a contract negotiation,
• understanding how data and technology are used in a process, and
• analyzing the impact of a pending change to a process.
A number of frameworks and methodologies exist that focus on process analysis and improvement methods, such as Six Sigma and Lean. Methods for process improvement include value stream mapping, statistical analysis and control, process simulation, benchmarking, and process frameworks.
Common changes made to processes in order to improve them include:
• reducing the time required to complete a task or tasks in the process,
• modifying interfaces or hand-offs between roles and organizational units to remove errors, including the reduction or elimination of bottlenecks,
• automating steps that are more routine or predictable, and
• increasing the degree of automation in the decision making required by the process.
When analyzing a process, business analysts look for:
• how the process adds or creates value for the organization,
• how the process aligns to organizational goals and strategy,
• to what degree the process is and needs to be efficient, effective, repeated, measured, controlled, used, and transparent, and
• how the requirements for a solution cover the future state process and its external stakeholders, including customers.

10.34.3 Elements

.1 Identify Gaps and Areas to Improve

Identifying gaps and areas to improve helps to identify what areas are in scope for analysis. Industry-specific models and process frameworks may be helpful in this

regard. When identifying gaps and areas to improve, business analysts:
• identify gaps between the current and desired future state,
• identify what gaps and areas are value and non-value added,
• understand pain points and the challenges of the process from multiple points of view,
• understand opportunities to improve the process from multiple points of view,
• align the gaps and areas to improve with the strategic direction of the organization, and
• understand the relationship of the gaps and areas to improve to changes in the enterprise.

.2 Identify Root Cause

Identifying the root cause of the gaps and improvement areas ensures that the solution addresses the right gap and area.
When identifying the root cause, business analysts understand:
• there may be multiple root causes,
• the inputs leading to the gap or area of improvement,
• who the right people are to identify the root cause, and
• the current measurements and motivators in place for those owning or performing the process.

.3 Generate and Evaluate Options

Generating options and alternative solutions to solve for the gap or area of improvement helps the team evaluate and see different points of view for improving the process. It is important for stakeholders to be involved in identifying the impact, feasibility, and value of the proposed solution relative to alternative options.

.4 Common Methods SIPOC

SIPOC is a process analysis method that originates in the Six Sigma methodology and has been more commonly adopted as a process analysis method outside of Six Sigma.
It is used to look at the process and understand the Suppliers, Inputs, Process, Outputs and Customers of the process being analyzed.
A SIPOC provides a simple overview of the process. It also shows the complexity of who and what is involved in creating inputs to the process and shows who receives outputs from the process. A SIPOC is a powerful tool used to create

dialogue about problems, opportunities, gaps, root cause, and options and alternatives during process analysis.

Figure 10.34.1: SIPOC Model

Value Stream Mapping (VSM)
Value stream mapping (VSM) is a process analysis method used in Lean methodologies.
Value stream mapping involves the diagramming and monitoring of inputs and application points for processing those inputs, starting from the front-end of the supply chain. At each stage, the value stream map gauges the wait time for the inputs and the actual processing times at the application points (also known as conversion times). At the end of the supply chain, the value stream map depicts the logistics or distribution process to the customer.
The value stream map provides a one-page picture of all the steps involved in the end-to-end process, including both value-adding (the value stream) and non- value-adding (waste) elements.

Figure 10.34.2: Value Stream Map

Activity/Tasks | | Data |

10.34.4 Usage Considerations

.1 Strengths
• Ensures solutions address the right issues, minimizing waste.
• Many different techniques and methodologies can be used and provide teams with great flexibility in approach.

.2 Limitations

• Can be time-consuming.
• There are many techniques and methodologies in process analysis. It can be challenging to decipher which to use and how rigorously to follow them, given the scope and purpose.
• May prove ineffective at process improvement in knowledge or decision- intensive processes.

10.35 Process Modelling

10.35.1 Purpose

Process modelling is a standardized graphical model used to show how work is carried out and is a foundation for process analysis.

10.35.2 Description

Process models describe the sequential flow of work or activities. A business process model describes the sequential flow of work across defined tasks and activities through an enterprise or part of an enterprise. A system process model defines the sequential flow of control among programs or units within a computer system. A program process flow shows the sequential execution of program statements within a software program. A process model can also be used in documenting operational procedures.
A process model can be constructed on multiple levels, each of which can be aligned to different stakeholder points of view. These levels exist to progressively decompose a complex process into component processes, with each level providing increasing detail and precision. At a high (enterprise or context) level, the model provides a general understanding of a process and its relationship to other processes. At lower (operational) levels, it can define more granular activities and identify all outcomes, including exceptions and alternative paths. At the lowest (system) level, the model can be used as a basis for simulation or execution.
Process models can be used to:
• describe the context of the solution or part of the solution,
• describe what actually happens, or is desired to happen, during a process,
• provide an understandable description of a sequence of activities to an external observer,
• provide a visual to accompany a text description, and
• provide a basis for process analysis.
The business analyst can use a process model to define the current state of a process (also known as an as-is model) or a potential future state (also known as a to-be model). A model of the current state can provide understanding and agreement as to what happens now. A model of the future state can provide alignment with what is desired to happen in the future.
Process models generally include:
• the participants in the process,
• the business event that triggers the process,
• the steps or activities of the process (both manual and automated),
• the paths (flows) and decision points that logically link those activities, and

• the results of the process.
The most basic process model includes: a trigger event, a sequence of activities, and a result.
A more comprehensive process model can include other elements, such as data/ materials, inputs and outputs, and call-out descriptions that supplement the graphical representation.

10.35.3 Elements

.1 Types of Process Models and Notations

Many different notations are used in process modelling. The most commonly used notations include the following:
• Flowcharts and Value Stream Mapping (VSM): used in the business domain.
• Data Flow diagrams and Unified Modelling Language™ (UML®) diagrams: used in the information technology domain.
• Business Process Model and Notation (BPMN): used across both business and information technology domains; is increasingly adopted as an industry standard.
• Integrated DEFinition (IDEF) notation and Input, Guide, Output, Enabler (IGOE) diagrams: used for establishing scope.
• SIPOC and Value Stream Analysis: used for process modelling. Process models typically contain some or all of the following key elements:
• Activity: an individual step or piece of work that forms part of the business process. It may be a single task or may be further decomposed into a sub- process (with its own activities, flow, and other process elements).
• Event: a zero-time occurrence which initiates, interrupts, or terminates an activity or task within a process or the process itself. It may be a message received, the passage of time, or the occurrence of a condition as defined in the business rules.
• Directional Flow: a path that indicates the logical sequence of the workflow. In general, diagrams are drawn to show the passage of time in a consistent fashion (typically in the direction that text would be read).
• Decision Point: a point in the process where the flow of work splits into two or more flows (paths), which may be mutually exclusive alternatives or parallels. A decision can also be used to locate rules where separate flows merge together.
• Link: a connection to other process maps.
• Role: a type of person or group involved in the process. Its definitions typically match those in the organizational model.

Flowchart

Flowcharts are used commonly with non-technical audiences and are good for gaining both alignment with what the process is and context for a solution. A flowchart can be simple, displaying just the sequence of activities, or it can be more comprehensive, using swimlanes. A swimlane is a partitioned area (horizontal or vertical) that segregates those activities in the process that are carried out by a particular role.

Figure 10.35.1: Flowchart

Business Process Model and Notation (BPMN)
Business Process Model and Notation (BPMN) provides an industry-standard language for modelling business processes in a form that is accessible by both business users and technical developers. BPMN is designed to cover many types of modelling, including both internal (private) processes and collaborative (public) processes. It can be the input to process automation technologies.
A key feature of BPMN is its ability to distinguish the activities of different participants in a process with pools and swimlanes. When the flow of work crosses the boundary of a swimlane, responsibility for the work then passes to

another role within the organization. Swimlanes are part of a pool. A pool is a self-regulating (free-standing) business entity, typically an organization or a system. A pool may include a number of swimlanes, each of which represents a role. Commonly, a process includes one pool for the customer and a second pool for the organization under study, although it is possible for a process to include any number of pools.

Figure 10.35.2: Business Process Model and Notation

Activity Diagram
The activity diagram is one of the use case realization diagrams defined in the Unified Modelling Language™ (UML®). Originally designed to elaborate on a single use case, the activity diagram has been adopted for more general process
modelling purposes, including business process modelling. While similar in appearance to a flowchart, the activity diagram typically employs swimlanes to show responsibilities, synchronization bars to show parallel processing, and multiple exit decision points.

Figure 10.35.3: Activity Diagram

10.35.4 Usage Considerations

.1 Strengths
• Appeals to the basic human understanding of sequential activities.
• Most stakeholders are comfortable with the concepts and basic elements of a process model.
• The use of levels can accommodate the different perspectives of various stakeholder groups.
• Effective at showing how to handle a large number of scenarios and parallel branches.
• Can help identify any stakeholder groups that may have otherwise been overlooked.
• Facilitates the identification of potential improvements by highlighting “pain points” in the process structure (i.e. process visualization).

• Likely to have value in its own right. They provide documentation for compliance purposes and can be used by business stakeholders for training and coordination of activities.
• Can be used as a baseline for continuous improvement.
• Ensures labelling consistency across artifacts.
• Provides transparency and clarity to process owners and participants on activity responsibilities, sequence and hand-overs.

.2 Limitations

• To many people in IT, a formal process model tends to reflect an older and more document-heavy approach to software development. Therefore, project time is not allocated to developing a process model, especially of the current state or problem domain.
• Can become extremely complex and unwieldy if not structured carefully. This is especially true if business rules and decisions are not managed separately from the process.
• Complex processes can involve many activities and roles; this can make them almost impossible for a single individual to understand and ‘sign off’.
• Problems in a process cannot always be identified by looking at a high-level model. A more detailed model with reference to metadata (such as path frequency, cost, and time factors) is usually required. It is often necessary to engage with stakeholders directly to find the operational problems they have encountered while working with a process.
• In a highly dynamic environment where things change quickly, process models can become obsolete.
• May prove difficult to maintain if the process model only serves as documentation, as stakeholders may alter the process to meet their needs without updating the model.

10.36 Prototyping

10.36.1 Purpose

Prototyping is used to elicit and validate stakeholder needs through an iterative process that creates a model or design of requirements. It is also used to optimize user experience, to evaluate design options, and as a basis for development of the final business solution.

10.36.2 Description

Prototyping is a proven method for product design. It works by providing an early model of the final result, known as a prototype. Prototyping is used to identify both missing or improperly specified requirements and unsubstantiated

Prototyping Techniques

assumptions by demonstrating what the product looks like and how it acts in the early stages of design.
Prototypes can be non-working models, working representations, or digital depictions of a solution or a proposed product. They can be used to mock up websites, serve as a partially working construct of the product, or describe processes through a series of diagrams (such as workflow). Business rules and data prototypes can be used to discover desired process flow and business rules. Data prototyping can be used for data cleansing and transformation.

10.36.3 Elements

.1 Prototyping Approach

There are two common approaches to prototyping:
• Throw-away: prototypes are generated with simple tools (such as paper and pencil, a whiteboard, or software) to serve the goal of uncovering and clarifying requirements. The prototype may be updated or evolve during the course of discussion and development, but does not become workable code or get maintained as a deliverable once the final system or process is implemented. This method is helpful for identifying functionality or processes that are not easily elicited by other techniques, have conflicting points of view, or are difficult to understand. These prototypes can be an inexpensive tool to uncover or confirm requirements that go beyond an interface including requirements related to processes, data, and business rules.
• Evolutionary or Functional: prototypes are created to extend initial requirements into a functioning solution as requirements are further defined through stakeholder use. This approach produces a working solution and usually requires a specialized prototyping tool or language. These prototypes may be used in the final solution. If specialized software is used, business processes, rules, and data can be simulated to evaluate the impact of changes and validate desired outcomes.

.2 Prototyping Examples

There are many forms of prototyping in use today.
Each of the following can be considered a form of prototyping:
• Proof of Principle or Proof of Concept: is a model created to validate the design of a system without modelling the appearance, materials used in the creation of work, or processes/workflows ultimately used by the stakeholders.
• Form Study Prototype: is used to explore the basic size, look, and feel of a product that will be manufactured, without creating actual functionality. It is used to assess ergonomic and visual factors using a sculptural representation of the product made from inexpensive materials. This type of prototype may also be used to model a workflow or navigation at a high

Techniques Prototyping

level in order to identify gaps or inconsistencies in the possible solution of the properties (for example, appearance, configuration).
• Usability Prototype: is a product model created to test how the end user interacts with the system without including any of the properties (for example, appearance, configuration).
• Visual Prototype: is a product model created to test the visual aspects of the solution without modelling the complete functionality.
• Functional Prototype: is a model created to test software functionality, qualities of the system for the user (for example, appearance), and workflow. It is also referred to as a working model and is used both to simulate business processes and business rules and to evaluate software function calls.

.3 Prototyping Methods

The following is a list of commonly used methods for prototyping:
• Storyboarding: is used to visually and textually detail the sequence of activities by summing up different user interactions with the solution or enterprise.
• Paper Prototyping: uses paper and pencil to draft an interface or process.
• Workflow Modelling: depicts a sequence of operations that are performed and usually focuses solely on the human aspect.
• Simulation: is used to demonstrate solutions or components of a solution. It may test various processes, scenarios, business rules, data, and inputs.

10.36.4 Usage Considerations

.1 Strengths

• Provides a visual representation for the future state.
• Allows for stakeholders to provide input and feedback early in the design process.
• When using throw-away or paper prototyping methods, users may feel more comfortable being critical of the mock-up because it is not polished and release-ready.
• A narrow yet deep vertical prototype can be used for technical feasibility studies, proof of concept efforts, or to uncover technology and process gaps.

.2 Limitations

• If the system or process is highly complex, the prototyping process may become bogged down with discussion of ‘how’ rather than ‘what’, which can make the process take considerable time, effort, and facilitation skill.
• Underlying technology may need to be understood or assumed in order to initiate prototyping.

• If the prototype is deeply elaborate and detailed, stakeholders may develop unrealistic expectations for the final solution. These can range from assumed completion dates to higher expectations of performance, reliability, and usability.
• Stakeholders may focus on the design specifications of the solution rather than the requirements that any solution must address. This can, in turn, constrain the solution design. Developers may believe that they must provide a user interface that precisely matches the prototype, even if more elegant technology and interface approaches exist.

10.37 Reviews

10.37.1 Purpose

Reviews are used to evaluate the content of a work product.

10.37.2 Description

Different types of reviews are conducted for business analysis work products.
Each is tailored to the needs of the organization and business analyst, and uses these dimensions:
• Objectives: defining the purpose of the review.
• Techniques: identifying either a formal or informal way to perform the review.
• Participants: identifying who should take part in the review activity.
Each review is focused on a work product, not the skills or actions of the participants. The work product may be a package of several deliverables, a single deliverable, a portion of a deliverable, or work in process. For a completed work product, the objective of the review is usually to remove defects or inform the reviewers about the content. For work in process, the review may be conducted to resolve an issue or question.
Each review includes the business analyst as a participant. Reviewers may be peers, especially for work in process, or stakeholders, who validate that the work product is complete and correct. The review steps depend on the technique used.
Reviews can include:
• an overview of the work product and review objectives,
• checklists and reference materials that can be used by reviewers,
• reviewing the work product and documenting the findings, and
• verifying any rework.
Using feedback from reviewers, the business analyst updates the work product.

10.37.3 Elements

.1 Objectives

Objectives are clearly communicated to all participants prior to the review. Objectives may include one or more goals, for example:
• to remove defects,
• to ensure conformance to specifications or standards,
• to ensure the work product is complete and correct,
• to establish consensus on an approach or solution,
• to answer a question, resolve an issue, or explore alternatives,
• to educate reviewers about the work product, and
• to measure work product quality.

.2 Techniques

Reviews can be formal or informal. The techniques used during a review are selected to support the objectives of the review.
The following techniques are commonly used by business analysts when conducting reviews:
• Inspection: a formal technique that includes an overview of the work product, individual review, logging the defects, team consolidation of defects, and follow-up to ensure changes were made. The focus is to remove defects and create a high quality work product. While usually performed by peers, it can also be used for stakeholder reviews.
• Formal Walkthrough (also known as Team Review): a formal technique that uses the individual review and team consolidation activities often seen in inspection. Walkthroughs are used for peer reviews and for stakeholder reviews.
• Single Issue Review (also known as Technical Review): a formal technique focused on either one issue or a standard in which reviewers perform a careful examination of the work product prior to a joint review session held to resolve the matter in focus.
• Informal Walkthrough: an informal technique in which the business analyst runs through the work product in its draft state and solicits feedback. Reviewers may do minimal preparation before the joint review session.
• Desk Check: an informal technique in which a reviewer who has not been involved in the creation of the work product provides verbal or written feedback.
• Pass Around: an informal technique in which multiple reviewers provide verbal or written feedback. The work product may be reviewed in a common copy of the work product or passed from one person to the next.

• Ad hoc: an informal technique in which the business analyst seeks informal review or assistance from a peer.

.3 Participants

Participant roles involved in any particular review depend on the objectives of the review, the selected technique, and any organizational standards that may be in place.
In some situations, a supervisor or manager may be one of the reviewers because of their expertise. In these situations, the moderator is careful to avoid adversely affecting the level of candour of other participants or inappropriately affecting decisions of the team.

Table 10.37.1: Review Roles

10.37.4 Usage Considerations

.1 Strengths
• Can help identify defects early in the work product life cycle, eliminating the need for expensive removal of defects discovered later in the life cycle.
• All parties involved in a review become engaged with the final outcome; they have a vested interest in a quality result.

• Desk checks and pass around reviews can be performed by a reviewer at a convenient time, rather than interrupting work in progress to attend a meeting.

.2 Limitations

• Rigorous team reviews take time and effort. Thus, only the most critical work products might be reviewed using inspection or formal walkthrough techniques.
• Informal reviews by one or two reviewers are practical in terms of the effort required, but they provide less assurance of removing all significant defects than using a larger team and more formal process.
• For desk checks and pass around reviews it may be difficult for the author to validate that an independent review was done by each participant.
• If review comments are shared and discussed via e-mail there may be many messages to process, which makes it difficult for the author to resolve disagreements or differences in suggested changes.

10.38 Risk Analysis and Management

10.38.1 Purpose

Risk analysis and management identifies areas of uncertainty that could negatively affect value, analyzes and evaluates those uncertainties, and develops and manages ways of dealing with the risks.

10.38.2 Description

Failure to identify and manage risks may negatively affect the value of the solution. Risk analysis and management involves identifying, analyzing, and evaluating risks. Where sufficient controls are not already in place, business analysts develop plans for avoiding, reducing, or modifying the risks, and when necessary, implementing these plans.
Risk management is an ongoing activity. Continuous consultation and communication with stakeholders helps to both identify new risks and to monitor identified risks.

10.38.3 Elements

.1 Risk Identification

Risks are discovered and identified through a combination of expert judgment, stakeholder input, experimentation, past experiences, and historical analysis of similar initiatives and situations. The goal is to identify a comprehensive set of relevant risks and to minimize the unknowns. Risk identification is an ongoing activity.

Risk Analysis and Management Techniques

A risk event could be one occurrence, several occurrences, or even a non- occurrence. A risk condition could be one condition or a combination of conditions. One event or condition may have several consequences, and one consequence may be caused by several different events or conditions.
Each risk can be described in a risk register that supports the analysis of those risks and plans for addressing them.

Figure 10.38.1: Example of a Risk Register

|

# |

Risk Event or Condition |

Consequence |

Probability |

Impact |

Risk Level | Risk Modification Plan |

Risk Owner | Residual Risk | | | | —- | —- | —- | —- | —- | —- | —- | —- | —- | —- | —- | | | | | | | | | | Probability | Impact | Risk Level | | 1 | If the union does not agree with changes to job descriptions | then planned staff changes will not be able to occur | Medium | Medium | Medium | Begin consultations with the union no later than next month | Marta | Low | Low | Low | | 2 | If subject matter experts are not available for requirements elicitation | then scope and quality will be reduced, and the delivery date will be pushed back | Medium | High | High | Develop a plan for when the SME’s are required, hold on-site workshops and obtain agreement from the sponsor about their participation | Deepak | Low | Medium | Low | | 3 | If an insufficient number of customers reply to our survey | then we will not have a representative sample of customer requirements | Medium | High | High | Contract with a firm that specializes in survey management to develop and run the survey | François | Low | Medium | Low | | 4 | If the organizational structure does not adjust to the new business processes | then the enterprise will not be able to achieve the planned efficiencies and the business need will not be met | High | High | High | The business sponsor must approve the organizational changes prior to deployment, and the changes must occur prior to deployment | Jiahui | Medium | Low | Medium |

.2 Analysis
Analysis of a risk involves understanding the risk, and estimating the level of a risk. Sometimes controls may already be in place to deal with some risks, and these should be taken into account when analyzing the risk.

The likelihood of occurrence could be expressed either as a probability on a numerical scale or with values such as Low, Medium, and High.
The consequences of a risk are described in terms of their impact on the potential value. The impact of any risk can be described in terms of cost, duration, solution scope, solution quality, or any other factor agreed to by the stakeholders such as reputation, compliance, or social responsibility.

Table 10.38.1: Example of a Risk Impact Scale

While an enterprise may have a standard or baseline risk impact scale, the categories like cost, effort, and reputation, and the thresholds may be adjusted to consider the potential value and the level of risk that is acceptable. Typically, three to five broad categories of level are used to describe how to interpret the potential impact.
The level of a given risk may be expressed as a function of the probability of occurrence and the impact. In many cases, it is a simple multiplication of probability and impact. The risks are prioritized relative to each other according to their level. Risks which could occur in the near term may be given a higher priority than risks which are expected to occur later. Risks in some categories such as reputation or compliance may be given higher priority than others.

.3 Evaluation

The risk analysis results are compared with the potential value of the change or of the solution to determine if the level of risk is acceptable or not. An overall risk level may be determined by adding up all the individual risk levels.

.4 Treatment

Some risks may be acceptable, but for other risks it may be necessary to take measures to reduce the risk.
One or more approaches for dealing with a risk may be considered, and any combination of approaches could be used to address a risk:
• Avoid: either the source of the risk is removed, or plans are adjusted to ensure that the risk does not occur.
• Transfer: the liability for dealing with the risk is moved to, or shared with, a third party.
• Mitigate: reduce the probability of the risk occurring or the possible negative consequences if the risk does occur.
• Accept: decide not to do anything about the risk. If the risk does occur, a workaround will be developed at that time.
• Increase: decide to take on more risk to pursue an opportunity.
Once the approach for dealing with a specific risk is selected, a risk response plan is developed and assigned to a risk owner with responsibility and authority for that risk. In the case of risk avoidance, the risk owner takes steps to ensure that the probability or the impact of the risk is reduced to nil. For those risks which cannot be reduced to nil, the risk owner is responsible for monitoring the risk, and for implementing a risk mitigation plan.
The risk is re-analyzed to determine the residual risk which is the new probability and new impact as a result of the measures taken to modify the risk. There could be a cost-benefit analysis done to determine if the cost and effort of the measures reduces the level of risk enough to make it worthwhile. The risks may be re- evaluated in terms of the residual risk.
Stakeholders should be informed of the plans for modifying the risks.

10.38.4 Usage Considerations

.1 Strengths

• Can be applied to strategic risks which affect long-term value of the enterprise, tactical risks which affect the value of a change, and operational risks which affect the value of a solution once the change is made.
• An organization typically faces similar challenges on many of its initiatives. The successful risk responses on one initiative can be useful lessons learned for other initiatives.
• The risk level of a change or of a solution could vary over time. Ongoing risk management helps to recognize that variation, and to re-evaluate the risks and the suitability of the planned responses.

.2 Limitations

• The number of possible risks to most initiatives can easily become unmanageably large. It may only be possible to manage a subset of potential risks.
• There is the possibility that significant risks are not identified.

10.39 Roles and Permissions Matrix

10.39.1 Purpose

A roles and permissions matrix is used to ensure coverage of activities by denoting responsibility, to identify roles, to discover missing roles, and to communicate results of a planned change.

10.39.2 Description

Role and permission allocation involves identifying roles, associating these with solution activities, and then denoting authorities who can perform these activities. A role is a label for a group of individuals who share common functions. Each function is portrayed as one or more solution activities. A single activity can be associated with one or more roles by designating authorities. Each individual that is assigned this authority can perform the associated activity.
The following is an example of a roles and permissions matrix for a software system.

Figure 10.39.1: Roles and Permissions Matrix

**

10.39.3 Elements

.1 Identifying Roles
To identify roles for either internal or external stakeholders, business analysts:
• review any organizational models, job descriptions, procedure manuals, and system user guides, and
• meet with stakeholders to uncover additional roles.
Through this review and discussion, the business analyst considers both that individuals with the same job title may have different roles and that individuals with different job titles may have the same roles.
When identifying roles, business analysts look for common functions that are performed by individuals with similar needs.

.2 Identifying Activities

Business analysts frequently use functional decomposition to break down each function into sub-parts, process modelling to better understand the workflow and division of work among users, and use cases to represent tasks. By performing these techniques, the business analyst can ensure that all functions are accounted for and their activities are identified among various use case scenarios.
There may be different levels of abstraction for roles and permission matrices based on the business analysis perspective. Initiative level roles and responsibilities may be identified in a RACI (Responsible, Accountable, Consulted, Informed) matrix. Specific information technology system roles and responsibilities may be identified in a CRUD (Create, Read, Update, and Delete) matrix.

.3 Identifying Authorities

Authorities are actions that identified roles are permitted to perform. For each activity, the business analyst identifies the authorities for each role. When identifying authorities, business analysts consider the level of security needed and how the work flows through the process. Business analysts collaborate with stakeholders to validate identified authorities.

.4 Refinements Delegations

The business analyst may also identify which authorities can be delegated by one individual to another on a short-term or permanent basis.

Inheritances

Stakeholders may request that when an individual is assigned an authority at an organizational hierarchy level that this assignment pertain to only that user’s organizational level and any subsidiary organizational unit levels.

10.39.4 Usage Considerations

.1 Strengths

• Provides procedural checks and balances, as well as data security, by restricting individuals from performing certain actions.
• Promotes improved review of transaction history, in that audit logs can capture details about any assigned authorities at the time.
• Provides documented roles and responsibilities for activities.

.2 Limitations

• Need to recognize the required level of detail for a specific initiative or activity; too much detail can be time-consuming and not provide value, too little detail can exclude necessary roles or responsibilities.

10.40 Root Cause Analysis

10.40.1 Purpose

Root cause analysis is used to identify and evaluate the underlying causes of a problem.

10.40.2 Description

Root cause analysis is a systematic examination of a problem or situation that focuses on the problem’s origin as the proper point of correction rather than dealing only with its effects. It applies an iterative analysis approach in order to take into account that there might be more than one root cause contributing to the effects. Root cause analysis looks at the main types of causes such as people (human error, lack of training), physical (equipment failure, poor facility), or organizational (faulty process design, poor structure).
Root cause analysis helps organize the information in a framework, which allows for deeper analysis if needed. Root cause analysis can be used for:
• Reactive Analysis: identifying the root cause(s) of an occurring problem for corrective action, or
• Proactive Analysis: identifying potential problem areas for preventive action.
Root cause analysis uses four main activities:
• Problem Statement Definition: describes the issue to be addressed.
• Data Collection: gathers information about the nature, magnitude, location, and timing of the effect.
• Cause Identification: investigates the patterns of effects to discover the specific actions that contribute to the problem.

• Action Identification: defines the corrective action that will prevent or minimize recurrence.

10.40.3 Elements

.1 The Fishbone Diagram

A fishbone diagram (also known as an Ishikawa or cause-and-effect diagram) is used to identify and organize the possible causes of a problem. This tool helps to focus on the cause of the problem versus the solution and organizes ideas for further analysis. The diagram serves as a map that depicts possible cause-and- effect relationships.
Steps to develop a fishbone diagram include:
Step 1. Capturing the issue or problem under discussion in a box at the top of the diagram.
Step 2. Drawing a line from the box across the paper or whiteboard (forming the spine of the fishbone).
Step 3. Drawing diagonal lines from the spine to represent categories of potential causes of the problem. The categories may include people, processes, tools, and policies.
Step 4. Drawing smaller lines to represent deeper causes.
Step 5. Brainstorming categories and potential causes of the problem and capturing them under the appropriate category.
Step 6. Analyzing the results. Remember that the group has identified only potential causes of the problem. Further analysis is needed to validate the actual cause, ideally with data.
Step 7. Brainstorming potential solutions once the actual cause has been identified.

Figure 10.40.1: Fishbone Diagram

**

.2 The Five Whys
The five whys is a question asking process to explore the nature and cause of a problem. The five whys approach repeatedly asks questions in an attempt to get to the root cause of the problem. This is one of the simplest facilitation tools to use when problems have a human interaction component.
To use this technique:
Step 1. Write the problem on a flip chart or whiteboard.
Step 2. Ask “Why do you think this problem occurs?” and capture the idea below the problem.
Step 3. Ask “Why?” again and capture that idea below the first idea.
Continue with step 3 until you are convinced the actual root cause has been identified. This may take more or less than five questions—the technique is called the five whys because it often takes that many to reach the root cause, not because the question must be asked five times.
The five whys can be used alone or as part of the fishbone diagram technique. Once all ideas are captured in the diagram, use the five whys approach to drill down to the root causes.

10.40.4 Usage Considerations

.1 Strengths

• Helps to maintain an objective perspective when performing cause-and-effect analysis.
• Enables stakeholders to specify an effective solution at the appropriate points for corrective action.

.2 Limitations

• Works best when the business analyst has formal training to ensure the root causes, not just symptoms of the problem, are identified.
• May be difficult with complex problems; the potential exists to lead to a false trail and/or dead–end conclusion.

10.41 Scope Modelling

10.41.1 Purpose

Scope models define the nature of one or more limits or boundaries and place elements inside or outside those boundaries.

10.41.2 Description

Scope models are commonly used to describe the boundaries of control, change, a solution, or a need. They may also be used to delimit any simple boundary (as distinct from horizons, emergent properties, and recursive systems).
These models may show elements that include:
• In-scope: the model identifies a boundary as seen from inside, as well as the elements contained by that boundary (for example, functional decomposition).
• Out-of-scope: the model identifies a boundary as seen from outside, as well as the elements that are not contained by that boundary (for example, context diagram).
• Both: the model identifies a boundary as seen from both sides, as well as elements on both sides of the boundary (for example, venn diagram or use case model).
Scope models provide the basis for understanding the boundaries of:
• Scope of Control: what is being analyzed, roles and responsibilities, and what is internal and external to the organization.
• Scope of Need: stakeholder needs, value to be delivered, functional areas, and organizational units to be explored.
• Scope of Solution: requirements met, value delivered, and impact of change.
• Scope of Change: actions to be taken, stakeholders affected or involved, and events to cause or prevent.
Scope models are typically represented as a combination of diagrams, matrices, and textual explanations. If the scope is implemented in phases or iterations, the scope model should be described per each phase or iteration.

10.41.3 Elements

.1 Objectives

Scope models are typically used to clarify the:
• span of control,
• relevance of elements, and
• where effort will be applied.

Depending on the action or stakeholder needs the model supports, a business analyst determines the types of models to be used and selects boundaries and elements.

.2 Scope of Change and Context

Typically, business analysts are concerned with elements that will be altered as part of a change, as well as external elements that are relevant to the change. For elements inside the scope of change, the business analyst is involved in establishing the ways those elements are modified. For elements outside the scope of change but relevant to the change, the business analyst is involved in establishing the interactions between the change, the current and proposed solutions, and the context.
The business analyst often determines:
• business processes to be defined or modified,
• business functions to be added, changed, optimized, or re-assigned,
• new capabilities to be built or existing capabilities to be changed,
• external and internal events to be responded to,
• use cases and situations to be supported,
• technologies to be changed or replaced,
• informational assets to be acquired, produced, or processed,
• stakeholders and organizational roles impacted by the change,
• external and internal agents and entities impacted by the change,
• organizations and organizational units (departments, teams, groups) impacted by the change, and
• systems, components, tools, and physical assets required for the change or impacted by the change.

.3 Level of Detail

The purpose of analysis defines the appropriate level of abstraction at which scope elements are described. A proper level of detail provides a meaningful reduction of uncertainty while preventing ‘analysis paralysis’ at a scope definition stage. The elements of the final scope model can be described by enumerating them, by referring to a specific level of their decomposition hierarchy, or by grouping them into logically bound sets. For example, a subject of change can be defined as a list of specific business processes, as a high-level business process encompassing all of them, or as a generic business function. Similarly, stakeholders included in the scope can be defined by enumerating specific titles or by referring to their common organizational role.

.4 Relationships

Exploring relationships between potential scope elements helps to ensure completeness and integrity of the scope model by identifying their dependencies or by discovering other elements involved in or impacted by the change.
Various diagramming techniques are available for exploring relationships of specific types, including:
• Parent-Child or Composition-Subset: relates elements of the same type by way of hierarchical decomposition. Relationships of this type appear as an organization chart, in a class or entity-relationship diagram, as sub- processes in a business process model, or as composite states on a state diagram.
• Function-Responsibility: relates a function with the agent (stakeholder, organizational unit, or solution component) that is responsible for its execution. Relationships of this type appear on business process models and on collaboration, sequence, and use case diagrams.
• Supplier-Consumer: relates elements by way of the transmission of information or materials between them. Elements can be processes, systems, solution components, and organizational units, for both internal and external entities. Relationships of this type occur in data flow diagrams, business process models, and in collaboration, sequence, and robustness diagrams.
• Cause-Effect: relates elements by logical contingency in order to identify chains of associated elements that are involved in or impacted by the change. Relationships of this type appear in fishbone (Ishikawa) diagrams and other cause-effect diagrams.
• Emergent: in most complex systems, several elements can interact to produce results that cannot be predicted or understood based on the components alone.

.5 Assumptions

At a time of scope modelling, the validity of the model heavily relies on assumptions such as the definition of needs, causality of outcomes, impact of changes, applicability, and feasibility of the solution. The resulting scope model should include explicit statements of critical assumptions and their implications.

.6 Scope Modelling Results

Results of scope modelling can be represented as:
• textual descriptions of elements, including criteria for making in-scope or out-of-scope decisions,
• diagrams illustrating relationships of scope elements, and
• matrices depicting dependencies between scope elements.

10.41.4 Usage Considerations

.1 Strengths

• A scope model facilitates agreement as a basis for:
• defining contractual obligations,
• estimating the project effort,
• justifying in-scope/out-of-scope decisions in requirements analysis, and
• assessing the completeness and impact of solutions.

.2 Limitations

• An initial, high-level model can lack a sufficient level of granularity, particularly for boundary elements, that is needed to ensure clear scope identification.
• Once a scope is defined, changing it may be difficult due to political reasons and contractual obligations. Meanwhile, many factors can affect the scope validity before the targets are achieved. Such factors as wrong initial assumptions, situation change, evolution of stakeholder needs, or technology innovations may cause a need for revising the scope partially or entirely.
• Traditional scope models cannot address common complex boundaries, such as a horizon (a boundary that is completely dependent on the position of the stakeholder).

10.42 Sequence Diagrams

10.42.1 Purpose

Sequence diagrams are used to model the logic of usage scenarios by showing the information passed between objects in the system through the execution of the scenario.

10.42.2 Description

A sequence diagram shows how processes or objects interact during a scenario. The classes required to execute the scenario and the messages they pass to one another (triggered by steps in the use case) are displayed on the diagram. The sequence diagram shows how objects used in the scenario interact, but not how they are related to one another. Sequence diagrams are also often used to show how user interface components or software components interact.
The diagram represents information in a horizontal and vertical alignment. The objects that send messages to each other are represented as boxes that are aligned at the top of the page from the left to the right, with each object occupying a column of space on the page bordered by a vertical line stretching down to the bottom of the page. The messages that are sent from one object to

the next are represented as horizontal arrows. The order of the messages is represented in a top-down and left-to-right sequence beginning with the first message at the top left of the page and subsequent messages occurring to the right and below. Sequence diagrams are sometimes called event diagrams.
The standard notation for sequence diagrams is defined as part of the Unified Modelling Language™ (UML®) specification.

10.42.3 Elements

.1 Lifeline

A lifeline represents the lifespan of an object during the scenario being modelled in a sequence diagram. The example below shows the object order. A lifeline is drawn as a dashed line that vertically descends from each object box to the bottom of the page.

Figure 10.42.1: Lifeline

.2 Activation Box
An activation box represents the period during which an operation is executed. A call to activate is represented by an arrow with a solid arrowhead leading to the activation object. The lifeline can be terminated with an X.

Figure 10.42.2: Activation Box

.3 Message
A message is an interaction between two objects. A message is shown as an arrow coming from the activation box of the object that sends the message to the

activation box of the object that receives the message.
The name of the message is placed on top of the arrowed line. There are different types of messages:
• Synchronous Call: transfers control to the receiving object. The sender cannot act until a return message is received.
• Asynchronous Call: (also known as a signal) allows the object to continue with its own processing after sending the signal. The object may send many signals simultaneously, but may only accept one signal at a time.

Figure 10.42.3: Message

10.42.4 Usage Considerations

.1 Strengths
• Shows the interaction between the objects of a system in the chronological order that the interactions occur.
• Shows the interaction between the objects in a visual manner that allows the logic to be validated by stakeholders with relative ease.
• Use cases can be refined into one or more sequence diagrams in order to provide added detail and a more in-depth understanding of a business process.

.2 Limitations

• Time and effort can be wasted creating a complete set of sequence diagrams for each use case of a system, which may not be necessary.
• Have historically been used for modelling system flows and may be considered too technical in other circumstances.

10.43 Stakeholder List, Map, or Personas

10.43.1 Purpose

Stakeholder lists, maps, and personas assist the business analyst in analyzing stakeholders and their characteristics. This analysis is important in ensuring that the business analyst identifies all possible sources of requirements and that the stakeholder is fully understood so decisions made regarding stakeholder engagement, collaboration, and communication are the best choices for the stakeholder and for the success of the initiative.

10.43.2 Description

Stakeholder analysis involves identifying the stakeholders that may be affected by a proposed initiative or that share a common business need. Stakeholder analysis notes, considers, and analyzes the various characteristics of the identified stakeholders.
Common types of stakeholder characteristics that are worth identifying and analyzing include:
• level of authority within the domain of change and within the organization,
• attitudes toward or interest in the change being undertaken,
• attitudes toward the business analysis work and role, and
• level of decision-making authority.
For details on the work involved in conducting a thorough stakeholder analysis, see Plan Stakeholder Engagement (p. 31).
When analyzing stakeholders, business analysts utilize one or more techniques to draw out a list of stakeholders and analyze them. Stakeholder lists, maps, and personas are three tools that can be utilized when conducting this work.

10.43.3 Elements

.1 Stakeholder Lists

A business analyst may apply a number of techniques to generate a stakeholder list. Brainstorming and interviews are two common techniques that can be used. The goal is to ensure a thorough list is produced because this list is central to both stakeholder analysis activities and the planning work the business analyst performs for elicitation, collaboration, and communication.
Stakeholder lists may become quite lengthy. As the analysis is conducted, the business analyst categorizes and adds structure to the list. It is important to have an exhaustive list to ensure that no important stakeholder or stakeholder group has been overlooked, which opens up the risk that requirements will be missed later on.

.2 Stakeholder Map

Stakeholder maps are diagrams that depict the relationship of stakeholders to the solution and to one another.
There are many forms of stakeholder maps, but two common ones include:
• Stakeholder Matrix: maps the level of stakeholder influence against the level of stakeholder interest.
• Onion Diagram: indicates how involved the stakeholders are with the solution, which stakeholders will directly interact with the solution or participate in a business process, which are part of the larger organization, and which are outside the organization.
The business analyst typically starts their stakeholder analysis by reviewing the proposed scope of the solution and then analyzing which groups will be impacted. At the start of this analysis, the business analyst may produce a stakeholder matrix to identify each stakeholder and their role as it pertains to the development of the requirements. Throughout a project, a stakeholder’s position on the matrix can change due to organizational, environmental, or requirement scope changes. Due to these potential changes, stakeholder analysis is considered iterative and reviewed frequently by the business analyst.

Figure 10.43.1: Stakeholder Matrix

High

Influence of Stakeholder

**

Low
Low
Impact on Stakeholder
High
**

• High Influence/High Impact: the stakeholders are key players in the change effort. The business analyst should focus their efforts and engage this group regularly.
• High Influence/Low Impact: the stakeholders have needs that should be met. The business analyst should engage and consult with them, while also attempting to engage them and increase their level of interest with the change activity.
• Low Influence/High Impact: the stakeholders are supporters of and potential goodwill ambassadors for the change effort. The business analyst should engage this group for their input and show interest in their needs.

• Low Influence/Low Impact: the stakeholders can be kept informed using general communications. Additional engagement may move them into the goodwill ambassador quadrant, which can help the effort gain additional support.

Figure 10.43.2: Stakeholder Onion Diagram

Customers, suppliers, regulators, and others.

Affected External Stakeholders Organization or Enterprise
Affected Organizational Unit

Solution Delivery
Sponsors, executives, domain SMEs, and others who interact with the affected group.

End users, help desk, and others whose work changes when the solution is delivered.

Project team and others directly involved with creating the solution.

.3 Responsibility (RACI) Matrix

Another popular stakeholder matrix is the responsibility (RACI) matrix. RACI stands for the four types of responsibility that a stakeholder may hold on the initiative: Responsible, Accountable, Consulted, and Informed. When completing a RACI matrix, it is important to ensure that all stakeholders or stakeholder groups have been identified. Further analysis is then conducted to assign the RACI designation in order to specify the level of responsibility expected from each stakeholder and/or group. It is common practice to define each term so that a consistent understanding of the assignment and associated roles are understood by any stakeholders utilizing the RACI matrix.
• Responsible (R): the persons who will be performing the work on the task.
• Accountable (A): the person who is ultimately held accountable for successful completion of the task and is the decision maker. Only one stakeholder receives this assignment.
• Consulted (C): the stakeholder or stakeholder group who will be asked to provide an opinion or information about the task. This assignment is often provided to the subject matter experts (SMEs).
• Informed (I): a stakeholder or stakeholder group that is kept up to date on the task and notified of its outcome. Informed is different from Consulted as with Informed the communication is one-direction (business analyst to stakeholder) and with Consulted the communication is two-way.

Figure 10.43.3: RACI Matrix

.4 Personas
A persona is defined as a fictional character or archetype that exemplifies the way a typical user interacts with a product. Personas are helpful when there is a desire to understand the needs held by a group or class of users. Although the user groups are fictional, they are built to represent actual users. Research is conducted to understand the user group, and the personas are then created based upon knowledge rather than opinion. A number of elicitation techniques can be utilized to conduct this research. Interviews and surveys/questionnaires are two techniques commonly used to elicit this information. The persona is written in narrative form and focuses on providing insight into the goals of the group.
This allows the reader to see the story from the point of view of the stakeholder group. Personas help bring the user to life, which in turn makes the needs feel real to those who design and build solutions.

10.43.4 Usage Considerations

.1 Strengths

• Identifies the specific people who must be engaged in requirements elicitation activities.
• Helps the business analyst plan collaboration, communication, and facilitation activities to engage all stakeholder groups.
• Useful to understand changes in impacted groups over time.

.2 Limitations

• Business analysts who are continuously working with the same teams may not utilize the stakeholder analysis and management technique because they perceive change as minimal within their respective groups.
• Assessing information about a specific stakeholder representative, such as influence and interest, can be complicated and may feel politically risky.

10.44 State Modelling

10.44.1 Purpose

State modelling is used to describe and analyze the different possible states of an entity within a system, how that entity changes from one state to another, and what can happen to the entity when it is in each state.

10.44.2 Description

An entity is an object or concept within a system. An entity may be used in several processes. The life cycle of every entity has a beginning and an end.
In a state model (also sometimes called a state transition model), a state is a formal representation of a status. It is used when it is necessary to have a precise and consistent understanding of an entity that has complex behaviour and complex rules about that behaviour.
A state model describes:
• a set of possible states for an entity,
• the sequence of states that the entity can be in,
• how an entity changes from one state to another,
• the events and conditions that cause the entity to change states, and
• the actions that can or must be performed by the entity in each state as it moves through its life cycle.
While a process model can show all of the entities that are used in or affected by that process, a state model shows a complementary view: what happens to one entity across all the processes that affect it or use it.

10.44.3 Elements

.1 State

An entity has a finite number of states during its life cycle, although it can be in more than one state at a time. Each state is described with a name and the activities that could be performed while in that state. There may be rules about which activities must or can be performed and which events it can respond to or trigger.

A complex state can be decomposed into sub-states.

.2 State Transition

How the entity changes or transitions from one state to another could be determined by the steps of a process, by business rules, or by information content. The sequence of states of an entity are not always linear; an entity could skip over several states or revert to a previous state, perhaps more than once.
A transition may be conditional (triggered by a specific event or a condition being reached) or automatic (triggered by the completion of the required activities while in the previous state or by the passage of time). It may also be recursive, leaving one state and returning back to the same state. A transition is described in terms of the event that causes the transition, conditions which determine whether or not the entity must respond to that event, and actions that occur in association with the event.

.3 State Diagram

A state diagram shows the life cycle of one entity, beginning when the entity first comes into existence and moving through all of the different states that the entity may have until it is discarded and no longer of use.
A state on a state diagram is shown as a rectangle with rounded corners. There may be any number of states. A state may be decomposed into sub-states.
The transition from one state to another state is shown with a one-directional arrow pointing from the start state to the destination state, optionally labelled with the name of the event that causes the entity’s state to change from one state to another, and optionally with conditions and actions.
The beginning and end of the entity’s life cycle are shown with special symbols for both the initial state, which indicates that the entity has come into existence, and the final state, which indicates that the entity is discarded and the life cycle is complete.

Figure 10.44.1: State Transition Diagram

**

.4 State Tables
A state table is a two-dimensional matrix showing states and the transitions between them. It can be used during elicitation and analysis either as an alternative, a precursor, or a complement to a state diagram. It is a simple way to get started on a state model in order to elicit the state names and event names from the domain subject matter experts.
Each row shows a starting state, the transition, and the end state. If one state could respond to several transitions, there will be a separate row for each transition.
A state that appears as an end state in one row could be a start state in another row.

10.44.4 Usage Considerations

.1 Strengths

• Identifies business rules and information attributes that apply to the entity being modelled.
• Identifies and describes the activities that apply to the entity at different states of the entity.
• Is a more effective documentation and communication tool than plain text, especially if the entity being described has more than a few states, transitions, and conditions governing those transitions.

.2 Limitations

• Is usually only used to understand and communicate about information entities that are perceived to be complex; simple entities may be understood without the time and effort required to build a state model.
• Building a state model appears simple at the start, but achieving a consensus among domain SMEs about the details required by the model can be difficult and time-consuming.
• A high degree of precision about states and transitions is required to build a state diagram; some domain SMEs and business analysis practitioners are uncomfortable trying to describe such a level of detail.

10.45 Survey or Questionnaire

10.45.1 Purpose

A survey or questionnaire is used to elicit business analysis information—including information about customers, products, work practices, and attitudes—from a group of people in a structured way and in a relatively short period of time.

10.45.2 Description

A survey or questionnaire presents a set of questions to stakeholders and subject matter experts (SMEs), whose responses are then collected and analyzed in order to formulate knowledge about the subject matter of interest. The questions can be submitted in written form or can be administered in person, over the telephone, or using technology that can record responses.
There are two types of questions used in a survey or questionnaire:
• Close-ended: the respondent is asked to select from a list of predefined responses, such as a Yes/No response, a multiple-choice selection, a rank/ order decision, or a statement requiring a level of agreement. This is useful when the anticipated range of user responses is fairly well defined and understood. The responses to close-ended questions are easier to analyze than those gained from open-ended questions because they can be tied to numerical coefficients.
• Open-ended: the respondent is asked to answer questions in a free form without having to select an answer from a list of predefined responses. Open-ended questions are useful when the issues are known and the range of user responses is not. Open-ended questions may result in more detail and a wider range of responses than closed-ended questions. The responses to open-ended questions are more difficult and time-consuming to categorize, quantify, and summarize as they are unstructured and often include subjective language with incomplete or superfluous content.
Questions should be asked in a way that does not influence the response data. They should be expressed in neutral language and should not be structured or sequenced to condition the respondent to provide perceived desirable answers.

10.45.3 Elements

.1 Prepare

An effective survey or questionnaire requires detailed planning in order to ensure that the needed information is obtained in an efficient manner.
When preparing for a survey or questionnaire, business analysts do the following:
• Define the objective: a clear and specific objective establishes a defined purpose of the survey or questionnaire. Questions are formulated with the intent of meeting the objective.
• Define the target survey group: identifying the group to be surveyed in terms of population size and any perceived variations (for example, culture, language, or location) helps identify factors that can impact survey design.
• Choose the appropriate survey or questionnaire type: the objective of the survey or questionnaire determines the appropriate combination of close-ended questions and open-ended questions to elicit the information required.

• Select the sample group: consider both the survey or questionnaire type and the number of people in the identified user group in order to determine if it is necessary and feasible to survey the entire group. It may be important to survey all members—even of a large group—if their demographics indicate a wide variance due to geographic distribution, regulatory differences, or lack of standardization in job function or business process. If the population is large and the survey type is open-ended, it may be necessary to identify a subset of users to engage in the questionnaire process. Using a statistical sampling method will help ensure that the sample selected is representative of the population so that the survey results can be reliably generalized.
• Select the distribution and collection methods: determine the appropriate communication mode for each sample group.
• Set the target level and timeline for response: determine what response rate is acceptable and when it should be closed or considered complete. If the actual response rate is lower than the acceptable threshold, the use of the survey results may be limited.
• Determine if the survey or questionnaire should be supported with individual interviews: as a survey or questionnaire does not provide the depth of data that can be obtained from individual interviews, consider either pre- or post-survey or questionnaire interviews.
• Write the survey questions: ensure that all the questions support the stated objectives.
• Test the survey or questionnaire: a usability test on the survey identifies errors and opportunities for improvement.

.2 Distribute the Survey or Questionnaire

When distributing the survey or questionnaire it is important to communicate the survey’s objectives, how its results will be used, as well as any arrangements for confidentiality or anonymity that have been made.
When deciding on a method of distribution (for example, in-person, e-mail, or survey tool), business analysts consider:
• the urgency of obtaining the results,
• the level of security required, and
• the geographic distribution of the respondents.