Chapter Foundation Concepts

1 CBAP®/CCBA™ EXAM TOPICS COVERED

IN THIS CHAPTER

✓ Describe business analysis and the role of the business

analyst.

✓ Recognize the basic contents, structure, and intent of the

BABOK® Guide.

✓ Define the BABOK® Guide requirements classification

scheme.

✓ Explore the six business analysis knowledge areas.

✓ Map business analysis activities to a generic project

life cycle.

✓ Understand the content and intent of the BABOK® Guide.

Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 This chapter lays the foundation for navigating and
understanding the content and intent of A Guide to the
Business Analysis Body of Knowledge ® (BABOK® Guide).
It is our high-level look at what it means to be a business analyst and how to successfully
perform business analysis work. Business analysts can be found in all facets of an
organization — projects, programs, strategic planning, operations, or other initiatives.
Although the examples in this chapter use projects and the project life cycle to step through
the discipline, remember that business analysts do not have to be members of a project
team to do their jobs. They can work almost anywhere.
The set of generally accepted best practices defi ned by the BABOK® Guide provides a
business analysis framework defi ning areas of knowledge, associated activities and tasks,
and the skills required to perform them. The scope of this standard covers pre-project
activities, the full project life cycle, and the fi nal product’s operational life.

What Is Business Analysis?

Let’s start with an example of how difficult it can be to do business analysis work when
you are not certain where to begin. New business analysts start their careers in a number
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

of ways. In the past, it was not uncommon for young software engineers to transition
into the business side of an organization when their manager called them into their office,
saying, “We are short-staffed, and I need you to figure out what the users need this new
software application to do.” The fledging business analyst needed to discover who to talk
to, what to ask, how to ask, and how to document the information that they discovered in
a way that made sense to the development team and to the business. This was not an easy
task the fi rst time around!
In this situation, performing basic business analysis work took a lot longer than it
seemed like it should. These unprepared rookie business analysts had great difficulty
deciding exactly how to get started. There was no process in place to guide them and no
one available to point them in the right direction. They found themselves longing to go
back to their cubicles and just write some more code. Luckily, there is no need for business
analysts to feel this way today. There are standards, books (like this one), websites, blogs,
and tons of experienced folks out there to mentor and guide business analysts in getting
the job done right.
Business analysis is the glue that holds successful organizations together. It is a distinct
discipline focusing on identifying business needs, problems, and opportunities, and
on determining the appropriate solutions to address them. The resulting projects and

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 What Is Business Analysis? 3

initiatives may focus on systems development, process improvement, organizational change,

or some combination of the three. Business analysis touches all levels of an organization:
strategic, tactical, and operational. Business analysts participate across the project and the
product life cycles as they look at all aspects of an organization’s enterprise architecture,
stakeholder needs, business process, software, and hardware.
The set of generally accepted best practices defi ned by the BABOK® Guide make this
book an essential resource for every business analyst. You should take this basic business
analysis framework and make it work for you and your projects. The areas of knowledge,
associated activities and tasks, and the skills required to perform them will give you a
valuable starting point for introducing, validating, or improving your business analysis
processes throughout an organization. Even better, the scope of the BABOK® Guide covers
pre-project activities, the full project life cycle and the fi nal solution’s operational life.
The BABOK® Guide focuses on building underlying competencies that make for a
successful business analyst on today’s projects. The BABOK® Guide defi nes business
analysis as “the set of tasks and techniques used to work as a liaison among stakeholders
in order to understand the structure, policies, and operations of an organization and to
recommend solutions that enable the organization to achieve its goals.” Put simply, a
business analyst is defi ned as anyone performing these business analysis activities.
When looking at business analysis in an organization, you need to make sure that
you know how the organization views its business analysts. First, what is the role of the
business analyst? Second, what is the expected relationship between the business analyst
and the project manager? And third, who are the stakeholders with whom the business
analyst will be interacting along the way? We will look at each of these topics next.

The Business Analyst ’s Role

Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

The linchpin of successful business analysis is the business analyst performing the actual
work. Their involvement in defi ning and validating solutions that address key business
needs and goals is essential to both project and business success. According to the
BABOK® Guide, “A business analyst works as a liaison among stakeholders in order to
understand the structure, policies, and operations of an organization, and to recommend
solutions that enable the organization to achieve its goals.”
So, what exactly is the job description for the business analyst? There have been many
job postings lately that came straight from the BABOK® Guide role defi nition. That
is a good sign. The adaption and integration of these principles as best practices in the
corporate environment will lead to stronger business analysis process, better business
analysts, and more credibility and consistency in the role of business analysts today. Here
is a short list of the business analyst’s job responsibilities from the BABOK® Guide:
■ Liaises and communicates with project stakeholders
■ Elicits, analyzes, and validates project requirements for changes to business process,
policies, and information systems
■ Understands business problems and opportunities in the context of the requirements
■ Recommends solutions enabling the organization to achieve its goals

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 4 Chapter 1 ■
Foundation Concepts

In many organizations, the folks performing business analysis work do

not have the job title of “business analyst.” The business analyst role can
be filled by anyone performing business analysis work regardless of job
title. The BABOK® Guide lists a number of job roles that may do business
analysis work, such as business system analysts, requirements engineers,
process analysts, product managers or owners, enterprise analysts,
business architects, and management consultants.

Additional Roles: Generalist, Specialist, and Hybrid

The International Institute of Business Analysis (IIBA)’s Business Analysis Competency
Model, Version 2. 0 takes a closer look at the role of the business analyst in today’s
projects and initiatives. As part of the job profi le, they classify business analysts using
three categories:
Generalist The generalist role is effective across a wide range of techniques and is able to
adapt to a range of project circumstances.
Specialist The specialist role uses a limited set of business analysis techniques with great
skill and expertise, often working on complex business problems.
Hybrid The hybrid role combines business analysis competencies with other professions,
such as project management or testing.

Essential Skills of Effective Business Analysts

Business analysts must possess a wide spectrum of skills and knowledge. Being a technical
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

expert in a particular area does not guarantee success as a business analyst on a project. In
addition to the necessary business, technical, and domain knowledge, the business analyst
should have management, interpersonal, business, and structured problem-solving skills.

Reviewing Requirements Over a Cup of Coffee

Years ago, Phil was leading a team working on an executive compensation system for
top -level management. The team needed input from a small, closed community of
senior and executive management customers in order to define the current and future
processes. Unfortunately, his key contact from this group felt that the job of customer
interface had been given to a young, up -and- coming star who didn’t have a clue. This
made developing a rapport with the key customer contact almost impossible. However,
the project deadlines remained inflexible, as they usually do.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 What Is Business Analysis? 5

Taking what little input was offered and doing significant research from other sources,
the team compiled their draft of the business requirements document. The document
was huge. It was single - spaced and double - sided, and it filled a three -inch binder.
There was a meeting to step through it. The customer contact was there and took her
place at the head of the table. Phil sat at the opposite end of the table.

During the meeting, the customer ’s demeanor grew increasingly agitated. She hurled the
requirements document down the table toward my friend along with the exclamation,
“I don’t do this kind of menial work.” Unfortunately, Phil reacted by returning the
document in the same manner. His aim wasn’t quite as true, and the document slammed
into her coffee cup sending a spray of hot, sugary liquid into her lap. Her color changed
from the red of aggravation to the scarlet of rage. She stalked out of the room. So
much for creating rapport with the customer! In the end, it all worked out. Both parties
apologized and the project (meeting the business requirements that had been approved)
was delivered. But how much better things could have been if this situation had been
avoided in the first place.

The technical experts on the project team may not be the best choice for the business
analyst role. Technical skills and expertise are necessary on the project team, but they
are not the skills and knowledge that separate effective business analysts from the
pack. Superior business analysis skills are not necessarily derived from a superior set
of technical skills.

Soft skills and knowledge support and enable effective business analysis. Knowing
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

what to do and when to do it is a good start for a business analyst, but how you actually
do that work makes a big difference! The BABOK® Guide refers to these behaviors as the
“underlying competencies” of effective business analysts. The underlying competencies
are in addition to knowing what business analysts produce from a work activity and a
deliverable perspective. They encompass the interpersonal skills and additional business
and technical knowledge that are necessary for doing the business analyst’s job well. These
essential skills range from applying structured analysis techniques to issue management to
addressing solution usability concerns.
The BABOK® Guide puts the essential skills and knowledge of effective business
analysts into six categories:
Analytical thinking and problem-solving skills
Behavioral characteristics
Business knowledge
Software knowledge
Interaction skills
Communication skills

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 6 Chapter 1 ■
Foundation Concepts

Let’s take a quick look at each of these categories that are the building blocks for the
business analyst’s skill and knowledge.
Analytical Thinking and Problem-Solving Skills Facilitating solutions to business
problems would be impossible without a logical mind. Analytical thinking and problem-
solving skills enable the business analyst to assess and understand a situation. Once that
situation is fully understood, the business analyst assesses and recommends one or more
potential solutions to address the business need, problem, or opportunity.
Behavioral Characteristics Effective business analysts apply personal integrity and
strength of character when dealing with people, including the business analysis team,
project team, and internal and external project stakeholders. The ability to build strong,
lasting working relationships serves both the business analyst and the project well.
Business and Software Knowledge It is impossible to be a liaison between the business
and the technology if you have no understanding of the business. Skilled business analysts
understand the internal and external business environment surrounding their projects, and
they use that knowledge to make good decisions and recommendations.
Software applications are typically used by the business analyst to develop and manage
requirements. This can range from using a word processor to document project scope to
using a requirements management tool to develop detailed user and system requirements.
Although using a requirements management tool is not a required skill, the ability to
master and apply requirements management, word processing, and spreadsheet tools are
desirable traits in experienced business analysts.
Interaction Skills Good business analysts are team players. In large part, this is due
to their ability to interact and work well with other members of the team. Leadership
and facilitation skills play a key part in defi ning and agreeing to a solution to a business
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

problem or need.
Communication Skills The number one reason for project failure is poor communication.
Business analysts must have excellent communication skills in order to develop requirements.

The underlying competencies of effective business analysts have

numerous pieces and parts. In Chapter 8, “Underlying Competencies,” we
will discuss them in more depth, and we will add in a few additional skills
that you might want to use on your projects.

The Business Analyst and the Project Manager

There is much buzz about the potential for overlap and confl ict between the project
manager and the business analyst. Interestingly enough, many project managers perform
business analysis work early in their projects — developing feasibility studies, business cases,

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 What Is Business Analysis? 7

scope statements, and business-level requirements as part of project selection, initiation,

and scope defi nition. Many project managers were part of the business analysis team
earlier in their careers. As a result, many project managers have business analysis skills to
complement and overlap their project management skill set.
The project manager’s responsibilities differ from the responsibilities of the business
analyst in several ways. The project manager focuses on meeting the project objectives.
They initiate, plan, and manage the project. The project manager makes sure the
project team delivers a solution that meets requirements, the acceptance criteria, and
the customer’s quality expectations. The project manager juggles the many constraints
present on a project, such as scope, budget, schedule, resources, quality, and risk. On
a large project, the business analysis team is only one part of the project resources the
project manager is managing.
The business analyst and the project manager typically work closely together on projects
and must maintain good communications. There is potential for the project manager and
the business analyst to be in conflict with one another. The business analyst works with key
stakeholders to understand the structure, policies, and operations of an organization and to
recommend solutions. The project manager focuses on planning and managing the project
to achieve the project objectives and deliver those solutions to the stakeholders. Where are
they going to step on each other’s toes? There are two key areas for confl ict: stakeholder
communication and planning.
The project manager and the business analyst both need to communicate well with
key stakeholders. Without planning and discussion, the project manager and the business
analyst could easily come to blows about who “owns” the stakeholders, when in actuality
the project “owns” the stakeholders. A good project-level communications plan needs to be
built and followed to minimize potential areas of political game play and conflict. As far as
planning goes, the business analysis team must remember that it is a subset of the project
team. As such, any business analysis work plans they put together must be consistent with
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

and roll up into the overall project plan.

Dealing with Key Stakeholders

There is no project without stakeholders. Stakeholders have a vested interest in the project
and its outcome, and they are the major source of requirements, constraints, and assumptions
for the business analyst. Remember that stakeholder roles are like hats — one person may
wear multiple hats and fill more than one role on a project.
There are a number of generic stakeholders that will interact with the business analyst
across the project life cycle. While the list in Table 1.1 doesn’t cover every possible role, it
is a good starting point for who should be involved with your business analysis activities.
Many organizations have different names for the same role, so don’t get excited if these are
not the generic stakeholder roles with which you are familiar. In addition to the business
analyst, there are a number of key stakeholder roles involved with business analysis
activities. They are summarized in Table 1.1.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 8 Chapter 1 ■
Foundation Concepts

TA B L E 1 .1 Key Business Analysis Stakeholders

Stakeholder Description

Customer Uses the products, services, or solutions.

Domain Subject Matter Possesses detailed, in - depth knowledge of a particular topic or

Expert (SME) problem area of the solution scope or the business need.

End User Directly interacts with the resulting solution when it has been
completed and deployed.

Implementation SME Responsible for designing and implementing potential

solutions and providing specialist expertise.
Subsets of the Implementation SME role include developers,
software engineers, organizational change management
professionals, system architects, trainers, and usability
professionals.

Operational Support Helps to keep the solution functioning by providing end user
support or day-to - day operational support.

Project Manager Manages the work performed to deliver the solution.

Tester Verifies that the designed and constructed solution meets the
requirements and quality criteria for that solution.

Regulator Defines and enforces standards for developing the solution or

for the resulting solution itself.
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Sponsor Authorizes the solution development work to be performed and

controls the budget.

Supplier Provide products or services to the organization.

Exam Spotlight

These stakeholder role names and definitions from the BABOK® Guide are exactly
what you will see in your exam questions. The business analyst is a stakeholder for
all business analysis activities and is responsible and accountable for their execution.
Remember that stakeholder roles are like hats. One person can wear one or many hats
across the project life cycle. The roles are not necessarily the same as their job titles;
however, they do indicate the job responsibilities and the level of accountability for the
person filling that particular role on a project.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Exploring the Business Analysis Knowledge Areas 9

Exploring the Business Analysis

Knowledge Areas
The BABOK® Guide is based on a set of knowledge areas guiding the business analyst
when they perform business analysis activities at any point in the project or product life
cycle. Knowledge areas defi ne what business analysts need to understand and the tasks they
should perform. They do not represent project phases, and their activities are not intended
to be performed in a linear fashion. Tasks from one or more knowledge areas may be
performed in any order (such as in succession, simultaneously, or iteratively), provided that
the necessary inputs to each task are available.
Six knowledge areas are defi ned by the standard. If you are planning to take the
Certified Business Analyst Professional (CBAP ®) or Certification of Competency in
Business Analysis (CCBA™) exam, you will need to memorize the high-level defi nition of
each knowledge area, as well as the more detailed tasks, elements, inputs, and outputs. If
you are interested in applying these knowledge areas to your work world, you will need
to master the tasks and the skills in order to become an effective business analyst. The six
knowledge areas listed here are shown in Figure 1.1.
■ Business Analysis Planning and Monitoring
■ Elicitation
■ Requirements Management and Communication
■ Enterprise Analysis
■ Requirements Analysis
■ Solution Assessment and Validation
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Exam Spotlight

Here’s a memory aid for the six knowledge areas—BEaRERS.

Business Analysis Planning and Monitoring

Enterprise Analysis

Requirements Management and Communication

Elicitation

Requirements Analysis

Solution Assessment and Validation

Business analysts are the BEaRERS of good news!

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 10 Chapter 1 ■
Foundation Concepts

F I G U R E 1 .1 Relationships between knowledge areas

Business Analysis
Planning and
Monitoring

Solution
Enterprise
Assessment
Analysis
and Validation Requirements
Elicitation Management and
Communication

Requirements
Analysis

Underlying
Competencies

Adapted from A Guide to the Business Analysis Body of Knowledge. Release 2.0. International Institute of Business
Analysis, 2009 Figure 1-1 p. 7.
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Knowledge Area: Business Analysis Planning

and Monitoring
Business Analysis Planning and Monitoring is where the business analyst plans how
to approach the business analysis effort. The approach is a set of processes, templates, and
activities used to perform business analysis in a specific context. The tasks govern
and monitor the performance of all other business analysis tasks. These planning and
monitoring activities take place throughout the project life cycle. The results of this
knowledge area govern the tasks found in the remaining five knowledge areas and set
the performance metrics to be used to evaluate all business analysis work. So, what is a
business analyst to do? Well, the business analyst’s task list for this particular knowledge
area consists of:
■ Determining the business analysis approach for the project
■ Performing stakeholder identification, analysis, and categorization
■ Defining the business analysis activities to be performed
■ Addressing business analysis communication requirements

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Exploring the Business Analysis Knowledge Areas 11

■ Planning the requirements development and management process

■ Managing and reporting on the business analysis effort

Knowledge Area: Elicitation

Elicitation defi nes how business analysts work with stakeholders to identify and gather
requirements and understand their needs and concerns. The business analyst’s task list for
this knowledge area consists of:
■ Building a detailed elicitation schedule for a specific activity
■ Meeting with stakeholders to conduct the elicitation activity
■ Documenting and recording the elicitation results
■ Confirming elicitation results with key stakeholders

Knowledge Area: Requirements Management and

Communication
Requirements Management and Communication defines how the business analyst approaches
communicating requirements to stakeholders. Tasks and techniques for managing changes,
conflicts, and issues related to requirements are also described. Business analysts perform
requirements communication activities as part of requirements development work by:
■ Managing the solution scope and requirements
■ Managing requirements traceability
■ Maintaining requirements for reuse
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

■ Preparing requirements packages

■ Communicating requirements

Knowledge Area: Enterprise Analysis

Enterprise Analysis focuses on how the business analyst identifies the business needs
driving a project by performing problem defi nition and analysis. In addition to defi ning
and refi ning these driving needs, the business analyst is responsible for defi ning a feasible
solution scope that can be implemented by the business. This work may also include
developing a business case or feasibility study for a proposed project. Typically, the
tasks in this knowledge area occur prior to or early in the project life cycle. The business
analyst’s task list for this knowledge area includes translating business strategy into
proposed new business solutions by:
■ Defining and understanding the business problem or opportunity
■ Assessing capability gaps in the organization

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 12 Chapter 1 ■
Foundation Concepts

■ Determining the most feasible business solution approach

■ Describing the resulting solution scope
■ Developing a business case for the proposed solution

Knowledge Area: Requirements Analysis

Requirements Analysis describes how the business analyst progressively elaborates and
prioritizes stakeholder and solution requirements. In essence, the business analyst takes the
elicited information and makes sense of it to derive the real requirements for the project.
This knowledge area also focuses on graphically modeling the requirements as well as
documenting them. When performing these tasks, the business analyst should ensure the
feasibility of the requirements while defining, describing, and refining the characteristics of an
acceptable solution. The business analyst’s task list for this knowledge area consists of:
■ Prioritizing the relative importance of the requirements
■ Organizing requirements
■ Specifying and modeling requirements
■ Defining assumptions and constraints
■ Verifying requirements
■ Validating requirements

Knowledge Area: Solution Assessment and Validation

Solution Assessment and Validation focuses on assessing and validating proposed, in
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

progress, and implemented solutions before, during, and after the project life cycle. While
many tasks in this knowledge area take place later in the project life cycle, some solution-
focused activities may occur quite early. The business analyst’s task list for this knowledge
area consists of:
■ Assessing the proposed solution
■ Allocating stakeholder and solution requirements
■ Assessing organizational readiness
■ Defining transition requirements
■ Validating the solution
■ Evaluating solution performance
We will examine each knowledge area and every task within it in great detail in the
coming chapters. You will need this level of knowledge to successfully prepare for and
pass the certification exams. You will also need this level of knowledge to be an effective
business analysis practitioner in your organization.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Exploring the Business Analysis Knowledge Areas 13

Exam Spotlight

Remember that business analysts are the bearers of good news—BEaRERS. This
acronym will help you to remember the six knowledge areas. Make sure you know the
correct names, descriptions, and tasks for each of them: Business Analysis Planning
and Monitoring, Enterprise Analysis, Requirements Management and Communication,
Elicitation, Requirements Analysis, and Solution Assessment and Validation.

How Are the Knowledge Areas Organized?

Knowledge areas divide what business analysts need to know and how they perform their
tasks into six common buckets. The business analyst can dip into one or more buckets at
any time —in any order — to select a deliverable or perform a necessary task. The knowledge
areas are not a road map or a methodology; they simply break business analysis stuff into
common areas.
■ Tasks
■ Inputs
■ Elements
■ Techniques
■ Stakeholders
■ Outputs
The content of each knowledge area is defi ned using the same structure. Let’s take a look at
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

this structure now.

Tasks In order to achieve the purpose of a particular knowledge area, the business analyst
must perform a defi ned set of high-level tasks. Each task has a particular purpose and
adds value to the overall effort when performed. The expectation is that each task will be
performed at least once during any project.
Inputs Inputs consist of the information and preconditions required by a task so that task
can begin. These inputs must be usable by the task that needs them. They are produced
externally to the business analysis activities, by a single business analysis task, or by
multiple business analysis tasks.
Elements Elements are the detailed concepts that are necessary to perform a particular
task. For some tasks, the elements are categories of things to be considered. For other
tasks, the elements are subtasks performed by the business analyst.
Outputs Outputs are the results that are created or changed when a task is successfully
completed. One task can have one too many outputs.
Techniques Techniques guide the business analyst in the many ways a particular task
might be done. The techniques found in the BABOK® Guide are considered best practices

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 14 Chapter 1 ■
Foundation Concepts

that are used by many business analysts. However, business analysts can certainly use
techniques that are not found in the standard.

Exam Spotlight

When you are reviewing and learning the techniques from the BABOK® Guide, make sure
you don’t miss anything! There are two types of techniques: general and knowledge area
specific. The general techniques are summarized in Appendix C, “Mapping Techniques,
Stakeholders, and Deliverables to Knowledge Areas and Tasks,” of this book and are
defined in Chapter 9 of the BABOK® Guide. They can be used by any activity, and many
are used by more than one. Knowledge area specific techniques are defined as part of the
knowledge area task that uses them. They are only used by a single task. The knowledge
area specific techniques are addressed in Chapter 2 through Chapter 7 of this book as a
part of the discussion of each specific task that uses them.

Stakeholders All tasks come with a generic list of stakeholders who may be involved in
performing that task or who might be affected by the task and its outcome. Interestingly
enough, the business analyst is a stakeholder for every business analysis activity found in
the BABOK® Guide. This makes perfect sense — the business analyst is responsible and
accountable for making sure that these tasks are done and done well. Remember that
earlier in this chapter we took a look at the key generic stakeholder roles that typically
interact with business analysts on their projects.
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Exploring Requirements
Projects are successful when what is to be accomplished is clearly stated and agreed upon.
For most projects, this statement consists of defi ning the high-level scope of the project
along with its more detailed project requirements. The general defi nition of a requirement
is something wanted or needed. Business analysts in many organizations spend a lot
of time developing requirements. This is a good thing. Defi ning and documenting
requirements allow you to quantify and document the needs, wants, and expectations
of our project stakeholders.
The BABOK® Guide uses the term requirement to cover many aspects of the business and
its needs. Their broad view of requirements addresses both the current state of the business
as well as its desired future state. Requirements may focus on the business, the users, or
the systems and subsystems that already exist or are being considered. Requirements range
from high-level enterprise capabilities to organizational structure and roles to processes
and policies. Information systems fall into the requirements realm, as do business rules.
Requirements analysis activities are also quite broad in nature. There is no prescription
for the correct level of detail in your project requirements other than what is sufficient for
understanding and subsequent action.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Exploring Requirements 15

Determining the Business Analysis Approach

The business analysis team typically determines both the business analysis approach and the
requirements management process for their project. The business analysis approach defines
the methodology used for business analysis work on the overall project and each of its phases.
It includes team roles, deliverables to be produced, how and when tasks are performed,
techniques to be used, and other aspects of the high-level business analysis process.

Defining the Requirements Management Process

The requirements management process is a detailed subset of the business analysis
approach, targeting how the team performs requirements development activities for a
project. The process should be documented in the requirements management plan. This
deliverable defi nes many things, including:
■ How the team will deal with requirements traceability
■ The explicit process for developing requirements
■ How requirements will be prioritized
■ What requirements attributes will be collected
■ How changing requirements will be handled both during requirements development
and after the requirements are agreed upon and baselined
■ Who will review and approve requirements and any requested changes
In addition, the requirements management process defi nes the types or classes of
requirements found on the project. Often, these requirements classes are associated with a
particular requirements document. Classifying requirements allows the business analysis
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

team to make sure that their project requirements are reviewed and understood by the
correct stakeholders. Requirements classes help you determine the appropriate level of
detail and the specificity needed in the project requirements, and they help you decide
how many documents you will use to defi ne what is needed.
Requirements classes can be defi ned using two dimensions: focus and type.
Requirements classified by focus tend to be named in a more traditional way:
■ High-level business requirements
■ User requirements
■ System requirements
■ Software requirements
Each lower level of requirements defi nes the level above it in greater detail. This is a
form of progressive elaboration, where the characteristics of the solution are determined
incrementally and in greater detail as the project moves forward in time. After all, the
more information you have, the better your solution defi nition will become. Solutions are
typically defi ned at a high-level of detail early in a project or initiative, and then refi ned
into more detail over time as additional information is gathered and analyzed.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 16 Chapter 1 ■
Foundation Concepts

Classifying Requirements
The BABOK® Guide contains its own requirements classification scheme. This is the
scheme that we will be using throughout the book as well as the scheme you will see
on the certification exams. A requirement is defi ned as a condition or capability needed
by a stakeholder to solve a problem or to achieve an objective. This aligns nicely with
the International Institute of Electrical and Electronics Engineers (IEEE) defi nition of
requirements for software-intensive systems. Regardless of your project type, the project
requirements must be used to design, develop, and deliver a solution that adds value to the
business as a whole.
In order to implement the BABOK® Guide requirements classification scheme, you will
need to assess and map the levels of requirements to your existing requirements process and
the resulting requirements documents. You don’t have to use these requirements classes if you
don’t want to use them. However, you do need to make sure that all of these requirements
classes are being addressed by your requirements development approach in some way. The
relationship between the BABOK® Guide requirements classes is shown in Figure 1.2.

F I G U R E 1. 2 Classes of requirements

Business
Requirements

Stakeholder
Requirements
Transition
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Requirements
Solution
Requirements

Functional Nonfunctional
Requirements Requirements

Let’s take a closer look at each class of requirements.

Business Requirements Business requirements are the highest level of requirements
and are developed during Enterprise Analysis activities. They defi ne the high-level goals,
objectives, and needs of the organization. They also describe and justify the high-level
business functionality that is needed in the resulting solution. In order to defi ne a solution,
the business requirements will be progressively elaborated and decomposed to the next
level of detail, the stakeholder requirements.
In the BABOK® Guide, the business requirements are not contained within a single,
standalone document. They are composed of a set of Enterprise Analysis task deliverables,

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Exploring Requirements 17

including the business need, the required capabilities, the solution scope, and the business
case. (We will look at these deliverables in more detail later when we dig into this knowledge
area in Chapter 2, “Controlled Start: Business Analysis Planning and Monitoring.”)
Stakeholder Requirements These requirements defi ne the needs of stakeholders and
how they will interact with a solution. Stakeholder requirements bridge between the
business requirements and the more detailed solution requirements. Many folks refer to
stakeholder requirements as high-level user requirements. They identify what is needed from the
user’s perspective and define “big picture” capabilities that the resulting solution must possess.
Stakeholder requirements are developed and defined as part of the tasks found in
the Requirements Analysis knowledge area. Like the business requirements, the
stakeholder requirements will be progressively elaborated into the more detailed
solution requirements.
Solution Requirements Solution requirements are the most detailed type of requirements
found in the standard. They describe the solution characteristics that will be needed
to meet the higher-level business and stakeholder requirements. Typically, solution
requirements are subdivided into two specific types: functional requirements and
nonfunctional requirements. They are developed and defi ned as part of the tasks found
in the Requirements Analysis knowledge area.
Functional Requirements Functional requirements defi ne the capabilities that a
product must provide to its users. They are a subset of the Solution Requirements that
are developed for the project.
Nonfunctional Requirements Nonfunctional requirements describe quality attributes,
design and implementation constraints, and external interfaces that the product must
have. They are a subset of the Solution Requirements that are developed for the project,
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

and they are typically paired up with the functional requirements that they constrain and
bound in some way. They would add characteristics to the functional requirements
Transition Requirements Transition requirements defi ne the solution capabilities required
to transition from the current to the future state and are no longer needed once the transition
is complete. Typically, transition requirements are created later in the project life cycle after
both the current and new solutions have been defined. They are developed and defi ned as
part of the tasks found in the Solution Assessment and Validation knowledge area.

Case Study: Palmer Divide Vineyards

You are a team member at Palmer Divide Vineyards, currently defining their new green
initiative. The owners would like to conserve energy and water resources, reduce
pollution, recycle more effectively, and become a certified Green Business. You have
been assigned to lead the team to discover the IT requirements for the project.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 18 Chapter 1 ■
Foundation Concepts

Following discussions with the IT group, you learn that the existing information systems
will not support the ongoing green initiative research studies. You recommend that
Palmer Divide’s business requirements include the following statement: “The vineyard
operation shall upgrade existing information systems to support ongoing green initiative
research studies.”

Breaking down the IT system business requirement for the vineyard yields the following
stakeholder requirement focusing on stakeholder interaction with the system: “The
research team sets up the tracking data for a new green initiative study.” This would be
one of many stakeholder capabilities that the upgraded systems would provide.

Next, you look into the solution requirements for the stakeholder study parameter
capabilities and recommend that the project solution requirements include: “The research
study leader logs into the system with study leader access privileges. The research study
leader defines the set of research study data fields for their research project.” This would
be a functional requirement.

A nonfunctional requirement accompanying the previous set of functional requirements

addresses the access and authentication parameters for logging in to the system.
“Logging in as a study leader provides read, write, update, and delete capabilities for
selected study data.”

Transition requirements included data conversion activities for the upgraded IT system.

Our favorite requirements classification scheme comes from the software engineering
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

standards developed by the IEEE. It focuses on the three Cs — capabilities, conditions, and
constraints. According to the IEEE, a requirement is a capability needed by a user to solve
a problem to achieve an objective. These capabilities must be met or possessed by a product
to satisfy a contract, standard, specification, or other formally imposed documentation.
Conditions and constraints together equal the nonfunctional requirements classification
found in the BABOK® Guide. Conditions are statements that determine a possible
outcome, like the “if” part of an “if-then” statement. Constraints are limits or boundary
values for a particular function or capability.

Classifying Project Requirements Your Way

The IEEE requirements classes align quite nicely with the BABOK® Guide requirements
classes. Basically, the capabilities are the functional requirements and the other two classes
are the nonfunctional requirements. Functional requirements defi ne the capabilities
provided to users and other interested parties, while nonfunctional requirements defi ne
conditions of the system or product as a whole as well as any constraints or limits on all or
part of the system. You can easily extend the three Cs to focus across the different levels of
requirements focus, such as the business, stakeholder, and solution requirements found in
the BABOK® Guide.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Exploring Requirements 19

The Requirements State Machine

When you look at requirements across the project life cycle, you will notice that they
change as the project progresses. They start as a bunch of information and are analyzed
into meaningful requirements. The analyzed requirements are reviewed and approved by
their key stakeholders. Following review and approval, the requirements are used as the
basis for designing a solution. See the pattern? Requirements development fits nicely into
a state machine approach as the requirements change over time — they transition from
state-to-state based on actions that have been taken. Many requirements deliverables
are modified based on the state that they are in at a particular point in time. This is
particularly true for the requirements found in the BABOK® Guide.

Exam Spotlight

When preparing for your exam or simply trying to apply the best practices in the book, be
aware of states and how they affect where you are in the project life cycle relative to your
business analysis work, what has been done, and what should be done next.

You will see these different types and states of requirements used when naming inputs
and outputs to business analysis activities. This will help you recognize where you are in
the project life cycle and where you are in your requirements development process. You
may also see the term Requirements with no modifiers attached, or noted as Requirements
[Any], indicating any class of requirement in any state. Inputs and outputs from business
analysis tasks may use this notation.
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Let’s say you are developing your project’s business requirements. According to the
BABOK® Guide, the solution requirements include the business need, the required
capabilities, the solution scope, and the business case. This is the set of deliverables produced
by Enterprise Analysis activities. The solution scope defines the capabilities that a solution
must possess in order to meet a business need. In addition to modifying your requirements
to the specific class of requirements you are focusing on, business requirements, you can also
reflect the state of these business requirements at a particular point in time.
When you develop business requirements, you will need to elicit information from key
stakeholders about what they and the business actually need. These stated requirements reflect
what the users have told the business analyst about what they need. As part of our elicitation
results, these stated business requirements will be analyzed, prioritized, validated, and verified
prior to becoming the accepted set of business requirements for the project. They would be
named Requirements [Stated] in the inputs or outputs for a particular task, indicating that
your business analysis team sought information from the users about what they needed.
The requirements state machine is worth watching; it provides the business analyst with
guidance and recommendations about what has already taken place and what might be
the logical next step in the requirements development process. Table 1.2 summarizes the
possible states and may be of assistance when you are navigating the BABOK® Guide.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 20 Chapter 1 ■
Foundation Concepts

TA B L E 1 . 2 The BABOK® Guide Requirements State Machine Summary

Requirements State Description

Allocated Associated with the solution component or components

that will implement the requirements

Analyzed Modeled and specified requirements

Approved Agreed to by stakeholders and ready for use in subsequent

business analysis or implementation efforts

Communicated Shared with and understood by the stakeholders in their

current state

Maintained and Reusable Formatted and suitable for long-term or future use by the
organization; may be saved as organizational process assets

Prioritized Having an attribute describing its relative importance or

assigned priority to stakeholders and the organization

Stated Stated needs expressed by the stakeholders during

elicitation

Stated, Confirmed Confirmed by the business analyst to match both the

stakeholders needs and their understanding of the problem

Stated, Unconfirmed Representing the business analyst ’s understanding of the

stakeholder intentions
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Traced Having clearly defined and identified relationships to other

requirements within the solution scope

Validated Demonstrated to deliver value to stakeholders, are within

the solution scope and are aligned with business goals/
objectives

Verified Requirements have been checked and are of sufficient

quality to allow further work to be performed

Keep an eye on the classes of requirements and their current states as you navigate and
use all of the knowledge area tasks. They provide valuable road signs to keep you headed in
the right direction.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Understanding How This Applies to Your Projects 21

Exam Spotlight

As part of your studies, be sure that you are comfortable with the requirements classes from
the BABOK® Guide. They represent the requirements taxonomy used on the exam. If you
classify your requirements another way, try to forget about that as you take your exam! It
will also be helpful to remember which knowledge area creates which type of requirements.

Understanding How This Applies

to Your Projects
As you can tell from this fi rst chapter, successful business analysts bring a serious mixture
of skills, dedication, and knowledge to their projects in order to solve business problems
and meet business needs. It isn’t just the ability to execute the business analysis techniques
that gets the job done, either. Effective business analysts must also possess excellent
interpersonal skills as well as a strong set of business and technical knowledge.

The Fledging Business Analyst Makes a Mistake

Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Everyone has to start somewhere. Phil’s first formal solo assignment as a fledgling
business analyst was to aid in the automated tracking of key performance measurements
for one of the operating departments in a large telecommunications firm. The process
was manual and senior management felt that it was time to make it computer-based. Phil
left his software engineering role behind, put on his business analysis hat, and went to
figure out exactly what was required.

Phil followed the rules for being a business analyst on this new assignment. He interviewed
the client and captured every word. He parroted back the key elements of the conversations.
He carefully documented the current processes as described. He obtained sign-off from
the client sponsor. Phil was proud of following the rules and getting this complex manual
algorithm explained in concise and well-understood terms.

When programmed (by someone else), the automated results didn’t come close to what
the manual process reported. Phil proceeded to put his technical hat back on and spent
days pouring through reams of manual data, comparing that data with the automated
results. After consulting with the client sponsor (along with his reams of data), Phil
discovered that he had missed an unrevealed rule about how the data values were

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 22 Chapter 1 ■
Foundation Concepts

tracked on a daily and monthly basis. Because he understood the math, the business, and
the technology of the automated system, he was able to ripple this new requirement
and deliver a solution that met the client ’s requirements.

It’s okay for Phil to wear multiple hats on his projects, as long as he realizes which hat he
has on at any particular time. People often find it difficult to leave the technical work behind
and think about the business when they are wearing their business analyst hat. Doing so
can lead the fledging business analyst into trouble, resulting in incorrect or incomplete
requirements and project problems downstream. Phil was lucky that he was able to put his
technology hat back on and address his requirements problem sooner rather than later.

Business analysts must also be able to map the proven principles, best practices, and
deliverables of the BABOK® Guide across their organization’s project life cycle. This
allows them to create a flexible framework for the essential work activities of the business
analyst. The standard allows you to build a business analysis methodology providing an
integrated framework of elements for successful business analysis work that can be tailored
to the project environment.

Exam Spotlight

This generic life cycle model is not on the exam. However, if you plan to use the BABOK®
Guide as the basis for your business analysis work activities, you have to make it work for
your organization. Mapping to your existing life cycle model is the first step in integrating
these best practices into your own projects.
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Different business analysis skills, techniques, and knowledge are used at different places
in the project life cycle. To implement the contents of the BABOK® Guide on your projects,
you will need to map what needs to be done to when you would like to do it. If you have
an existing project life cycle in your organization, this is the time to dust it off and use it. If
not, it’s time to build one. Our generic project life cycle consists of three parts: controlled
start, controlled middle, and controlled end. When you think about your projects, one way
to keep track of what needs to be done is to know “when and where” you are in this simple
model (see Figure 1.3).

Don’t confuse the six knowledge areas of the BABOK® Guide with the
phases of the project life cycle. The BABOK® Guide is not a methodology
or a road map for business analysis. Instead, it is a set of best practices
that can be used to build a framework for business analysis activities
supporting the activities and deliverables defined by an organization’s
project life cycle. The organization is responsible for mapping these best
practices to their selected project life cycle.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Understanding How This Applies to Your Projects 23

F I G U R E 1. 3 Mapping the BABOK® Guide to a generic life cycle

Business Analysis Work

Controlled Controlled Controlled

Start Middle End

Initiate and Monitor and Perform Transition

Perform Pre- Formally
Plan Overall Control Project Technical Solution to
Project Close the
Project and Work for Each Project Ongoing
Activities Project
Next Stage Stage Work Operations

Business Analysis Planning and Monitoring

Enterprise Analysis

Elicitation

Requirements Analysis

Solution Assessment and Validation

Requirements Management and Communication

Controlled Start The controlled start to a project includes the pre-project activities
where you determine if this is a viable and worthwhile project for the business. It also
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

covers the project initiation, where you do more detailed planning for our overall project
and for the next detailed project stage. At the end of the controlled start activities, you
should have your project scope fi nalized, business justification in place, and the high-level
project plan built. The project team should be ready to get to work. Numerous tasks and
deliverables from the Enterprise Analysis and Business Analysis Planning and Monitoring
knowledge areas are used at this point in time with a little Requirements Management and
Communication work thrown in for good measure.
Controlled Middle The controlled middle of a project is where the technical work gets
done, one stage or phase at a time. The project manager uses the plan to measure and
monitor project performance and to control what takes place. This is Management by
Walking Around (MBWA), where you are into everything — regular status, informal
conversations, checking the health of the project, dealing with stakeholders, forecasting
future performance, and dealing with issues and risks. The business analysis work
is a subset of this plan, and business analysis work performance is also managed
and controlled during this time. Business analysis tasks typically include those from
the Elicitation, Requirements Analysis, Solution Assessment and Validation, and
Requirements Management and Communication knowledge areas.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 24 Chapter 1 ■
Foundation Concepts

Controlled End A controlled end to a project is when you are wrapping up a job well
done. This can also take place if your project was prematurely terminated for one reason
or another, hopefully a rare event. You take stock of achievements, report on the effort,
ensure objectives and acceptance criteria are met, and transition the final product of
your project into its operational life. There are specific tasks in Solution Assessment and
Validation that focus on this part of the project life cycle.

Summary
You covered a lot of content in this chapter! You learned that business analysis is an
essential part of every organization. Successful business analysts bring a serious set of
skills and knowledge to every project or initiative in order to liaise among the stakeholders
to address business needs and solve business problems. Business analysis is more than just
asking questions!
You looked at how the BABOK® Guide provides a business analysis framework defi ning
areas of knowledge, associated activities and tasks, and the skills required to perform them.
The scope of the BABOK® Guide covers pre-project activities, the full project life cycle,
and the fi nal solution’s operational life. It is also the basis for the CBAP ® and CCBA™
certification exams, and it provides the backbone of this book.
The BABOK® Guide contains its own requirements classification scheme. This is the
scheme you will see on the certification exams. A requirement is defi ned as a condition or
capability needed by a stakeholder to solve a problem or to achieve an objective. Classifying
requirements allows the business analysis team to make sure that their project requirements
are reviewed and understood by the correct stakeholders. Requirements classes help
you determine the appropriate level of detail and the specificity needed in the project
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

requirements, and to decide how many documents you will use to defi ne what is needed.
The six business analysis knowledge areas were visited as a part of our chapter tour.
These knowledge areas guide the business analyst when they perform business analysis
activities at any point in the project or product life cycle. They defi ne what business
analysts need to understand and the tasks they should perform. They do not represent
project phases, and their activities are not intended to be performed in a linear fashion.
In order to use the BABOK® Guide at work, you will need to map its business analysis
tasks to your own Project Life Cycle (PLC) or Systems Development Life Cycle (SDLC).
This will allow you to create a business analysis methodology that supports your project
and product-focused life cycles and will help you to keep the lights on. This book uses a
very simple project lifecycle as the basis for a map. It has only three phases: controlled
start, controlled middle, and controlled end. Most life cycles are far more complex!
Because many of you are planning to use this book in your preparations to take the
CBAP® or CCBA™ certification exams, the content and structure of the exams are covered
here. It takes a lot of work to successfully prepare for and pass these exams — they are
not intended to be easy! The CBAP® exam is designed for experienced business analysts,

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Exam Essentials 25

while the newer CCBA™ exam targets folks who have less experience working as business
analysts. The questions in each exam are built using Bloom’s taxonomy, and they can be
quite straightforward or rather difficult.

Exam Essentials
Be able to list and describe each knowledge area. The names and high-level descriptions
of each of the six knowledge areas are required knowledge for you as you prepare to take
your exam. As you dig deeper into each knowledge area, learn to also list the tasks and
their key inputs/outputs/techniques as part of your exam preparation repertoire. The six
knowledge areas are Business Analysis Planning and Monitoring, Enterprise Analysis,
Elicitation, Requirements Analysis, Requirements Management, and Communication and
Solution Assessment and Validation.
Be able to recognize the underlying competencies every good business analyst should
possess. The six high-level categories are analytical thinking and problem solving
skills, behavioral characteristics such as trustworthiness, business knowledge, software
knowledge, interaction skills, and communication skills.
Be able to describe and relate the requirements classes in the BABOK® Guide. Starting
at the highest level of detail, they are business requirements, stakeholder requirements,
solution requirements, the functional and nonfunctional subsets of the solution
requirements, and the transition requirements.
Be familiar with the key stakeholder roles. The exact role names and defi nitions from
the BABOK® Guide are what you will see in your exam questions, so make sure you know
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

each of them. Remember that the stakeholder roles are like hats, and one person can wear
one or many hats during a project life cycle.
Be able to navigate your copy of the BABOK® Guide. Tabbing your copy of the
BABOK® Guide helps you fi nd exactly what you need to know. You might fi nd it helpful
to use multiple colors of durable tabs to mark the chapters in your book, the glossary, the
index, and any other information that you think will be useful.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 26 Chapter 1 ■
Foundation Concepts

Key Terms
This chapter introduced the knowledge areas from the BABOK® Guide that you will
be using as a business analyst on your projects and other initiatives. You will need to
understand how to apply each of these knowledge areas at the right spot in the project life
cycle in order to be an effective business analyst. Additionally, you will need to know each
knowledge area by name and defi nition in order to be successful on the CBAP® or CCBA™
exams. Each knowledge area will be discussed in greater detail in the chapters to come.
Business Analysis Planning Requirements Analysis
and Monitoring Solution Assessment and Validation
Enterprise Analysis Requirements Management
Elicitation and Communication
You have learned many new key words in this chapter. The IIBA has worked hard
to develop and defi ne standard business analysis terms that can be used across many
industries. Here is a list of some of the key terms that you encountered in this chapter:

business analysis requirements

business analyst solution requirements

business requirements solutions

domain solution scope

elements stakeholder requirements

functional requirements stakeholders

Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

inputs tasks

knowledge areas techniques

nonfunctional requirements transition requirements

outputs underlying competencies

project manager

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Review Questions 27

Review Questions
1. A business analyst is currently defining a set of changes to the current state of an
organization that allows the organization to take advantage of a business opportunity.
What is most likely being defined?
A. Project scope
B. Business need
C. Solution scope
D. Business domain

2. In what knowledge area is the business analyst MOST likely to be scoping and defining
new business opportunities?
A. Enterprise Analysis
B. Solution Assessment
C. Requirements Analysis
D. Enterprise Assessment

3. What project role focuses on understanding business problems and opportunities?

A. Business architect
B. Project manager
C. Project sponsor
D. Business analyst

4. A capability needed by a stakeholder to achieve an objective is also called a:

Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

A. Strategy
B. Requirement
C. Solution
D. Process

5. Your project implementation plan defines 12 capabilities of the planned systems solution
that will not be needed once the new solution is operational. What type of requirements are
these?
A. Functional requirements
B. Nonfunctional requirements
C. Reusable requirements
D. Transition requirements

6. Who is primarily responsible for achieving the project objectives?

A. Program manager
B. Project manager
C. Business analyst
D. Project sponsor
Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 28 Chapter 1 ■
Foundation Concepts

7. Inputs to a specific business analysis task may be externally produced by:

A. Requirements
B. Preconditions
C. Techniques
D. A single task

8. In order to determine solutions to business problems, the business analyst applies a set of:
A. Activities and tasks
B. Inputs and outputs
C. Tasks and techniques
D. Practices and processes

9. Knowledge areas define what a business analyst needs to understand. They do NOT define
the project:
A. Scope
B. Techniques
C. Phases
D. Resources

10. All of the following are part of the business requirements, EXCEPT:
A. Solution scope
B. Business need
C. Required capabilities
D. Business goals
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

11. What knowledge area contains the next MOST logical steps after the business analyst has
built a business case and gained management approval for a project?
A. Solution Assessment and Validation
B. Business Analysis Planning and Monitoring
C. Requirements Management and Communication
D. Requirements Analysis

12. All of the following are knowledge areas EXCEPT:

A. Solution Assessment and Validation
B. Requirements Planning and Monitoring
C. Requirements Management and Communication
D. Enterprise Analysis

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Review Questions 29

13. The business analysis team has put together the elicitation results documenting their
understanding of the user needs. What types of requirements have they developed at this
point in time?
A. Maintained and reusable
B. Communicated and confirmed
C. Validated and confirmed
D. Stated and unconfirmed

14. Identifying key roles and selecting requirements activities is done as part of which
knowledge area?
A. Requirements Analysis
B. Requirements Development
C. Business Analysis Planning and Monitoring
D. Requirements Elicitation

15. Requirements gathering activities are also known as requirements:

A. Planning
B. Development
C. Analysis
D. Elicitation

16. What represents the information and preconditions necessary for a business analysis task
to begin?
A. Activity
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

B. Input
C. Output
D. Technique

17. You are a business analyst measuring alternatives against objectives and identifying
tradeoffs to determine which possible solution is best. You are most likely engaged in
what activity?
A. Problem solving
B. Systems thinking
C. Creative thinking
D. Decision making

18. What defines the business analysis team roles, deliverables to be produced, and tasks to be
performed?
A. Requirements process
B. Project management plan
C. Solution approach
D. Business analysis approach

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 30 Chapter 1 ■
Foundation Concepts

19. When does the business analyst ensure the feasibility of the proposed requirements to
support the business and user needs?
A. As part of building a business case
B. During Requirements Analysis
C. When organizing business requirements
D. While planning and monitoring tasks

20. The system users have stated their needs for revised online order entry system capabilities.
Her team needs the ability to perform online, remote order entry when they are traveling
worldwide. What class or type of requirements best describe this need?
A. Functional requirements
B. Business requirements
C. User requirements
D. Transition requirements
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 Answers to Review Questions 31

Answers to Review Questions

1. C. A solution is a set of changes to the current state of an organization made in order to
enable the organization to meet a business need, solve a problem, or take advantage of
an opportunity. It is the basis for the project scope that implements the solution and its
components.

2. A. Enterprise Analysis contains pre-project or early project activities such as assessing

feasibility and building a business case for a potential business initiative.

3. D. The business analyst is responsible for understanding the business problems and
opportunities in the context of the requirements.

4. B. One defi nition for a requirement is a condition or capability needed by a stakeholder to

either solve a problem or to achieve an objective.

5. D. Transition requirements describe capabilities that a solution must have to facilitate

transitioning from the current to the desired future state. They are not needed once
the transition is complete and cannot be created until both the current and new solutions
have been defi ned.

6. B. The project manager has primary responsibility for achieving the project objectives.

7. D. Inputs represent information and preconditions necessary for a task to begin. They are
produced externally by a single task.

8. C. Business analysis is a set of tasks and techniques used to identify business needs and
determine solutions to business problems.

9. C. Knowledge areas defi ne what a business analyst needs to understand and the tasks they
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

need to perform. They do not defi ne a methodology or indicate project phases as tasks may
be done in any order as long as their inputs are available.

10. D. The deliverables produced by the Enterprise Analysis tasks that make up the business
requirements include the business need, the required capabilities, the solution scope, and
the business case.

11. B. Building a business case is typically done as part of Enterprise Analysis activities. The
next most logical knowledge area applied after Enterprise Analysis is completed would be
Business Analysis Planning and Monitoring where requirements-related resources and tasks
are defi ned.

12. B. Requirements Planning and Monitoring is not a knowledge area. The six knowledge
areas are Business Analysis Planning and Monitoring, Enterprise Analysis, Elicitation,
Requirements Analysis, Solution Assessment and Validation, and Requirements Management
and Communication.

13. D. The stated, unconfi rmed requirements represent the business analyst’s understanding of
the user needs or intentions.

14. C. Business Analysis Planning and Monitoring defi nes requirement-related resources and
tasks throughout the requirements development process.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.
 32 Chapter 1 ■
Foundation Concepts

15. D. Requirements gathering or requirements collecting activities are also known as

requirements elicitation.

16. B. Inputs are the information and preconditions necessary for a business analysis task to
begin. They may be generated outside of the scope of business analysis or generated by a
business analysis task.

17. A. Problem solving involves measuring alternatives against objectives and identifying
tradeoffs to determine which possible solution is best.

18. D. The business analysis approach defi nes the methodology used for business analysis
work on the overall project and each of its phases. It includes team roles, deliverables to be
produced, how and when tasks are performed, techniques to be used, and other aspects of
the high-level business analysis process.

19. B. The business analyst is responsible for ensuring the feasibility of proposed requirements
when defi ning, describing, and refi ning the characteristics of an acceptable solution as part
of Requirements Analysis activities.

20. A. Stakeholder requirements are statements of stakeholder needs, describing how that
stakeholder will interact with a solution. This need from a class of users is best described
as a stakeholder requirement. Solution requirements could also be a correct answer to this
question, although they were not one of the potential answers provided.
Copyright © 2011. John Wiley & Sons, Incorporated. All rights reserved.

Weese, S., & Wagner, T. (2011). Cbap / ccba : Certified business analysis. John Wiley & Sons, Incorporated.
Created from uql on 2024-01-03 09:26:50.