Business Analysis - How To Gather and Document User Requirements

Copyright ESI International
April 2009
All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted,
in any form or by any means, electronic, mechanical, photocopying, recording, or
otherwise, without the prior written permission of ESI International.
ESI grants federal government users "Restricted Rights" (as the term is defined in FAR
52.227-14 and DFARS 252.227-7013). Use, reproduction, or disclosure of these materials is
subject to the restrictions set forth in the MOBIS, FSS, or contract under which the materials
were provided.
All material from A Guide to the Project Management Body of Knowledge (PMBOK
Guide)
is reprinted with permission of the Project Management Institute, Four Campus Boulevard,
Newtown Square, Pennsylvania 19073-3299, USA, a worldwide organization of advancing
the state-of-the-art in project management. Phone: (610)356-4600, Fax: (610)356-4647.
PMI
did not participate in the development of this publication and has not reviewed the
content for accuracy. PMI
does not endorse or otherwise sponsor this publication and

makes no warranty, guarantee, or representation, expressed or implied, as to its accuracy or
content. PMI
does not have any financial interest in this publication and has not
contributed any financial resources.
The names of all companies and characters used in these materials are purely fictional. Any
resemblance to any existing or no longer existing company or living or dead person is not
intended, and is purely coincidental.
PMI is a service and trademark of the Project Management Institute, Inc., which is
registered in the United States and other nations.
PMBOK is a trademark of the Project Management Institute, Inc., which is registered in the
United States and other nations.
PMP

is a certification mark of the Project Management Institute, Inc., which is registered in
the United States and other nations.

State Council of Higher Education for Virginia (SCHEV) has certified this institution to
operate in Virginia.

ESI International
Arlington, VA USA
Copyright 2009 by ESI International, Inc. iii
CONTENTS
Page
Chapter 1: Introduction to Requirements Elicitation.............................................. 1
Reference Material................................................................................... 1
Positioning Business Analysis................................................................... 2
The Requirements Elicitation Process ....................................................... 7
Requirements........................................................................................... 9
The Key Requirements Documents ........................................................ 15
Chapter Summary .................................................................................. 19
How to Gather and Document User Requirements: Next-Steps
Action Plan...................................................................................... 20
Action Plan............................................................................................ 21
Chapter 2: Establishing Vision, Scope, and Quality .............................................. 23
Reference Material................................................................................. 23
Eliciting Solution Vision......................................................................... 24
Defining Solution Scope ........................................................................ 29
Ensuring Solution Quality ...................................................................... 32
Validating Vision and Scope .................................................................. 35
Chapter Summary .................................................................................. 37
Action Plan...................................................................................... 38
Action Plan............................................................................................ 39
Chapter 3: Modeling at the Enterprise Level ........................................................ 41
The Function of Modeling in Business Analysis ...................................... 42
Business Rules ....................................................................................... 44
Modeling Techniques ............................................................................ 48
Organization Models ............................................................................. 49
Strategy Models ..................................................................................... 51
Process Models...................................................................................... 53
Information Models ............................................................................... 61
The Business Analysts Toolkit ............................................................... 63
Chapter Summary .................................................................................. 65
Action Plan...................................................................................... 66
Action Plan............................................................................................ 67
Chapter 4: Developing the Requirements Work Plan ........................................... 69
Overview of the RWP............................................................................ 70
Elements of the RWP ............................................................................. 71
Identifying Business Analysis Tasks ........................................................ 75
Encouraging User Involvement .............................................................. 79
CONTENTS
Page
Copyright 2009 by ESI International, Inc. iv
Profiling Users ....................................................................................... 82
Managing Risk ....................................................................................... 86
Chapter Summary .................................................................................. 89
Action Plan...................................................................................... 90
Action Plan............................................................................................ 91
Chapter 5: Requirements Elicitation..................................................................... 93
Overview of Requirements Elicitation .................................................... 94
Elicitation and Validation Techniques .................................................... 99
Reviewing the AS-IS............................................................................. 101
Survey Techniques............................................................................... 105
Facilitated Techniques ......................................................................... 113
Product-Based Techniques ................................................................... 119
Chapter Summary ................................................................................ 122
Action Plan.................................................................................... 123
Action Plan.......................................................................................... 124
Chapter 6: Developing the Business Requirements Document ........................... 126
Reference Material............................................................................... 126
What Is the BRD?................................................................................. 127
A Note About Technical Writing.......................................................... 137
Analyzing Requirements ...................................................................... 148
Documenting Requirements................................................................. 151
Chapter Summary ................................................................................ 162
Action Plan.................................................................................... 163
Action Plan.......................................................................................... 164
Chapter 7: Validating Requirements................................................................... 166
Reference Material............................................................................... 166
Checking the BRD............................................................................... 167
Building Consensus ............................................................................. 174
Approval and Change Management ..................................................... 184
Chapter Summary ................................................................................ 186
Action Plan.................................................................................... 187
Action Plan.......................................................................................... 188
ESI 1
Introduction to Requirements Elicitation
Reference Material
Business analysis is an important step in the development of business
solutions. It involves the investigation of a business problem (root cause
analysis) or opportunity, the systematic analysis and documentation of
the requirements that a solution must satisfy (requirements elicitation),
and support throughout solution development, testing, and
implementation to ensure the requirements are met (requirements
management).
This course focuses specifically on the requirements elicitation and
documentation processes in business analysis. While the processes and
techniques presented are often thought of in terms of systems or software
development, they are applicable to process improvement and solution
development efforts in general.
Chapter Overview
1

ESI 2
Introduction to Requirements Elicitation
Positioning Business Analysis
Various studies over the last decade have shown that most technology
projects fail in some way, from total abandonment of the project to cost
overruns, schedule slippage, and missing features. Numerous IT
professionals report at least one IT project that either failed or suffered
from cost or time overruns or missing features.
The most common reasons cited for project failure are
A lack of user involvement in design and development
Poorly defined or incomplete requirements
Changing requirements and specifications
Other frequently cited reasons for project failure are
Requirements that do not map to business goals
A lack of management support
Scope creep and poor change management
A failure to understand project complexity
Unrealistic expectations, requirements, or timelines
A lack of resources
Poor risk planning
A failure to align the solution to the business environment or
culture
Business analysis helps set the stage for successful project completion by
managing expectations and risk and providing a clear, complete picture
of solution requirements from the outset. By preventing errors during the
Analysis phase, the business analyst (BA) eliminates costly rework later
on in the project. Without this initial work, no amount of competent
project management can overcome the resulting problems stemming
from incomplete or misunderstood requirements, scope creep, and poor
understanding of project goals and complexity.
What Makes Projects
Fail?
4 1

ESI 3
Positioning Business Analysis (continued)
The BAs involvement in a project may begin with a small work request
to investigate an operational problem. The BA needs to link the
operational problem to a business opportunity that affects customers,
cost, or compliance. This helps ensure that any business process
improvements resulting from the investigation are worth the investment.
Depending on the business impact, the investigation may remain a small
work request, or it may lead to the initiation of a project.
The PMBOK
Guide

defines a project as a temporary endeavor
undertaken to create a unique product, service, or result.
1
A project
manager (PM) is the person assigned by the performing organization to
achieve the project objectives.
2

Ideally, both the PM and BA will be involved throughout the project life
cycle with clearly defined roles. The PM and the BA support each other,
with the PM responsible for orchestrating the project as a whole and the
BA responsible for ensuring that requirements clearly reflect the business
need and remain mapped to business goals. The table below illustrates
some of the differences between the two roles.
Business Analyst Project Manager
Defines solution scope
Models business (AS-IS)
Develops requirements
work plan (RWP)
Develops business
requirements document
(BRD)
Models requirements
(TO-BE)
Validates requirements
Manages requirements
Supports testing
Defines project scope
Forms project team
Estimates resources
Develops project plan
Coordinates project
Manages project constraints
Reviews and accepts
project
Performs project closeout
Captures lessons learned

PMBOK is a trademark of the Project Management Institute, Inc., which is
registered in the United States and other nations.
1
PMBOK
Guide, p. 434
2
PMBOK
Guide, p. 436
A Note on Project
Management

ESI 4
The project constraints, which represent the scope, cost, time, risk,
quality, and resources on a project, are a key aspect of project
management and are depicted as interrelated in the below graphic,
because each facet is critical and related to the others. In fact, changing
one almost inevitably changes the others.

What is meant by each facet or factor of the project constraints?
Scope: as defined in the PMBOK
Guide, p. 440, is the sum of

the products, services, and results to be provided as a project.
More specifically, project scope is the work that must be
performed to deliver a product, service, or result with the
specified features and functions (PMBOK
Guide, p. 436). In
other words, project scope is all the work that must be completed
for the project.
Budget/cost: the approved estimate for the project to any work
breakdown structure component or any schedule activity.
(PMBOK
Guide, p. 420)
Project Schedule/time: the planned dates for performing schedule
activities and the planned dates for meeting schedule milestones.
(PMBOK
Guide, p. 436)
The Project
Constraints

ESI 5

Risk: an uncertain event or condition that, if it occurs, has a
positive or negative effect on the projects objectives. (PMBOK

Guide, p. 438)
Quality: the degree to which a set of inherent characteristics
fulfills requirements. (PMBOK
Guide , p. 437)
Resources: skilled human resource, equipment, services,
supplies, commodities materials, budgets or funds. (PMBOK

Guide, p. 438)
What then is the constraint? The constraint is how each factor affects
the others. For example, if a decision is made to speed up the schedule
and complete a project earlier than originally planned, it will have
repercussions. It may require the assignment of more resources or a
reduction in the scope of the project lessening the quality. If project
managers can make their managers and clients understand the project
constraints, they will avert or solve many potential problems!
The classic example of compromise to keep the project constraints
balanced arises when the project schedule must be accelerated. If a
project manager develops a reasonable schedule to complete a project
within two months but is required to finish in half the time, one of three
things will happen: The project will either cost more because it will
require added or more costly resources to complete on time; the end
products scope or quality will suffer; risk increases regardless, or some
combination of both consequences will occur.
The requirements elicitation process takes place during the Analysis
phase of the project.

The above life cycle is a generic development version. Different
organizations may have different numbers of phases or different
identifiers. The important thing to remember is that requirements
elicitation occurs in the beginning of the life cycle and lays the
foundation for design, testing, and acceptance.
The Project
Constraints
(continued)
Business Analysis and
the Project Life Cycle

ESI 6
All business analysis deliverables and requirements should have the
following five quality attributes. They should be
Visible. Business analysis mandates the formal documentation of
all requirements. Nothing should remain hidden or left to verbal
agreement.
Specific. All requirements and deliverables must be described in
enough detail that they can be differentiated from related
requirements and deliverables.
Traceable. Traceability ensures forward and backward mapping
of project deliverables from the various level of requirements
through their system specifications and shows how the different
levels relate to each other and to business goals.
Accountable. Business analysis mandates that all requirements
documentation be approved by the business sponsor, who
represents the aggregate needs of the users and has authority
(delegated by the project sponsor) to sign on their behalf.
Measurable. Although users may begin by describing
requirements in qualitative language, the BA must work with
them to elicit and define quantifiable measurements of
requirements success. Only then can the project team develop
appropriate quality standards to ensure that requirements are
understood and testable.
Depending on the project, many participants may be involved in
requirements elicitation. Some of the most common participants are
Customers. A customer requests and accepts the product, system,
or service. The customer (or someone the customer reports to) is
usually the project sponsor. This means the project sponsor often
funds the project. The project sponsor has a managerial (as
opposed to a day-to-day) view of the solution.
End users. As the name suggests, end users are people who will
use, operate, and maintain the new product, system, or service.
These individuals need the product, system, or service to perform
their jobs. End users can have a significant voice in the overall
corporate acceptance of the solution after it is implemented.
Business analysts. Business analysts develop business
requirements based on feedback from customers and end users
and may report to either a business or technical manager.
Business Analysis
Quality Attributes
Participants in
Requirements
Elicitation

ESI 7

Systems analysts. Systems analysts use requirements
documentation to identify technical specifications so that
developers can build the technology to accommodate business
needs. Systems analysts may also play a support role in helping
the business analyst elicit functional and nonfunctional
requirements necessary to support user requirements.
Testers. Testers execute test scenarios to prove that the product,
system, or service meets or conforms to requirements. Testers are
a great resource for reviewing requirements to ensure that they
can be measured. The project needs testers from both the
business and technical areas to test the solution effectively.
Business sponsor. The business sponsor, often called the project
sponsor, signs off on the project and its deliverables. The business
sponsor may delegate acceptance authority to another individual,
known as the client acceptor. The project must have a single
point of approval.
Other project participant responsibilities may include regulatory, legal, or
auditing roles. In addition, business owners, technology vendors,
developers, operations support, and technical or end-user trainers may
participate in identifying solution requirements. All participants have
their own ideas and objectives concerning project requirements, and it is
up to the BA to elicit, analyze, and structure the information to best
facilitate meeting business goals.
The Requirements Elicitation Process
The primary focus of business analysis is requirements elicitation and
documentation. The requirements elicitation process can be illustrated as
four activity streams interwoven with four underlying themes.
The underlying themeselicit, structure, document, validateare the
four basic steps repeated throughout the iterative activity streams. The
process is more than just listening to people and writing down what they
say. The BA elicits information through interviews, meetings, and other
activities; analyzes and structures the information gathered; documents
what was learned; and validates conclusions through continuous user
involvement and feedback on the documentation produced.
Participants in
Requirements
Elicitation
(continued)
Overview

ESI 8
The Requirements Elicitation Process (continued)
The requirements elicitation process can be illustrated as four activity
streams interwoven with four underlying themes. Although the following
chart shows a sequential process, in practice the activities can overlap
considerably, especially since the BA typically uses an iterative approach
to requirements elicitation and documentation.

The first activity stream traces the development of the vision and scope
report, which defines, at a high level, what the organization hopes to
accomplish and sets the boundaries for the requirements elicitation. The
second activity stream traces the development of the requirements work
plan (RWP), outlining the schedule, cost, and resources necessary for the
Analysis phase. The third activity stream shows the requirements
elicitation itself, involving various elicitation techniques, as well as
business and process modeling to show both current and future states.
Finally, the fourth activity stream traces the development of the business
requirements document (BRD), which provides an elaboration of the
requirements, including priorities, mapping to business goals, and
profiles of user communities.
Documenting in
Stages

ESI 9
The Requirements Elicitation Process (continued)
Note: The goal is for the BRD to be comprehensive. However, in reality,
the BA strives for excellence based on the requirements work plan
approved by the business sponsor. Excellence means that the BA does
the best analysis in the amount of time and cost set.
Having a formal documentation strategy guides the requirements
elicitation process and ensures the capture of adequate information for
validating and supporting requirements. Although it requires more
up-front time and effort than ad hoc approaches, the overall project is
compensated with less time and expense due to rework. A formal
documentation strategy
Sets expectations for all concerned as analysis gradually uncovers
requirements
Structures the approach to complex solution environments, with
predefined review, feedback, elaboration, and approval points
Provides communication, planning, and negotiation tools used
throughout the requirements elicitation process
Having such a formal documentation strategy, or any rigid process for
that matter, may seem counterintuitive in rapid development
environments, but the need for parties to develop a common
understanding and prepare a set of written requirements (which may be
in the form of code) still exists. The documentation simply happens at an
accelerated pace.
Requirements
A basic definition of requirement is a documented representation of a
condition or capability
[N]eeded by a stakeholder to solve a problem or achieve an
objective
[T]hat must be met or possessed by a solution or solution
component to satisfy a contract, standard, specification, or other
formally imposed documents. (BABOK
, p. 230)
Documenting in
Stages (continued)
The Importance of a
Documentation
Strategy
Requirements Versus
Specifications

ESI 10
Requirements (continued)
In contrast, a specification details how the condition or capability will be
met, providing design criteria such as prescribed materials or dimensions.
The difference between requirements and specifications is that
requirements define the functions and characteristics of the solution and
specifications define the method (design) used to provide the solution.
The BA is responsible for requirements, and the systems analyst or
solution team is responsible for specifications. The table below explains
the difference between requirements and specifications:
Requirement Specification
Answers who, what, where, when,
how often, and how much is
needed to solve the problem (or
pursue the opportunity)
Answers how we will solve the
problem (or pursue the
opportunity)
Describes performance; no
mention of possible technology
Describes technical solution
Concerned with processes and
behavior
Concerned with physical
architecture and infrastructure
Example:
An integrated administrative system
to track student enrollments
Example:
A three-tier Web solution using
ASP
over an Oracle
back end

Throughout the requirements elicitation process, the BA must identify
and monitor assumptions, constraints, and dependencies. Any of the
three can have a significant effect on project success. (For example,
careless assumptions can both create constraints and cause the BA to
miss constraints that might otherwise be obvious.)
The BA must identify and document assumptions pertaining to the
analysis. An assumption is a factor that is considered to be true, real, or
certain and is often used as a basis for decision making (Ward, p.24).
Requirements Versus
Specifications
(continued)
Assumptions,
Constraints,
Dependencies

ESI 11
Assumptions include, but are not limited to, the following:
Priority of the project relative to other projects
Business and system environment within which the solution will
live
Human resources expertise before, during, and following
implementation of the solution (which leads to a training plan)
Constraints are limits that may be imposed on the solution. When the
constraint is deemed necessary, then the constraint becomes a
requirement. The BA needs to investigate each constraint to understand
the limits it imposes and whether it is truly necessary.
Some typical project constraints that limit solution options include
Existing or planned technology infrastructure
New technology that will become available during the project life
cycle
Cost
Hard costs, including budget
Soft costs, including opportunity cost
Schedule
Resource availability and competency levels
Business pressures
Strategic, tactical, operational direction
Politics
Regulation and policy
Market pressures
Dependencies are relationships among projects and project-related
factors that could affect project success. Dependencies may be external
(outside the control of the team or organization) as well as internal.
Some typical sources of dependencies include
Government actions
Weather
Performance of others, such as subcontractors
Related projects
Limitations on resources
Assumptions,
Constraints,
Dependencies
(continued)

ESI 12
Typically, as part of the requirements elicitation process, the BA captures
various levels of requirements. Part of the BA role involves linking
requirements and ensuring they are traceable, while resolving conflicts
and ensuring that project stakeholders understand the requirements
themselves as well as the relationships among the various requirements.
Requirements must be mapped to both business needs and the resulting
deliverables. All requirements must be linked from the lowest level
(resulting deliverable) up to the top level (business need) to ensure a
strong business case. Lack of clear, explicit links results in a weak
business case, which in turn makes it more difficult to obtain funding,
resources, and commitment for the project.
At minimum, the BAs requirements documentation should capture
where each requirement came from (who suggested it and why), how
each supports business goals, what level each is (and how it relates to the
levels above and below), and how requirement success will be
measured. In other words, the requirements should be visible, specific,
traceable, accountable, and measurable.
Four levels of requirements (with several subdivisions within levels) feed
into the final specifications.
Level of
Requirement
Requirements Source Elicited By
Regulatory Internal or external legal or
governing body
Business:
Strategic
Senior management
Business:
Tactical
Middle management
Business:
Operational
First-line management
User Users
Business Analyst
Solution Users Business Analyst/
Systems Analyst
Requirement
Traceability
From Requirements
to Specifications

ESI 13

For example, the case of an ATM illustrates a wide range of requirements
answering questions, such as
Why do banks use these systems?
What high-level business requirements do they satisfy?
What are some of the physical features of ATMs?
What kinds of functions do they perform for users?
ATM regulatory requirement: All ATMs must comply with the banking
regulations of the resident state or political entity.
Regulatory requirements originate from the federal government, banking
industry standards and practices organizations, or internal regulations
within the individual banks. They are usually incorporated by reference,
noting the version and paragraph number of the regulatory document.
ATM business strategic requirement: By providing superior service to
our retail customers, Monumental Banks ATM network will increase
associated service fee revenue by 10% per annum on an ongoing basis.
The strategic requirement focuses on the long-term, strategic goals of the
organization. It is measurable, but still a very high-level, strategic
statement.
ATM business tactical requirement: Monumental Bank ATMs must allow
seamless interoperability for all functions provided by BANK 3000,
allowing our retail customers who have accounts with both banks to use
our ATMs as if they were using a BANK 3000 ATM.
Tactical requirements focus on the needs of middle management and
interoperability among internal and external systems. Many projects
begin as tactical responses to strategic goals.
ATM business operational requirement: ATM-based account transaction
updates must occur in real time for all accounts.
From Requirements
to Specifications
(continued)

ESI 14
Operational requirements focus on the needs of operational management
with regard to staff and system activity. They address issues with the
everyday operations of the organization.
ATM user requirement: Users must be able to deposit funds into their
accounts.
User requirements focus on the experience users need to have with the
system, with no concern for the inner workings of the system. These
requirements are tied to benefits and/or risk mitigation at the job level.
They may still be high level and form the basis for functional and/or
nonfunctional requirements.
ATM solution requirement: The solution must provide the ability to
withdraw funds from a personal account.
Solution requirements describe the technology-independent behaviors
and information needed by the solution to support the user requirements.
There are three basic types of solution requirementsfunctional
requirements, nonfunctional requirements, and transition requirements.
From Requirements
to Specifications
(continued)

ESI 15

Type of
Solution
Requirement
Definition Example
Functional The product capabilities, or
things the product must do for its
users. (BABOK
, p.227)
The solution must
allow users to
check their
account balance
prior to
withdrawing
funds.
Nonfunctional
(quality of
service)
The quality attributes, design
and implementation constraints,
and external interfaces that the
product must have. (BABOK
, p.
228)
The transaction
must take place
from login to cash
in less than one
minute.
Transition A classification of requirements
that describe capabilities that the
solution must have in order to
facilitate transition from the
current state of the enterprise to
the desired future state, but that
will not be needed once that
transition is complete. (BABOK
,
p. 234)
Existing automated
teller machines
(ATMs) must
continue to
operate while the
new ATM network
is being
implemented.
The Key Requirements Documents
This section provides an overview of the key documents necessary to
manage project requirements. The BA serves in the appropriate lead or
support role in the creation of each, resulting in a suite of requirements
elaboration documents. Requirements cannot be captured in one
attempt, in one place. Elicitation is an iterative discovery process, with
each of the documents building on the one before it as analysis proceeds
from the known to the unknown, from high level to low level. The
individual documents provide checks and balances against each other,
aiding in the validation process and ensuring traceability throughout the
process.
From Requirements
to Specifications
(continued)
Documenting the
Process

ESI 16
The Key Requirements Documents (continued)
These documents represent key milestones in the elicitation, structuring,
documentation, and validation of requirements. Different organizations
may
Use different names for the same documents
Build the documentation set in a different order
Combine documents
Have additional documents
In reviewing the key documents, focus on the purpose of the individual
documents, not their titles. Focus areas for the BA are shaded in the
following table.
Document BA Role Description
Project charter Contributor
Created during project initiation, under
the direction of the business sponsor
Provides formal, high-level scope
definition and project deliverable
accountability
Empowers the project team to act on
behalf of the business sponsor
Vision and scope
report
3

Lead or
contributor
Defines opportunity and scope with
volumetric values
Enumerates high-level benefits and
risks to the organization
Provides general cost estimates
May offer possible solution approaches
(buy/build)
May be authored by the BA or PM
through high-level discussion with key
stakeholders (a common mistake is not
to involve the BA or PM)
Begins the requirements elicitation
process with the business sponsor and
key stakeholders

3
The vision and scope report may also be known as an opportunity analysis,
feasibility study, project initiation report, or project definition report.
The Key Documents

ESI 17

Business case Contributor
Is a concise and focused overview of
project scope, benefits, risks, costs, and
recommended solution
Created by a team of contributors
including the PM, BA, financial analyst,
business sponsor, and key stakeholders
Seeks formal investment funding
approval from executive committee or
investment planners
Tied to quantified projected profits,
cost savings, and revenue streams over
time
May be done twice: as an initial
business case (following vision and
scope definition) and as a final business
case (more detailed, following BRD
approval)
RWP Lead
Is a mini project plan focusing solely
on the scope, cost, and schedule of the
Analysis phase (requirements
elicitation) of the project
Created by the BA
May become a component of the
overall project plan
Must be completed and approved
before any requirements analysis work
begins because analysis consumes
project resources, budget, and time
The Key Documents
(continued)

ESI 18

BRD Lead
Is an elaboration of the regulatory,
business, user, and system (functional,
nonfunctional, and implementation)
requirements
Created by the BA and handed off to
the systems analyst following formal
review and approval by the business
sponsor
Provides insights into the current (AS-
IS) and future (TO-BE) states of the
organization
Includes detailed profiles of user
communities
Provides a baseline for requirements
management throughout the project
life cycle
Vendor request
documents
Contributor
Collectively called RF(x); includes
request for information (RFI), request
for proposal (RFP), and request for
quotation (RFQ)
Prepared by the PM with support from
the project team
May incorporate the BRD as part of its
terms in the RFP
Business contract
documents
Contributor
Is legally binding, documented
commitment between the solution
provider (internal or external) and
funding organization
Is completely dependent on successful
requirements elicitation and
documentation
May include professional services
agreement, statement of work, end-user
license agreement
The Key Documents
(continued)

ESI 19
Chapter Summary
Poorly defined or incomplete requirements are a major
cause of failed projects.
Requirements elicitation takes place during the Analysis
phase of the project life cycle.
The business analyst is responsible for solution scope, and
the project manager is responsible for project scope.
The requirements elicitation process comprises four activity
streams: vision and scope definition, requirements
planning, requirements elicitation, and requirements
documentation.
During the requirements elicitation process, the BA collects
and categorizes various
Levels of requirements including regulatory
requirements, business requirements (strategic, tactical,
and operational), user requirements, and solution
requirements
Types of requirements including functional,
nonfunctional, and transition requirements
Requirements describe the functions and characteristics of
the solution, whereas specifications describe the method
(design) used to provide the solution.
The business analyst needs to establish a formal
documentation strategy and a set of documents that
provides checks and balances to aid validation and ensure
traceability.
The business analysts primary deliverables in the
requirements elicitation process are the vision and scope
report, requirements work plan, and business requirements
document.

ESI 20
How to Gather and Document User
Requirements:
Next-Steps Action Plan
The following worksheet is designed to help you begin prioritizing what
you want or need to do when you return to your organization and to
develop a realistic timeline. Take a few minutes to think about and
review what you have learned from the course and how you will apply
the principles learned when you return to your organization. Then
document your next steps on the Action Plan.
1. Read the Questions to Consider to start thinking about actions
you can take to improve your organizations processes.
2. Develop a list of at least five actions in each area that you will
complete when you return to work.
3. Next, identify who you need to involve for each item you have
listed.
4. Finally, identify the appropriate time frame for accomplishing
each of these steps. For items you know will be ongoing, identify
milestones for each period (3, 6, 9, and 12 months and over).
Next-Steps Action
Plan

ESI 21
How to Gather and Document User Requirements Chapter 1: Introduction to Requirements Elicitation

Action Plan:
Apply what you have learned about requirements elicitation by developing a list of actions you will complete when you return to your
organization.
Questions
to Consider:
How can business analysts work with project managers in my organization to ensure project success?
How do I differentiate between the different levels and types of requirements?

Time
What do I want/need to do next? Who 3 months 6 months 9 months 12+ months
1.

2.

ESI 22
Time
3.

4.

5.

ESI 23
Establishing Vision, Scope, and Quality
Reference Material
The vision and scope report is the first important deliverable in the
requirements elicitation process. Capturing solution vision and scope is a
critical step in the requirements process that provides stakeholders and
the project team with a high-level description of the proposed solution
for which the BA will gather requirements and that defines the
boundaries of the proposed solution. Although the vision and scope
report looks at the business problem or opportunity from a high
(conceptual) level, the report still needs to include quantified process
improvement targets, which are the foundation for the quality standards
against which the project deliverables will be measured.
Note: In this chapter, whether a business problem exists or a new
business venture is identified, the term opportunity is used to describe
both situations to reflect the positive nature of the vision.
Chapter Overview
2

ESI 24
Establishing Scope, Vision, and Quality
Eliciting Solution Vision
The vision and scope report clarifies the business opportunity that the
solution must address for stakeholders and the project team by providing
a high-level view of the
Business goalsidentifying the business opportunities that were
the catalyst for the current project or investigation
Solution visiona shared and clearly articulated description of
the proposed solution to the business opportunity
Solution scopedefining the boundaries of the proposed solution
At the enterprise (or organizational) level, mission statements often are
used to identify
Who the organization is
The goods and/or services it provides
Its customers, suppliers, and business partners
Its industry, market niche, and geographical boundaries
In contrast, enterprise vision statements deal with the TO-BE, or future
state, of the organization. Enterprise vision statements define where the
organization would like to be 5, 10, or 20 years from today without
regard for technology, timing, budget, or other constraints.
The mission describes the fundamental purpose for an organizations
existence; the vision describes where the organization is going.
For example--
Mission:
Monumental Bank provides the highest level of customer service and
most advanced business and personal financial solutions through
knowledgeable team members, efficient teamwork, and technological
advancements while striving for innovative and creative ways to improve
our procedures and products.
Mission Versus
Vision: The AS-IS and
the TO-BE
4 2

ESI 25
Eliciting Solution Vision (continued)

Vision:
Monumental Bank will invest in its culture of continuous improvement in
people, processes, and systems with the goal of becoming the leading
financial services supplier for personal and business banking in North
America, as measured by the annual Financial Services Customer
Satisfaction Index, by December 31, 2012.
In conjunction with this, we will realize a net market share increase of 30
percent and a net profit increase of 20 percent compounded annually.
This strategic goal will encompass wide-ranging tactical initiatives under
the umbrella name Summit Seven, or S7.

In contrast with an enterprise vision statement, which describes where
the organization will be in 5 to 20 years, the solution vision statement
describes the desired state of the affected business areas once the project
is complete. The solution vision needs to
Address the business opportunity
Provide an unbounded view of the possible solution
Map to business goals
Balance competing interests to provide a shared vision backed by
stakeholder consensus
Be captured in the vision and scope report
Be only one or two paragraphs in length
While the BA is not responsible for developing the solution for the
opportunity, the BA may be responsible for documenting the solution in
the vision and scope report. In addition, the BA can offer significant
contributions to the visioning process by
Organizing vision workshops
Clarifying, organizing, and prioritizing ideas
Validating vision statements and solution features
Resolving conflicts and building consensus
Mission Versus
Vision: The AS-IS and
the TO-BE
(continued)
Solution Vision
Capturing Solution
Vision

ESI 26
Capturing the solution vision is a creative process involving a
collaborative effort among stakeholders to define the high-level
(conceptual) solution that will best address the opportunity while
furthering business goals. The process is an excellent way to obtain
executive support for the project and build a sense of collective
ownership, enthusiasm, and mutual understanding. It includes, at
minimum, the
Project sponsors
User representatives
Technical representatives
Project manager
Business analyst
Just as requirements are captured at different levels and types, depending
on the source, vision statements also reflect their source. For example
Strategic
Management Level
As an S7 initiative, the S7-ATM enhancement
project will provide innovative, new, and enhanced
functionality to our ATM worldwide network by
1. Auditing and enhancing all existing ATM
functionality to provide clear and
demonstrable advantages to our ATM
customers compared with similar services
from our competitors
2. Doubling the total number of service
offerings through new local and interbank
functions
The success of the S7-ATM will be measured
against the goal of increased ATM-based market
share of 10 percent in the first year of operation and
3 percent every year thereafter until fiscal year-end
2012.
Capturing Solution
Vision (continued)

ESI 27

Tactical Management
Level
The S7-ATM project will facilitate increased
enterprise-wide knowledge management and
decision support across all areas of Monumental
Bank related to personal and business account
management.
It will fully integrate with existing and planned data
flow among our Investment Planning, Financial
Services, and Marketing applications.
Existing reporting functionality will be consolidated
from our current three separate ATM network
applications.
Operational
Management Level
The S7-ATM project will create increased
efficiencies and quality control for all ATM-related
operations. The standards for measuring the first
year of operation enhancements are as follows:
1. Branch personnel: Full-time recovery (FTE)
reductions of 25 percent related to daily
ATM maintenance and service, to be
accomplished through increased
automation of system start-up, self-
diagnosis, repair, and backup procedures.
FTE recovery will allow for redeployment of
existing administrative personnel into more
advanced ATM knowledge worker positions
to be determined.
2. Quality: System availability to be increased
to 96 percent within the first six months of
operations and 98 percent thereafter, with
associated reductions in service costs.
Capturing Solution
Vision (continued)

ESI 28

User Level The S7-ATM project will provide ATM bank
personnel with the following benefits:
1. Web-based graphical user interface (GUI)
portal interface to the branch and head
office ATM administrative and support
network, tailored to the needs of the ATM
administrator, ATM technical
representative, and ATM help desk
consultant
2. Enhanced communications among these
positions for situation identification,
analysis, and resolution through instant
messaging, live voice link, and real-time
incident report collaborative editing
Each category of participants in the process has a different perspective
about the solution. The BAs job is to refine each level by steering away
from specifications, encouraging a future vision, and eliciting quantitative
information that ultimately allows the development of quality standards
against which the solution is measured. Remember that the BA must
define precisely what needs to be accomplished in the elicitation, leaving
the technical team maximum room for creativity in solution design.
Following the visioning process, the BA must analyze the results to look
for potential problems and evaluate each statement collected. Consider
the following questions:
Does the solution vision map back to business goals?
Does the solution vision have any conflicting statements?
Do the stakeholders share a common understanding of the vision?
The BA must be sure to clarify any unclear or conflicting statements,
unspecific or immeasurable features, and abstract or intangible benefits.
Only then is the vision ready to be documented and passed on for
acceptance and approval.
Capturing Solution
Vision (continued)
Validating the Vision

ESI 29
Defining Solution Scope
Once the BA and project team capture the solution vision, the next step
is to define the solution scope. Solution scope places boundaries around
the solution by clearly delineating what project stakeholders expect the
solution to do and not do.
In contrast, project scope defines what work the project team will and
will not perform over the course of the project. Project scope applies to
the entire project and is the responsibility of the PM; solution scope
applies only to the requirements of the solution itself and is the
responsibility of the BA.
Defining the solution scope is one of the most important early steps in
requirements elicitation because planning for everything else, including
project costs, resources, risks, and so on, depends on it. It drives the
other planning processes and thus, the project itself. If the BA does not
clearly define solution vision and scope, not only will the BA be unable
to accurately plan the requirements elicitation process and manage
customer expectations, the PM and the project team will be unable to
accurately plan the time and costs involved for the project scope.
Do not make assumptions about what is included in solution scope.
Remember you are eliciting requirements, not determining them. When
you assume something is included, it may not be. When you assume
something is excluded, it may be in scope in the mind of the customer.
Because including every feature imaginable in the solution is almost
never possible, defining scope becomes a natural follow-on process to
visioning. In scoping, the BA, stakeholders, and project team make trade-
offs to determine what features to include in the solution based on
priority, effort, and resource considerations. Note that a feature is a high-
level (conceptual) requirement that will be further defined into detailed
requirements during the analysis.
Once the ideas captured during visioning have been organized into
logical categories, the BA, stakeholders, and project team must decide
what is in scope and what is out of scope. For example, the team may
decide to eliminate ideas that
Are amusing, but inappropriate
Do not directly address business goals
Do not directly address business issues arising from the
opportunity investigation
Are low priority/high effort
Solution Scope
Versus Project Scope
Defining Boundaries

ESI 30
Defining Solution Scope (continued)
Obviously, the team will have to discuss some ideas more thoroughly
than others to determine whether they need to be considered in scope or
out of scope. In the end, the team must have a clearly defined scope,
listing both features that are included and those that are excluded from
the opportunity solution.
Scoping is especially critical in iterative development or rapid
development projects because each iteration can bring about scope
change. Scoping affords the project team the ability to classify features
into releases so that scope, although constantly changing, is a bit more
manageable.
Ultimately, the clear definition of vision and scope through business
analysis will help
Guide requirements elicitation
Contain scope creep
Manage change
Manage client expectations
Unite the project team in a common purpose
Justify further resource commitment for the project
Establish quality standards
Establish acceptance criteria
Scope creep is the gradual, progressive increase of a projects scope such
that it is not noticed by the project team or the customer. Generally
scope creep occurs when the customer, project team, or other project
stakeholder identifies additional, sometimes minor, requirements that
when added together, collectively result in significant scope expansion
and cause cost and schedule overruns.
One of the most important, ongoing uses of the vision and scope report is
the management of change and scope creep. Note that the BA has
different concerns about scope creep than does the PM. The PM works to
avoid scope creep; in the requirements process, the BA works to manage
scope in order to maximize the benefits of the opportunity solution while
minimizing negative effects on projected schedule and cost.
Defining Boundaries
(continued)
Benefits of Defining
Vision and Scope
Scope Creep

ESI 31
The BA must not be seen by the customer as a roadblock to improving
solution scope. The BA needs to balance the benefit with the time and
cost needed to include all features in the solution. If prior to the
approval of the BRD, the BA is presented with a new feature that was not
cited within the original scope, the BA needs to analyze the benefit of the
new feature. Some questions to ask include
Can the added feature be mapped back to business goals?
How will the added feature affect project schedule and cost? Is
the effect significant?
Who made the request?
If the change request is received after the approval of the BRD, the BA
must defer to the documented project change management process.
Change is simply the transition from one condition to another. In terms of
the project environment, change can be any
Expansion or reduction of project scope
Modification of policies, processes, plans, or procedures
Increase or decrease in costs or budgets
Revision to the schedule
Change requests can be direct or indirect, external or internal, mandatory
or optional. Once the BRD has been approved, only formally
documented change requests can be processed, approved, and
implemented through the project change management process.
Changes to the project can come from almost anywherethe customer,
the team, the project manager, senior management, or outside regulatory
agencies. The key from a project perspective is to manage them. Major
sources of change include
Customers
Project management and team members
Organization management
Government agencies
Environment
Product obsolescence
Funding
Technological advances or problems
Scope Creep
(continued)
What Is Change?
Managing Change

ESI 32
Because changes will happen, the project team must be ready for them
with a process that is written into the project plan. The PM must include
a change management plan in the project plan, especially on technical
projects. The change management plan needs to establish procedures
for
Submitting change requests
Reviewing the effect of proposed changes on project cost, time,
scope, and quality
Approving and rejecting proposed changes
Do not let comments in casual conversations be considered change
requests. All change requests, no matter what the source, must be visible
(for example, submitted in a standard written format). The process must
clearly specify who has authority to direct changes and to what extent.
Enforcing the change management process may seem overly laborious in
a rapid development environment, but it is still important to track what
changes have been made, why they were requested, and who approved
them. During rapid development, the business sponsor is in the room
with the designers and is available for immediate approval or disapproval
authority. All meetings should be documented through meeting minutes
or notes, thereby satisfying the need to document changes.
The BAs role in change management is to help the PM determine the
impact of the change on the requirements (scope) of the solution and the
project. The BAs role may also entail replanning how to test, or validate,
the requirements in the testing phase.
Ensuring Solution Quality
A final purpose of the vision and scope report is to provide a quality
baseline for the project. Quality is defined as the
Total characteristics of an entity or item that affect its ability to
satisfy stated or implied needs.
Conformance to requirements or specifications.
Fitness for use. (Ward, p. 360)
Managing Change
(continued)
Defining Quality

ESI 33
Ensuring Solution Quality (continued)
Customers define quality. No matter how well made the product, or how
well performed the service, an organization will not achieve quality if its
products and services do not meet customer expectations and
requirements.
This relationship to quality is why the BA needs to strive to quantify
vision and scope, despite most users tendencies to speak in qualitative
terms. Specificity greatly strengthens the BAs deliverables as well as the
projects overall business case. For example
Specify Instead of
The solution will increase revenue
20 percent or more by 2008
The solution will increase revenue
No more than two defective parts
per thousand, according to
company standard 3.2.5
High-quality products
14-point text Readable text
Building quality measures into the solution from the start is much less
expensive and burdensome than fixing deficiencies that are discovered
after the solution has been implemented. In a nutshell, the more the BA
can do during the Analysis phase to elicit specific, quantifiable goals that
help define quality standards, the fewer failures due to nonconformance
that will be discovered and require correction.
The cost of quality is generally shown as this equation:
cost of quality = cost of conformance + cost of nonconformance
The commitment to quality may increase an organizations conformance
costs (for example, hiring a business analyst to perform requirements
elicitation and documentation), but the resulting savings in
nonconformance costs decreases the organizations total cost of quality.
For example, before an organization commits itself to a quality program,
the percentage of costs as a result of conformance is usually much
smaller than the percentage for nonconformance. Very little money is put
into prevention and appraisal, resulting in a great deal of money spent to
fix failures. In the before example below, the organization is spending
$3 million per year on conformance costs and $10 million on
nonconformance costs, for a total of $13 million.
Defining Quality
(continued)
The Cost of Quality

ESI 34

After committing to a quality program, the opposite is generally true: The
percentage of costs as a result of conformance is usually much greater
than the percentage for nonconformance. In the after example above,
the organization is spending $5 million per year on conformance costs (a
$2 million increase), but only $2 million on nonconformance costs (an
$8 million decrease) for a total of $7 million. As a result, the
organizations total cost of quality has decreased by $6 million.
Regardless of whether an organization is proactive or reactive about
quality, there is a cost. In the long run, the total cost of quality is less
expensive in a proactive environment. However, proactively ensuring
quality is often more painful and inconvenient because it appears to slow
down the start of a project.
In discussing quality in the context of requirements elicitation, two
important distinctions need to be made:
Quality versus grade
Excellence versus perfection
Grade refers to categories used to distinguish items with the same
function. For example, when you pull into a gasoline station, you can
usually choose among three or more grades of gasoline: regular, super,
and premium. Any of the three will run a standard car, but each offers a
different level of octane, which equates to a different level of
performance and different quality standards. You may use premium
gasoline in your luxury car and regular gasoline in your commuter car:
both will fuel the cars. The different grades indicate only their
performance for use in different vehicles, not their quality. That is, you
can have low-, medium-, and high-quality regular gasoline; and low-,
medium-, and high-quality premium gasoline.
The Cost of Quality
(continued)
Grade, Excellence,
and Perfection

ESI 35
Excellence is the highest level of quality that can be achieved within
project constraints, such as schedule and cost. It is by nature a moving
target (and a good reason to keep project time frames shorter than
technology life cycles, because excellence today may be obsolete next
year). Perfection, on the other hand, means zero defects. Perfection has a
cost and in most cases, business solutions simply cannot afford zero
defects. The cost difference between a system that is available 100
percent of the time and one that is available 99 percent of the time may
be more than double (necessitating, for example, tandem systems).
The BA must realize that when customers demand perfection, what they
often really want is excellence. The BA must determine the acceptable
variance: the difference between perfection (zero defects) and what is
both possible within project constraints and acceptable to the customer.
Validating Vision and Scope
The projects vision and scope are captured in the vision and scope
report, which includes, at minimum
The executive summary
Approvals
Current business, AS-IS model, describing the-
Business problem and root cause
Business opportunity
Vision and scope, TO-BE model, describing
Process improvement targets
Proposed solution features
Any assumptions, dependencies, or constraints
Risks
The proposed schedule
The proposed budget (with cost-benefit analysis)
The revision log
Grade, Excellence,
and Perfection
(continued)
The Vision and Scope
Report

ESI 36
Validating Vision and Scope (continued)
Before submitting the vision and scope report for approval, the BA needs
to analyze each feature in the solution scope to determine its feasibility,
to look for potential problems, and to evaluate risks. Consider the
following questions:
Does the solution vision map back to business goals?
Does each feature included in the scope map back to the solution
vision and business goals?
Are there any conflicting statements in the solution vision?
Are there any conflicting features in the solution scope?
Are all features feasible given known project constraints?
Do the stakeholders share a common understanding of the vision
and scope?
The BA must ensure that all statements are clear, all features are
measurable, and all benefits are tangible. Only then is the vision and
scope report ready to be passed on for acceptance and approval.
Validating Vision and
Scope

ESI 37
Chapter Summary
Visioning is a key activity in the development of solution
scope.
Solution vision describes what will change once the
solution is implemented.
Solution scope delineates boundaries for the solution, both
features that are included and those that are not.
Project scope is managed by the project manager; solution
scope is managed by the business analyst.
Quality must be analyzed according to desired grade and
excellence.
Cost of quality = cost of conformance + cost of
nonconformance

ESI 38
Requirements:
listed.
Next-Steps Action
Plan

ESI 39
How to Gather and Document User Requirements Chapter 2: Establishing Vision, Scope, and Quality

Action Plan:
Apply what you have learned about establishing the vision, scope, and quality by developing a list of actions you will complete when you
return to your organization.
Questions
to Consider:
How can I work with stakeholders to define the solution vision and scope?
How can I manage change to the solution scope should the need for a change arise?
How can I ensure that quality is considered when eliciting requirements?

Time
1.

2.

ESI 40
Time
3.

4.

5.

ESI 41
Modeling at the Enterprise Level
Reference Material
This chapter introduces several modeling techniques that the business
analyst (BA) uses to create the business architecture baseline. The BA
uses models to document both the AS-IS (the current state of the
enterprise or process) and the TO-BE (the future state of the enterprise or
process) at all levels of the organization with the goal of process
improvement. This chapter highlights the most commonly used models.

Chapter Overview
3

ESI 42
Modeling at the Enterprise Level
The Function of Modeling in Business
Analysis
Business analysis supports the investigation of problem areas and
opportunities in existing or proposed business processes with a goal of
process improvement. The BAs toolbox in this endeavor is a collection
of enterprise and process models used to document current (AS-IS) and
future (TO-BE) states.
With business models, the BA can
Produce clear, pictorial representations of the enterprise and its
processes
Highlight areas of inefficiency and redundancy
Assess the impact of proposed changes
Document process changes that accurately reflect user
requirements
All the models are scalable, meaning the BA can perform analysis and
requirements elicitation at precisely the level of detail necessary. The
models can be as simple or as complex as they need to be. At the
enterprise level, the models give the BA a structure for asking questions
about the business. Such questions might include who is accountable for
various parts of the business, who are the suppliers for materials and
services, and what are the business locations. Process models, however,
give the BA an easy way to change processes to see the effect of
proposed improvements without actually changing the business.
BAs use models to document both the AS-IS (the current state of the
enterprise or process) and the TO-BE (the future state of the enterprise or
process). Both AS-IS and TO-BE modeling use the same techniques, but
the goals and, therefore, the approaches are different.
Why Do We Use
Modeling?
AS-IS Versus TO-BE
4 3

ESI 43
The Function of Modeling in Business Analysis (continued)

Differences Between AS-IS and TO-BE Modeling
AS-IS (Current State) TO-BE (Future State)
Analysis covers the business area as
needed
Analysis covers all change areas and
their relationship to other areas
Models may be incomplete Models are complete and unified
Analysis may be a mix of formal and
informal techniques
Analysis is formal and precise
Models specify areas for change Models extend solution vision,
highlighting changes from AS-IS
AS-IS modeling is part of enterprise analysis and provides the baseline
against which changes to the business architecture are measured. It
positions the project within the goals, constraints, and mission of the
funding organization, and it facilitates root cause analysis. Outputs of this
process include
Business goals, drivers, and objectives
Organizational structure
Business functions and services
Business processes
Business roles
Key stakeholders concerns
Gap analysis (what is the difference between the AS-IS and the
desired TO-BE?)
Sources of information for AS-IS information include
Decision makers (such as owners, shareholders, directors,
managers)
Users and operators
Implementers
TO-BE modeling guides the requirements elicitation by providing a
unified view of
Information to be managed
Business processes
Workflows
Use case scenarios
Business rules
AS-IS Versus TO-BE
(continued)
AS-IS Modeling
TO-BE Modeling

ESI 44
The Function of Modeling in Business Analysis (continued)
Once the elicitation is complete, the BA integrates user requirements
with the TO-BE models, developing a complete package to guide
solution design and construction.
When documenting requirements, models and text should be used
together. Lists of text-only requirements tend to be incomplete,
ambiguous, confusing, and difficult to manage. A complete package that
integrates models with text requirements gives the project team several
advantages because it
Encourages complete elicitation of requirements and rules
Aids the understanding of requirements by providing a business
context
Helps ensure precision and clarity
Allows for validation prior to implementation
Aids in managing changes
Helps ensure that solution requirements are consistent with
solution vision
Business Rules
Business rules govern the way a business initiates actions and responds to
situations under various conditions (for example, normal processing,
alternative processing, and exception processing). Business rules may
originate inside (corporate policy) or outside (government regulation) the
organization, and they may take various forms in the organization, such
as
Regulations
Calculation formulas
Process rules
Information management rules
Decision logic
Some sample business rules include the following:
Employees and contractors may carry out their business activities
only within the areas of the building that appear as color codes
on their identification badges.
All timesheets will be submitted by noon on the Thursday prior to
the pay date. If they are turned in after noon on Thursday, they
have to be submitted to the Human Resources Director for
approval.
TO-BE Modeling
(continued)
What Are Business
Rules?

ESI 45
Business Rules (continued)

All submitted insurance claims must have the individuals name,
date of incident, and the individuals policy number or the claim
will be returned to the individual.
A sales tax of 7.5 percent must be added to all purchases, except
food and prescription medicines.
Business rules and requirements are not the same thing. Business rules
are a characteristic of business operations and exist independently of the
proposed solution or opportunity. Requirements, on the other hand, are
characteristics of the solution and describe it directly.
In general, business rules constrain processes and drive requirements.
The BA often documents them with constraints in the business
requirements document (BRD).
Often, business rules are not standardized or clearly defined, making it
difficult for the BA to capture the AS-IS. For example, business rules may
be embedded in programming code in existing applications, or they may
be implicit in everyday procedures. Even worse, they may exist only in
the minds of a select few individuals at the organization. This situation
presents problems for
Requirements elicitation and documentation
Business process engineering
Solution selection, development, and implementation
Without existing documentation, the BA has to discover and document
business rules in order to track their effect on the requirements elicited.
Some of the sources for business rules are
Organizational decision makers (such as owners, shareholders,
directors, managers)
End users and operators
Implementers
Existing AS-IS models (especially logical data models and use
case scenarios)
Business rules are not absolute; they do change. Even if business rules are
clearly documented, the BA must validate them to ensure the constraints
they represent do actually exist before integrating them into the analysis
effort.
What Are Business
Rules? (continued)
Business Rules Versus
Requirements
Sources for Business
Rules

ESI 46
For example, a convenience store business rule might be that vendors
only restock goods after 6 p.m. During an analysis of reasons behind high
operating costs, the BA might investigate why the business rule exists. If
no one in the business can provide a reason for the rule, the BA might
suggest that management approve deliveries earlier in the day. This
simple validation could eliminate an invalid business rule that was
causing significant overtime costs for the vendor and were being passed
on to the store.
As a BA, you may not be able to catalog and track every business rule in
your organization, but you need to have some process in place for
capturing and tracking those business rules that do apply to your business
area. Failure to do so can result in both the application of contradictory
business rules to a process or solution and the inconsistent application of
business rules. By capturing and tracking business rules, you can
Validate business rules to ensure they support organizational
goals
Eliminate contradictory business rules before they are built into a
solution
Guide requirements elicitation according to constraints imposed
by business rules
Monitor changes to business rules
Determine the relationships among business rules at the various
organizational levels
Two methods for documenting and tracking business rules are catalogs
and decision tables. General business rules are often stored in a central
repository or catalog. At minimum, the catalog captures a unique ID, the
business rule itself, what type of rule it is, and the source of the rule. The
BA can use the catalog ID when referencing business rules in models.
Sources for Business
Rules (continued)
Tracking Business
Rules

ESI 47
Example:
Business Rule Catalog:
ID Rule Type Source

54 All full-time employees must be at
work performing work-related
functions during the core business
hours of 9:00 a.m. and 3:00 p.m.
Constraint Company
policy
55 All employees must take one 15-
minute break for every 4 hours of
work.
Constraint Government
regulation
(OSHA v.2.5,
4:15, p.365)

More complex business rules involving decision logic are better captured
in a decision table. Decision tables show how different outcomes depend
on combinations of factors and allow the BA to capture very complicated
rules with multiple conditions and possible actions. These tables are later
used as the basis for condition-testing the system.
Tracking Business
Rules (continued)

ESI 48
For example
Decision Table: Approve Credit Increase and Amount
1 2 3 4 5 6 7 8 9 10 11 12
Credit
increase <=
10%? (Y/N)
Y Y Y Y Y Y N N N N N N
Years as
customer
>= 5? (Y/N)
Y Y Y N N N Y Y Y N N N
C

O

N

D

I

T

I

O

N

Previous
credit
disputes?
(0,12, 3+)
0 12 3+ 0 1
2
3+ 0 12 3+ 0 12 3+
Decline X X X X X X
Approve X X X X X X
Increase full
requested
amount
X X X
A

C

T

I

O

N

Increase
requested
amount
X X X
Modeling Techniques
Many models are available to the BA for documenting the AS-IS and the
TO-BE. This section provides high-level (conceptual) descriptions of the
more common models and how they are used.
4
For ease of discussion,
the models are grouped into several categories:

4
It is beyond the scope of this document to provide in-depth coverage of
business modeling techniques. ESIs courses Process Modeling Management,
Use Case Modeling, Logical Data Modeling, and Testing Techniques for Tracing
and Validating Requirements provide more in-depth coverage of individual
modeling techniques.
Tracking Business
Rules (continued)

ESI 49
Modeling Techniques (continued)

Organization
Organization model
Business interaction model
Location model
Strategy
Goal model
Impact model
Process
Functional decomposition
Event model
Use case diagrams and scenarios
Workflow model
Process model
Activity diagrams
Relationship/input-process-output
Information/communication
Data flow diagram
Logical data model
System model
These divisions are not absolute, and some models may function equally
well in more than one category (location models, for example, fit equally
well in any of the categories, depending on their use).
Organization Models
Models in the organization category define and structure organizational
components of the business and their internal and external relationships.
These models help show what groups need to be considered and how
structure supports organizational goals.

ESI 50
Organization Models (continued)
The organization model is a hierarchical representation of an
organization and its supporting roles. Organization models (also known
as organizational charts) typically begin with high-level areas and are
decomposed within each branch, division, or line of business. They may
or may not involve the identification of key personnel.

The business interaction model is a network representation of all or part
of the business showing organizational boundaries and interactions with
internal and external organizations. This model can be used to show
vendor and client relationships, with the identification of key deliverables
and commitments. In the example below, Whizbang Toys relies on a
highly coordinated supply chain to make its product lines.

Organization Model
Business Interaction
Model

ESI 51
Organization Models (continued)
The location model is another network representation that shows various
geographic locations of interest to the organization. It can be used to
highlight areas of geographic resource and financial investment, market
segments or customer locations, or physical locations within a specific
facility. Location models may or may not plot locations on an actual map,
but the BA needs to recognize that the layout of the model may
significantly affect the analysis of the data collected.
Location models aid in the recognition of location-dependent
relationships. For example
Businesses with widely dispersed locations must accommodate
differences in culture, language, legislation, and buying habits
Map-based models can help determine both areas that lack
coverage and those that have too much coverage

Strategy Models
Models in the strategy category show the relationships of plans, projects,
goals, and risks. (Business rules also may be documented in this category,
showing their influence on other strategic components.) These models
help ensure that process improvements are consistent with the strategy
and goals of the organization.
Location Model

ESI 52
Strategy Models (continued)
The goal model is a hierarchical representation of business goals
associated with business processes and their activities. The model
typically begins with strategic goals and decomposes them to specific
tactical and operational goals.
In the example below, Gardenation, Inc., has set a strategic goal to be the
leading supplier of plastic lawn ornaments in North America by 2007
(S1). To support this strategic goal, the product development group has
launched a series of tactical projects to produce a variety of products in
two new series: adventure and fantasy (T1 and T2). These tactical goals
have been further decomposed into the operational goals to upgrade
existing design systems and recruit new talent (O1 and O2). The goal
model helps to ensure that all project goals map back to the main
strategic goal.

Goal Model

ESI 53
Strategy Models (continued)
Impact models, also hierarchical, organize the possible effects of a
change and aid in the decision-making process. Arranging the possible
costs, benefits, and risks of a project, they provide a snapshot of the
overall cumulative impact of a proposed effort, providing a basis for the
BA to determine whether the overall effort is worth making.

Process Models
Models in the process category define the processes and activities of the
business. This group contains the most varied collection of models and
diagrams (including process models) to show the functions of the
enterprise, process components and interactions, and complex
workflows. These models categorize initiating events and show process
details such as when and how activities are performed, who performs
them, and their inputs and outputs.
Impact Model

ESI 54
Process Models (continued)
Functional decomposition diagrams are hierarchical models that show all
the essential business processes without showing any sequence or
relationships between them. These diagrams simply capture the
processes. Traditionally, BAs have used these diagrams as the basis for
defining requirements. With the advent of object-oriented (OO)
programming, BAs have switched to use case diagrams because they lend
themselves better to OO design.

Functional
Decomposition
Diagram

ESI 55
The event model is a Gantt chart
5
or calendar representation that
organizes the business by key events. It can be fiscally oriented (for
example, month-end processing or year-end processing) or
product/service oriented (following the project life cycle).

Use case diagrams and scenarios are part of the Unified Modeling
Language (UML).
6
They provide a simple, nontechnical way to describe
the functionality of a system and can be used either to show the way a
current system operates or to capture requirements for a proposed
system.
The diagrams (graphics) and scenarios (text) work in tandem to describe
the behaviors of the user and system interface. Not only can the BA use
this modeling technique to initially define user requirements, but the BA
can later refine the model by adding functional and nonfunctional
requirements.
The diagrams depict users of a system as stick figures: a user being a
person, other system, or an event such as month-end processing. These
stick figures are called actors. The behavior between the actor and the
system is depicted by an oval: a behavior being a function that the actor
needs to perform, with a title that is an action verbnoun pair. A line is
drawn to show the association between the actors and the use cases.

5
Gantt chart. Graphic display of schedule-related information. Generally,
activities or other project elements are listed down the left side of the chart,
dates are shown across the top, and activity durations are displayed against the x
and y axes as data-placed horizontal bars. Named after its developer, Henry
Gantt (Ward, p. 185).
6
Unified Modeling Language, or UML, is an object-oriented analysis and design
language developed by the Object Management Group (OMG). UML grew out
of an attempt to standardize several diagramming methods developed in the late
1980s, including Grady Booch's work at Rational Software, Rumbaugh's Object
Modeling Technique, and Ivar Jacobson's work on use cases.
Event Model
Use Case Diagrams
and Scenarios

ESI 56
Use case diagrams depict the boundary of the system as a rectangle,
called the subject. The rectangle is titled by the name of the system and is
surrounded by the actors that are outside the boundaries of the system.
Within the rectangle are the use cases along with lines associating them
with the actors.

Use case diagrams may also show relationships among use cases;
however, relationships among actors are never shown.
BAs often create use case diagrams during interviews to initially
document an overview of user requirements, and then they follow up
with details by writing use case scenarios.
Use Case Diagrams
and Scenarios
(continued)

ESI 57
Use case scenarios flow out of use case diagrams, providing a detailed,
step-by-step description of the behavior between the system and an actor
in the accomplishment of a single business objective. BAs write use case
scenarios as a series of numbered steps. For example, using the order
computer use case shown in the diagram above, a use case scenario
might be as follows:
1.0 The use case starts when the online customer selects Order
Computer
2.0 The online customer enters the product code for the desired
computer
3.0 The system supplies a product description and price for the
selected computer
4.0 The online customer enters credit card payment information
5.0 The online customer selects Submit
6.0 If payment is authorized by the credit card company,
the system
6.1 Marks the order
as confirmed
6.2 Forwards payment
information to the
accounting system
6.3 Returns an order
confirmation number to
the online customer
and the use case ends
Many variations for each use case scenarios may exist to allow for normal
processing (sometimes called the happy path), alternative processing,
and exception processing. These use case scenarios can also be used as
test scenarios for the system.
The workflow model represents the business in terms of component
groups and the flow of work among those groups. The BA uses this
model to describe key functions of departments and divisions, focusing
on the identification of key hand-off points and roles. Business level
(conceptual) workflow models do not depict the internal workings of
individual processes. They are conceptual overviews of interactions
among groups or divisions.
Use Case Diagrams
and Scenarios
(continued)
Workflow Model

ESI 58

Process models show the decomposition of the workflow into processes
and activities. At the business level, they do not show the details of
individual jobs and tasks. Process models, also called flowcharts, are
graphical models of how information moves through a process. They
begin in the top left corner of the page and move right and down through
the flow of activities. Each arrow is unidirectional (there should be no
endless loops), because every flow should have exactly one start and at
least one finish point. Therefore, every path through the flowchart must
be traceable from the start to one of the end points. Suppose one
flowchart, A, continues to a second flowchart, B. The exit point on
flowchart A is repeated as the entry point on flowchart B.

Workflow Model
(continued)
Process Model

ESI 59
Activity diagrams (also known as swim lane diagrams) show individual
processes and hand-off points in detail. Activity diagrams also follow
UML notation and may be organization or role centered, with decision
points explicitly shown in the model. In an activity diagram, processes
run in and across swim lanes that can be configured to represent user
roles or physical or organizational locations. Each diagram begins with a
single trigger that serves as the catalyst for running the process flow, but it
can have multiple ending states.
VENDOR
ANALYST
VENDOR SALES REPRESENTATIVE CUSTOMER
Issue
Application
Enhancement
Request
Application
Enhancement
Request
Issue
RFP
RFP
Plan
Response
Prepare
Sales
Proposal
Merge Proposal
Sections
Response
Plan
Sales
Proposal
Approve
Proposal
Proposal
[approved]
Proposal
[draft]
Prepare
Technical
Proposal
Technical
Proposal
[else]
[application exists]

Activity diagrams display in a visual format the similar information that is
in use case scenarios. They tie together the main use case and all its
extensions and flows, resulting in an overall flow of control, including
decision points and iteration.
Activity Diagram

ESI 60
In general, a relationship map describes a customer-supplier network and
gives a macro aerial view of work relationships. This example focuses
on major relationships among training and hardware suppliers, the
internal project organizations, and the customer groups affected by the
introduction of a new customer billing system.

Relationship Map

ESI 61
Information Models
Models in the information category show the communications that exist
in organizational and system components. These models define the
communication patterns and networks that support the business.
System models illustrate the systems and subsystems that support the
business. The systems shown may be paper-based manual systems or
technology-based systems such as intranet, Internet, or extranet systems.
(The example below is for a technology-based system.)

System Model

ESI 62
Information Models (continued)
Data flow diagrams show how data move from one process to another, as
well as how the data are stored. Data flow diagrams include the
following elements:
External agents: Sources of data; represented by squares
Processes: Take data as input, do something with it, and output it;
represented by rounded rectangles
Data stores: May be electronic, such as databases, or physical,
such as filing cabinets; represented by open-ended rectangles
Data flows: Show the exchange of data through electronic or
physical means; represented by arrows

Logical data models (also called entity relationship diagrams or ERDs)
show the data relationships in the solution. They are built using three
types of data objects:
Entities: Uniquely identifiable groups of persons, places, or things
about which the system wants to capture and save information
(for example, customers, orders, and so on).
Attributes: Characteristics of properties that further identify the
entity (such as first name, last name, city, state, zip code, color,
size, and so on). A Unique Identifier is a special attribute that is
unique, has a single value, and must be there for each occurrence
of the entity. This keeps entities separate and allows for better
database construction.
Relationships: Describe how the entities relate to each other (for
example, customer places order, or order shipped to address).
Cardinality is the minimum and maximum of each business rule
as it applies to each entity.
Data Flow Diagram
Logical Data Model

ESI 63
Information Models (continued)
Several different notations exist for logical data models, and their style
varies among organizations. When using data models, make sure the
entire team agrees to a common notation and style.
places
placed by
contains
contained in
Order Date
Order Number
ORDER
Customer Name
Customer Address
Customer ID
CUSTOMER
Quantity
Order Number
Order Item Number
ORDER ITEM
Product Name
Product Price
Product Description
Product Number
PRODUCT
an order
for
ordered
as

The Business Analysts Toolkit
Modeling allows the BA to
Clearly document facts (AS-IS) and vision (TO-BE)
Facilitate communication through visual representation of
complex relationships
Document requirements for solution development and testing
It is unrealistic to attempt to model every single aspect of a given
business or system or to expect a single model to capture all the
information needed. Success depends on knowing what to model and
when. Each model generates its own questions, has its own strengths and
weaknesses, and in most cases can be used for a variety of business
applications.
The table below shows two examples of the way a BA might use
modeling. Given a business goal, the BA identifies what is preventing the
business from achieving that goal, selects a model to use in investigating
the problem, and based on an analysis of the AS-IS model, proposes
possible solutions to the problem.
Logical Data Model
(continued)

ESI 64
The Business Analysts Toolkit (continued)

Business Goal Problem Type of Model
Possible
Solution
Improved
business
communication
Workers are
unable to find
information
when needed;
information may
be found in
several different
places (but
doesnt always
match)
Information/
communication
models
Identify
duplicate data
stores and
manage or
reduce
redundancies
Improved
customer
service; on-time
delivery of
products
Customers
complain that
work takes
longer than it
should
Process models Eliminate
activities that do
not add value;
convert serial
activities with
no
dependencies to
parallel
activities

ESI 65
Chapter Summary
Business rules are a characteristic of business operations
and exist independently of the proposed solution or
opportunity.
BAs use models because they are
Scalable and can perform analysis and requirements
elicitation at precisely the level of detail necessary
An easy way to change processes to see the impact of
proposed improvements without actually changing the
business
Both AS-IS and TO-BE modeling use the same techniques,
but the goals and, therefore, the approaches are different.
Many models are available to the BA for documenting the
AS-IS and the TO-BE.

ESI 66
Requirements:
listed.
Next-Steps Action
Plan

ESI 67
How to Gather and Document User Requirements Chapter 3: Modeling at the Enterprise Level

Action Plan:
Apply what you have learned about modeling at the enterprise level by developing a list of actions you will complete when you return to
your organization.
Questions
to Consider:
How can I identify, document, and track the business rules within my organization?
How can I use models to document the AS-IS and TO-BE states of my organization?

Time
1.

2.

ESI 68
Time
3.

4.

5.

ESI 69
Developing the Requirements Work Plan
Reference Material
This chapter focuses on planning the requirements activities for the
Analysis phase. The major output of planning the analysis is the
requirements work plan (RWP), which details the activities to be
performed for the requirements elicitation and documentation. This
chapter stresses the importance of planning before eliciting and
documenting solution requirements to ensure that nothing is forgotten.
Chapter Overview
4

ESI 70
Developing the Requirements Work Plan
Overview of the RWP
The BA creates an RWP to document how the business analysis team will
approach requirements activities on the project. The RWP details
Activities the team will perform
Scope
Resources
Schedule and budget estimates
Procurement plan
Communication plan
Risks
Deliverables
The RWP is, in effect, a mini project plan focused solely on the Analysis
phase of a project. It typically is developed in coordination with the
project manager, and at the project managers discretion the RWP may
also become part of the overall project plan.
The RWP must be approved by the project manager and the business
sponsor prior to beginning the actual requirements elicitation.
Planning the requirements elicitation in the RWP helps the BA ensure
that
All requirements activities are captured
Appropriate elicitation and analysis methods are selected
Expectations are set with all stakeholders
The project team has a common understanding of the
requirements elicitation process
Resources (including the business sponsor, users, and other
stakeholders) are available for participation when needed
Risk strategies are in place
Elicitation is coordinated with other project tasks
Once completed, the RWP serves several important functions. First, the
RWP is an important communication and negotiation tool for the project
manager and project sponsor. By defining the tasks to be completed
during Analysis and the resources and time needed to complete them,
the BA makes the complexity of the process both visible and measurable.
What Is the RWP?
How Is the RWP
Used?
4 4

ESI 71
Overview of the RWP (continued)
Second, the RWP provides the BA with a powerful risk management tool.
For example, if the project manager or business sponsor decides to
reduce the schedule or cost, or increase the scope of the analysis, the BA
can use the RWP to assess the risk of the change. The BA provides
support for the risk decision, but the project manager and/or business
sponsor is responsible for risk acceptance. The more complete the RWP,
the better prepared the BA will be to communicate and control analysis
risk.
Finally, the RWP provides a baseline for changes to the schedule and
cost, which are logged and tracked here. Careful risk analysis and
planning will prepare the BA and project team for challenges
encountered in the requirements elicitation process, and the plan
provides a way to document and track changes as they occur.
Elements of the RWP
Because the RWP is a project plan focused solely on the Analysis phase
of the project, it must contain many of the same elements as a full-
fledged project plan. The BA must include, at minimum, sections for the
following:
Cover page
Executive summary
Approvals
Purpose
Analysis scope
Resources
Risks
Analysis schedule and budget estimate
Procurement plan
Communications plan
Revision log
How Is the RWP
Used? (continued)

ESI 72
Elements of the RWP (continued)
The cover page includes the title of the document and basic project
administration information, such as who prepared the document, the date
it was prepared, names of key stakeholders, file name and location, date
of last revision, and so on.
The executive summary highlights the main points of the plan. The
summary is placed at the beginning of the RWP and is brief and concise
(no more than one page). It lists the deliverables that will be produced as
a result of the analysis, the major risks identified during planning, and the
proposed analysis schedule and budget.
The approval is the accountability for the plan; it identifies and provides
space for dated signatures. The RWP is usually signed by the BA, PM,
and business sponsor. Signatory approval indicates that everyone has
read and understood the document and that it represents the current
understanding of the proposed solution, risks, benefits, the associated
budget, and schedule. Once the RWP has been approved and signed,
any changes to the analysis plan must go through the projects change
management process.
The purpose states the two main functions of the requirements work plan.
The RWP is
An action plan for developing the BRD
A negotiations tool for discussing the effort needed to develop
the BRD
The analysis scope restates the boundaries along with any changes since
the issue of the vision and scope report. Major scope changes should
trigger a warning for the BA and may indicate substantive change in
project definition and a need for reevaluation.
The analysis scope further describes the approach and quality standard
that will be used for business analysis such as the elicitation methods and
the current assumptions, constraints, and dependencies.
Cover Page
Executive Summary
Approvals
Purpose
Analysis Scope

ESI 73
Typically, the BA and the analysis team will develop a work breakdown
structure (WBS) to capture all analysis tasks and ensure that nothing is
forgotten. Depending on the size of the analysis, the WBS can be a
simple list of activities, organized by time and who will complete them,
or a detailed hierarchy chart showing major task groups broken down
into several levels of smaller components.
Note that the WBS is a working document and, in general, it is not
included in the RWP because the business sponsor (the primary audience
for the RWP) is not likely to want or need such detailed task information.
However, the BA may review the WBS with the project manager
separately, because the project manager will construct a WBS for the
entire project as part of project planning.
The resource plan focuses on resources needed to perform the Analysis
phase. These resources include
Human resources needed for the analysis team, identified by
name, professional role or title, as well as their functional role
within the business analysis activities
Users who will need to be available for the requirements
elicitation and profiles of the user group
Nonhuman resources, such as travel expenses, meeting rooms,
computer equipment, and so on
The resource plan has a significant effect on the budget estimate for the
analysis, so the BA needs to work carefully to ensure that all resource
needs for the project are captured during planning. Some typical analysis
team roles include
Business analyst
Systems analyst
Project manager
Project sponsor
Business sponsor
Quality assurance personnel
Development team personnel
Other stakeholders
Analysis Scope
(continued)
Resources

ESI 74
The risk section details all potential risk events for the analysis (not the
project) identified during planning. For each risk event, the BA must
prepare a clear risk statement, assess the impact and probability of the
risk, and propose a strategy for resolving the risk should it occur.
Careful risk planning helps the BA build support for the RWP. The BA
uses the risk analysis to communicate risks to the project manager and
business sponsor and to provide risk decision support for going forward.
At minimum, the schedule includes a high-level list of Analysis phase
milestones. The level of detail included depends on the nature and
complexity of the analysis.
The BA builds the schedule out of the WBS developed during the
analysis scope activity. The vision and scope report schedule estimate for
the analysis is a top-down estimate; however, the RWP schedule is a
bottom-up estimate and more accurate, because it is based on a lower
level of detail. If a significant gap results, the BA must be prepared to
explain the variance during the RWP review with the project manager
and business sponsor.
The budget estimate is a projection of the analysis cost. The BA also
builds the budget estimate out of the WBS created for the Analysis phase.
As with the schedule, the BA builds the cost estimate out of the WBS
developed during the analysis scope activity. The vision and scope report
estimated the analysis cost using a top-down method (the same way the
schedule was estimated). The RWP cost estimate is a bottom-up estimate
and is more accurate, because it is based on a lower level of detail.
If a significant gap results, the BA must be prepared to explain the
variance during the RWP review with the project manager and business
sponsor.
Risks
Analysis Schedule
Analysis Budget
Estimate

ESI 75
A procurement plan, if needed, summarizes the process for pursuing an
outsourced solution. The BA includes this section if, as a result of this
effort, a request for proposal/quote (RFP/RFQ) will be issued to respective
system suppliers via the Procurement department.
The communication plan describes how the analysis team communicates
progress and results with project stakeholders. The plan details what
information will be provided to whom, in what format, and how often.
The revision log captures the revision history of the document (including
the date a change is made, which requirement is changing, who
requested it, and why the change is needed). Revisions made after the
document has been completed and approved must go through the
project change management process.
Identifying Business Analysis Tasks
The identification of all the tasks required for the requirements elicitation
process is a major part of requirements planning. The level of detail
captured in this list depends on the nature and complexity of the project
and the internal processes involved. This may be as simple as a list of
items organized by time (schedule) or who does what (accountability), or
it may be a detailed hierarchy chart, or WBS, showing major task groups
broken down into minor tasks groups, broken down into tasks.
The WBS is a good approach for bottom-up estimating of overall
schedule and cost requirements for the Analysis phase, and the BA can
use the completed WBS to draft the analysis scope, schedule, and budget
of the RWP. The WBS is also a good way to identify dependencies and
constraints among analysis tasks.
Procurement Plan
Communications
Revision Log

ESI 76
Identifying Business Analysis Tasks (continued)
A WBS is a hierarchically structured task or deliverable-oriented grouping
of work activities that can be created to organize and define the total
scope of the Analysis phase. Typically, the WBS is thought of in terms of
project management; however, it is invaluable to business analysis,
especially on larger projects. The WBS aids the BA in planning resources,
the budget, and schedule, and serves as the source document for both
planning and managing the Analysis phase. It prevents the BA from
allocating time and resources on work that is unnecessary and serves as
an institutional memory for future efforts.
The WBS offers several benefits during the analysis. It
Identifies all work necessary to accomplish the business analysis
Identifies only necessary work, thereby increasing efficiency
Identifies specific work packages for estimating and assigning
work tasks
Provides a quality structure for measuring success
Forces detailed planning and documentation
Clarifies responsibilities
The most effective method for identifying WBS tasks is the top-down
method. Top-down planning identifies the projects major deliverables.
Planning is executed from general (higher-level) tasks to specific (lower-
level) tasks. Most project managers use this approach.
When building the WBS for the analysis, do not do so alone. It is
important to develop the WBS as a team and to make sure that team
members understand the business opportunity, vision, and high-level
scope. Below are a few more guidelines to follow when building the
WBS for the analysis:
1. Establish major work components of the Analysis phase.
2. Break each identified work component into smaller, more
manageable components with no regard to sequence.
3. Continue breaking down the work until you reach a level where
activities can be assigned to a team or individual (approximately
4080 hours each).
4. Conduct a review session (walk-through) with the key resources
(those who will be participating in the analysis work) to validate
your work.
Breaking Down the
WBS

ESI 77

5. Prepare a WBS dictionary for each work package to provide
additional information needed to carry out the work of the
activity, such as assumptions, dependencies, or constraints. Be
sure to keep the WBS dictionary updated as more information
presents itself.
Information presented in the WBS can be displayed in many ways. When
choosing a format, consider the preferences of your audience. Two
common formats are indented (much like an outline) and graphical. The
following example shows a WBS for planning requirements analysis.

For easy tracking and monitoring, each item listed in the WBS can be
assigned a number. The numbers should be assigned after each
component has been broken down to the desired level of detail. The
same numbering scheme is applied to other documentation during the
analysis for traceability, including the budget, resource plan, and other
sections listed in the RWP, for example.
To number the project, first identify the project by number. Then,
number each major component as a subset of the project. For example,
1.1, 1.2, 1.3, 1.4, and so on. Continue this breakdown to the work
package level as shown in the following example.
Breaking Down the
WBS (continued)

ESI 78

Once a number is assigned to a work package, do not change that
number. If the work package is deleted, simply mark it as no longer
applicable. If a new work package is added, give it a new number. This
prevents confusion with version control after changes have been applied.
After the WBS is complete, the BA develops the schedule. The first step
in this task is to sequence the activities using the precedence diagram
method (PDM). This network diagram technique consists of boxes
(activities including WBS reference numbers) that are linked together via
arrows representing the flow, or order, in which the activities need to be
executed. The flow diagram shows both serial work flows and parallel
work flows where appropriate.
After the sequence is established along with any parallel paths, the
duration for each activity is stated, and the longest path in duration is
calculated (critical path). Some activities can have lag start times and
need to be taken into consideration when calculating the critical path or
paths.
Breaking Down the
WBS (continued)
Developing the
Schedule

ESI 79
Using the PDM, the BA can then assign actual dates, adjusting each date
per the durations and lag times. The PDM can then be transferred to a
scheduling tool called a Gantt chart where that BA can add milestones of
significant accomplishments that are highlighted to the business sponsor
and project manager. The WBS reference numbers are carried through
the Gantt chart for traceability; this helps the BA maintain consistency
throughout the process.
The schedule is included in the RWP and made available to the project
team. The project manager conducts the same exercise for the entire
project and can be consulted about schedule development.

Encouraging User Involvement
One of the top-three reasons for project failure is lack of user
involvement. As a BA, you must pay particular attention to your users
(who should be identified as critical stakeholders). Users are the group
that will ultimately make or break your projectthey have the most to
gain or lose because of your project. Setting and managing user
expectations and encouraging user involvement is a critical part of the
BAs communication role in the analysis process. The practical goals of
this part of the process are
Enabling user participation, thereby building a foundation for user
ownership, increasing user acceptance for new solutions, and
minimizing resistance in change processes
Giving users the opportunity to provide input into the process to
facilitate the development of usable, user-friendly solutions, in
line with the requirements of all relevant user groups
Obtaining buy-in, support, and a common understanding among
the business analysis team; the project team as a whole; and users
to reduce the risk of creating a solution that does not work
Developing the
Schedule (continued)

ESI 80
Encouraging User Involvement (continued)
The creation of the RWP is really the beginning of the BA relationships
with the customer/user groups. They need to have input to the process:
what is going to be done, what is being done, and what has been done.
In planning the requirements elicitation, the BA role must be established
as early as possible. For example, when the business sponsor approves
the RWP, the BA can ask for a letter of introduction to all participants as
to the nature of the project and the need for user involvement. This letter
gives referential authority to the BA for setting up the elicitation, and
most importantly, it sets user expectations. This letter can also help
prevent conflicts as the business analysis team works in various
organizational areas to elicit requirements.
The BA must be proactive in this relationship, making sure that users
understand that the process needs their input and participation. In
particular, users need to know the following:
The BA and analysis team elicit and document requirements
related to a business opportunity.
The BA and analysis team do not create requirements;
requirements must come from the users.
The goal of the analysis is to elicit all requirements from the
relevant user groups, although various constraints may prevent all
requirements from making it into the final solution (this situation
may lead to subsequent releases or versions as in the case of
iterative development).
User feedback is critical for validating and prioritizing
requirements during the development of the BRD.
Skillful communication in the form of setting and managing expectations
and encouraging user participation goes a long way toward ensuring the
ultimate success of the project. However, this process requires strong
commitment to the user groups from the BA. Users know whether that
commitment is there, so if you ask for feedback, be prepared to use it.
As part of the communication process, the BA needs to determine who
the project stakeholders (including users) are and how they may affect the
outcome of the analysis.
A potential stakeholder is anyone who is actively involved in or
influential to the project, or who is affected by the proposed solution.
When brainstorming a list of stakeholders, the BA must ask who
Revision Log
Identifying
Stakeholders

ESI 81

Provides the input?
Gets the output?
Has oversight?
Has other related responsibilities?
Reaps the rewards?
Suffers the consequences?
Thinks they are affected by the project?
Common stakeholders include analysis team members, the project
sponsor, the business sponsor, end users, business area management that
will be affected by the solution implementation, regulatory agencies,
project team, and so on. The AS-IS business analysis completed during
scope definition is a good place to look for stakeholders who might
otherwise be missed.
Remember that all stakeholders do not have the same influence on the
project. Identify those stakeholders with the most influence and make
their involvement a priority. Make sure you can explain the benefits of
the project to stakeholders. Doing so eases the transition into
requirements elicitation.
Another aspect of stakeholder identification is prioritizing stakeholders.
This task is especially important on a complex project with many
stakeholders expressing competing demands. To ensure project success
and plan a stakeholder management strategy, the BA must analyze which
stakeholders are most important to the project. Other criteria, such as
accessibility, knowledge, technical expertise, and domain expertise,
should also be considered when prioritizing stakeholders.
Prioritizing stakeholders involves ranking each according to their power
(level of influence) over the project and their level of interest or concern
(how important the project is to them). Plotting the resulting scores on a
simple grid provides a snapshot of the importance of each stakeholder.
For example:
Identifying
Stakeholders
(continued)
Prioritizing
Stakeholders

ESI 82

Stakeholders in the upper-right quadrant (high power, high interest) are
primary stakeholders. Stakeholders in the upper-left (low power, high
interest) and lower-right (high power, low interest) quadrants are
secondary stakeholders. Stakeholders in the lower-left quadrant (low
power, low interest) are tertiary stakeholders. Categorizing stakeholders
allows the team to concentrate management efforts on the primary
stakeholders, while still keeping other stakeholders in view.
Profiling Users
The process of identifying the broad categories of users for the business
solution is an essential step in planning the analysis. The identification of
users assists in the validation and clarification of analysis scope and
serves as a catalyst for planning analysis activities.
Prioritizing
Stakeholders
(continued)
The Importance of
User Profiling

ESI 83
Profiling Users (continued)
Every product, system, or service has end users, and the analysis and
documentation of user requirements must begin by defining who those
users are. If the team does not clearly identify the users, the requirements
elicitation process (and the resulting solution) will fail.
As part of the analysis resource plan, the analysis team develops user
profiles to identify those users and user groups who will participate in the
requirements elicitation. Identifying users and creating profiles is a team,
not an individual, effort. When one person creates the profiles, the
profiles tend to be biased toward that one individual. When the entire
team or even the stakeholders are enlisted, the profiles will be more
richly defined and less prone to personal bias.
At the highest level, the project has two main types of users: primary and
secondary. Primary users are those whose core job or task requirements
depend on the solution. An inability to perform these tasks results in
project failure.
Secondary users are those who may interact with the solution as part of
their jobs, but not as a core function. This group also includes those who
may benefit from the solution without using it at all. (For example,
supervisors read performance reports about an improved point-of-sale
system, but do not directly use the system.)
Some ways to identify various users are to
Ask organizational management who will be affected by the
solution implementation
Look at the AS-IS models of business processes that the solution is
intended to improve and identify those responsible for and
affected by the processes
Include customers of the organization; although they may not
necessarily be using the solution, it will affect them
Include anyone who will be responsible for developing or
maintaining the solution
Capture any regulatory or certification authorities who may have
mandatory requirements (constraints) for the solution
Review the list of project stakeholders for any additional or
missed groups
The Importance of
User Profiling
(continued)
Types of Users

ESI 84
Once all primary and secondary users have been identified, the BA
classifies them further by identifying common characteristics and
attributes among user groups. Some of the ways to classify users
include
Corporate job function
Marketing
Shipping and receiving
Accounting
Customer service
Manufacturing
Company relationship
Management
Staff
Customer
Contractor
Supplier
Nature of interaction with the solution
Supplier
Data entry
Data analysis
Research and development
Operator
Physical work environment
Where: office, outside, underwater, at home
When: time of day, shift, week, month, year when activities
normally occur
Technology used
High technology: computers and networks, handheld devices,
e-mail, document management systems
Mid technology: fax, photocopy, telephone
Low technology: hard-copy reports and forms, in baskets,
traditional mail
These classifications help the BA plan the most appropriate elicitation
strategy for each user group. They may also help identify additional
challenges or constraints that need to be documented as part of the
process.
Profiling
Characteristics and
Attributes

ESI 85
While planning the requirements elicitation strategy, the BA may use
additional differentiation factors such as
Level of education
Level of computer literacy
Level of expertise at work task
Language
Geographic location
Cultural norms
Recognizing and planning for these types of differences can be critical in
the success of the requirements elicitation. For example, the BA does not
want to plan a survey as part of the elicitation only to discover that the
group being surveyed does not read the language in which the survey
was written.
Once the team has defined the user groups, the next critical step in user
profiling is to define users goals and expectations for the solution. For
example
End goals: What does the user specifically hope to achieve
through the solution in terms of productivity, efficiency,
improvements over the current system, or quality?
Practical goals: What overall benefit does the user expect from
the solution? Customer satisfaction? Problems solved?
Business goals: What business goals does the user envision for
the solution in terms of profitability, market share, security, or
growth?
Experience goals: What would make the system a positive
experience and cause the user to recommend its use?
Uncovering and documenting what users expect from the solution helps
keep the requirements focused on their needs and also aids in the
ongoing process of setting and managing expectations. Users expect the
new system to improve productivity, efficiency, and the quality of the
work they do on a daily basis.
The business analyst also must consider the overall benefit that the
solution is expected to achieve, making sure customers are satisfied, the
problem was solved, and the business goals were met in terms of
profitability, market share, security, or growth as a result of the solution.
Defining users experience goals is a critical, though often overlooked,
part of user profiling. Users emotional perceptions of the solution and
what would make them recommend its use can have a tremendous effect
on project success.
Profiling
Characteristics and
Attributes (continued)
User Goals and
Expectations

ESI 86
Managing Risk
The BA makes risks visible through the requirements elicitation and
documentation process, providing critical decision support for the
business sponsor, who ultimately defines the level of acceptable risk. All
projects are risky, and high-risk levels may be acceptable under certain
business circumstances. The project team should reevaluate risk levels on
a plan-versus-actual basis at project milestones such as the creation of the
RWP and BRD. Business analysis can lead to project cancellation if it
uncovers items representing unacceptable risk.
A risk is any possible, future event that may affect the project in some
way. Risk can be either positive (an opportunity) or negative (a threat).
Risk consists of three factors:
Risk event
Probability, or likelihood, that the risk will occur
Impact on the project if the risk does occur
Risk management planning is the process of deciding how to identify and
manage possible risk events that might affect project goals. Good
planning prepares team members for even the most serious threats that
occur during the project; it also prepares them to take advantage of any
opportunities that arise.
Planning for risk begins during project or phase initiation and should
continue throughout the life of the project. The amount of effort
expended on risk management should be equivalent to the level of risk
involved and the importance of the project to the organization.
As part of the planning process, the BA needs to identify and analyze
risks to the Analysis phase. Risk analysis involves analyzing the
probability that identified risk events (both good and bad) will occur and
what the impact of those events will be on project success. The end result
is a prioritized list of risks that allows the analysis team to focus on the
most important risks when planning response strategies.
The analysis team must classify risks based on probability and impact.
Risks that fall within the green boxes (7, 8, 9) should present few worries
if they are not addressed. Risks that fall within the mixed boxes (4, 5, 6)
should be addressed. Risks that fall in the red box (1, 2, 3)those with
the highest probability and impactmust be addressed. The number in
the lower left corner of each box indicates the relative importance of that
placement, with 1 being most important and 9 being least important.
What Is Risk?
Risk Management
Planning
Prioritizing Risks

ESI 87
Managing Risk (continued)

Part of risk planning involves developing a set of strategies and specific
actions that may be implemented to enhance specific opportunities and
reduce significant threats to project objectives in the face of risk. Risk
response strategies that address threats typically fall into the four
categories shown below:
Avoid: Generally consists of changing the project plan to
eliminate the threat (for example, revising the schedule to include
more time for the work or revising scope to eliminate risky
activities). This strategy is typically used for adverse risks that
have both a high probability and a high impact.
Transfer: Shifts the impact of an adverse risk event to a third
party. Some examples include writing fixed-price contracts with
vendors and taking out insurance policies.
Mitigate: Seeks to reduce the probability or impact of adverse risk
events to an acceptable threshold. Examples include adding an
extra programmer to a software development project to reduce
the likelihood of finishing late, building a prototype to test a
concept before production, or identifying secondary suppliers for
required materials.
Prioritizing Risks
(continued)
Risk Response
Strategies

ESI 88
Managing Risk (continued)

Accept: Consists of simply dealing with consequences of an
adverse risk if it happens, either actively (by developing a
contingency plan) or passively (just dealing with the
consequences of the risk if it happens).
There are also four strategies for responding to opportunities, or positive
risk events:
Exploit: Ensures that the opportunity is realized. It seeks to
eliminate the uncertainty associated with a particular risk by
making the opportunity happen, for example, by assigning more
talented resources or providing better quality than originally
planned.
Share: Allocates ownership to a third party who is best able to
capture the opportunity. This involves creating risk-sharing
partnerships or joint ventures with the express purpose of
managing opportunities.
Enhance: Seeks to increase the probability of an opportunity, by
identifying and maximizing key drivers of these positive impact
risks. It seeks to facilitate or strengthen the cause of the
opportunity.
Accept: Dealing with a risks consequences either actively or
passively, for example, deciding not to change the project plan to
exploit or enhance an opportunity because the gain or advantage
is small.
In summary, the strategies chosen for risk management will vary with the
individual risk, its importance to project goals, its probability and impact
ratings, and whether it is a threat or an opportunity.
Risk Response
Strategies (continued)

ESI 89
Chapter Summary
The RWP is the mini project plan for developing the BRD
and is a negotiating tool for evaluating risks when
considering changes to the plan.
To ensure accountability, the project manager and the
business sponsor must sign off on the RWP.
The BA can use a WBS to determine the tasks that need to
be included in the RWP.
The WBS is used as the basis for creating a precedence
diagram and schedule.
The RWP schedule and budget is a bottom-up estimate of
the analysis effort and needs to be reconciled with the top-
down estimate given in the vision and scope report.
Stakeholders and users need to be identified and profiled to
ensure the elicitation process is effective.
Risks for conducting the Analysis phase need to be
identified and managed.

ESI 90
Requirements:
listed.
Next-Steps Action
Plan

ESI 91
How to Gather and Document User Requirements Chapter 4: Developing the Requirements Work Plan

Action Plan:
Apply what you have learned about developing the requirements work plan by developing a list of actions you will complete when you
return to your organization.
Questions
to Consider:
How can I plan for capturing requirements for a solution within my organization? Who should I involve in the planning process?
How can I ensure my requirements work plan addresses risks to the requirements?

Time
1.

2.

ESI 92
Time
3.

4.

5.

ESI 93
Requirements Elicitation
Reference Material
The key to business analysis is the requirements elicitation. This chapter
introduces 10 techniques for requirements elicitation.
Chapter Overview
5

ESI 94
Requirements Elicitation
Overview of Requirements Elicitation
The key to business analysis is the requirements elicitation. Requirements
are the link between the AS-IS and the TO-BE, and among the business
goals and drivers and the architecture, processes, products, and people
that make up the final solution. The quality of the solution depends
almost entirely on the requirements elicitation and subsequent
requirements analysis and validation. Without a complete and accurate
representation of all requirements that the solution must possess, the end
result will be a solution that does not fully satisfy the needs of the
business and/or the end users.
The basis for the requirements elicitation is the work already
accomplished on the vision and scope report and the requirements work
plan. The analysis team should emerge from those activities with a clear
understanding of business goals, identification of stakeholders and user
groups, and plan for the requirements elicitation.
Requirements elicitation is an iterative process, in which user groups and
other stakeholders serve both as the source and to validate solution
requirements. The elicitation and validation processes will feed each
other as the analysis team works through eliciting, structuring,
documenting, and validating requirements on the way to building the
business requirements document (BRD). Some keys to success in the
requirements elicitation process are
Do not expect to capture requirements in a single passanalysis
and validation will lead to additional elicitation needs as you go
Involve stakeholders throughout the processthey will help
validate requirements in addition to serving as a source of
requirements
Ensure that all requirements can be traced back to business goals
Ensure that all requirements can be measured or decomposed
into measurable requirements
Ensure that all requirements have an owner (that is, someone
who will confirm that the requirement has been met)
The following diagram shows a simplified view of bidirectional
traceability for a set of requirements.
Introduction
4 5

ESI 95
Overview of Requirements Elicitation (continued)
Functional
Requirement
1.1.1
Nonfunctional
Requirement
1.1.2
Functional
Requirement
2.1.1
Functional
Requirement
3.1.1
Functional
Requirement
3.1.2
Nonfunctional
Requirement
3.1.3
User
Requirement
1.1
User
Requirement
2.1
User
Requirement
2.2
User
Requirement
3.1
Business
Requirement
1
Business
Requirement
2
Business
Requirement
Y

Given this set of requirements, some areas for investigation in the next
iteration are the following:
Business Requirement Y has no requirements, pointing to the
need for additional elicitation to uncover stakeholders and/or
information to support its existence.
User Requirement 2.2 has no decomposed requirements, which
indicates a need to confirm with the requirement owner that it is
completely measurable as it stands.
Although it has been decomposed into derived requirements,
User Requirement 3.1 does not trace back to a business
requirement, pointing to a need for further clarification or
perhaps an indication that the requirement does not align with
business goals.
The iterative nature of the process allows the analysis team to check and
validate requirements as they go, filling in blanks and links, and ensuring
that all stakeholders are in agreement as to the elicited requirements and
the relationships among them. The BA needs to make certain that the
same process is followed during the Design phase, ensuring that each
specification traces back to a validated requirement.
Introduction
(continued)

ESI 96
Few would argue with the wisdom of consulting a doctor about a health
problem. Generally, the patient consults a doctor, expects the doctor to
perform a proper diagnosis by investigating the problem through various
tests and questions about the problem, and then, based on the diagnosis,
expects the doctor to prescribe a course of treatment to correct the
problem. If the patient is comfortable with the doctor and feels confident
that the doctor has used the proper methods to arrive at this conclusion,
the patient will proceed with the course of treatment recommended. The
patient probably also expects to receive the proper support throughout
the diagnosis and treatment processes and to feel that the diagnosis,
treatment, and solution are appropriate.
The same holds true for business analysis. Having a diagnostic mindset
greatly enhances the BAs ability to gain the trust of stakeholders and
elicit complete, correct, and usable requirements. Just as a doctor
consults with a patient to discover the underlying cause of the patients
symptoms before deciding on a treatment, the BA must consult with
stakeholders to understand the current situation/problem and
requirements before developing a solution. So, for example, when a
stakeholder frames an initial requirement as, We need three new fields
in the order table, the stakeholder has, in effect, already prescribed a
treatment, skipping the critical steps of investigating symptoms and
diagnosing the real problem. It is up to the BA to apply a diagnostic
mindset in order to diagnose and address the real problem, which may
be something more like, Customers are unable to track the status of their
orders.
The elicitation seeks to uncover internal processes within the AS-IS
situation identified during visioning and planning the requirements work.
Diagnosis enables the BA to identify the actual problem or need for
change. The treatment plan or TO-BE will be the design or selection of a
solution; this is where the systems analyst takes over. The benefits of the
diagnostic mindset are that it
Prevents the analysis team and stakeholders from making
assumptions about the solution before they understand the
current situation
Structures the elicitation so it moves from the known (AS-IS) to
the unknown (TO-BE)
Paves the way for a successful requirements elicitationthe more
you know, the more accurate the solution is likely to be
Addresses the real problem, leaving maximum room for experts
to find the best possible solution
Diagnostic Modeling

ESI 97
Normally, there is not enough time in the requirements elicitation
process to talk to everyone about every aspect of the solution vision.
Therefore, the analysis team must focus the elicitation on those
stakeholders most likely to provide the information needed. For example,
regulators and management will likely have the highest level of accuracy
on regulatory and business-level requirements, but would not be as good
a source on user requirements, while end users and maintainers are the
best source for user, functional, and nonfunctional requirements, but
would have a lower level of accuracy for regulatory requirements. The
diagram below shows the continuum from regulatory and business
requirements to users, functional, and nonfunctional requirements.

The key is to elicit requirements from the extreme ends of the customer
continuum and work in toward the middle as time allows. Both
management and end user needs must be represented to ensure that the
BA captures both the strategic (visionary) and the operational (day-to-day)
requirements for the solution.
Modeling can be a valuable tool in requirements elicitation to help clarify
and communicate requirements. In an observation, for example, the BA
may find it helpful to sketch a workflow model or activity diagram of the
process rather than trying to capture each step in a purely text format.
The resulting model will help identify areas for further investigation such
as possible business rules, gaps in the process, and possible alternative
process flows.
Some tips for the effective use of modeling during requirements
elicitation include
Model in groups: Modeling can be an effective way to talk
through issues and explore alternatives. In a group setting, use a
whiteboard and take digital pictures of any models you want to
preserve.
Levels of Source
Accuracy
Modeling and
Requirements
Elicitation

ESI 98

Experiment with different models: Some models lend themselves
easily to particular applicationsfor example, using an activity
diagram to capture a business process during an observation, or a
use case diagram to capture system interactions described in an
interview. However, each model has its strengths and
weaknesses, and the model you start out using may not end up
being the best display of the data captured. If you get stuck,
switch to another model to change focus and open up new
possibilities.
Use multiple models: You may find your issue requires the use of
more than one model simultaneously.
Use the tools at hand: Perfectly adequate models can be drawn
on the back of a cocktail napkin. Do not avoid modeling simply
because you are not sitting at your desk in front of a computer
with a high-end modeling program.
Share your models: Give other team members and stakeholders a
chance to see and comment on models. They may have insights
you have missed.
The requirements elicitation is complete when the business sponsor has
enough support information to make an acceptable risk go/no-go
decision. Some BRDs are hundreds of pages in length, and some are no
longer than the template used to build them. The level of detail captured
will depend on both the triple constraint and the risks associated with the
project.
While this may sound a bit like saying the elicitation is done when it is
done, remember that the process is iterative and the team will continue
eliciting, structuring, documenting, and validating requirements until the
requirement set is sufficient for developing or deciding on a solution (that
is, the risk tolerance of the business sponsor has been reached). By
working with the business sponsor and other stakeholders on an ongoing
basis to alleviate fear and create comfort around the decision, the BA
builds the BRD concurrently with the requirements elicitation. The end
result is a well-documented, comprehensive set of prioritized
requirements that contains no surprises for stakeholders in its final
review. This iterative, diagnostic approach helps ensure
More complete requirements documentation
Fewer requirements changes during development
A shared vision among stakeholders throughout the project life
cycle
Control of scope creep
Modeling and
Requirements
Elicitation
(continued)
When Are You Done?

ESI 99
Elicitation and Validation Techniques
A number of techniques are available for eliciting requirements. This
course introduces 10 techniques, summarized in the list below and
described in greater detail in the following sections. Each technique has
its advantages and challenges, so the BA must be able to use several
techniques comfortably, adapting them to the situation, in order to
become adept at requirements elicitation. The 10 techniques are
Reviewing the AS-IS
Research
Observation
Verbal protocols
Survey Techniques
Interviews
Questionnaires
Facilitated Techniques
Focus groups
Brainstorming
Joint application design (JAD)
Product-based Techniques
Product evaluation trials
Prototyping
Inevitably, the analysis team will run into challenges in the elicitation.
These challenges may include issues related to the availability of
stakeholders for elicitation activities, uncertainty surrounding what the
solution needs to accomplish, and stakeholder bias and disagreement
over requirements. The following table lists some of the barriers to
requirements elicitation the analysis team is likely to encounter and some
ways to overcome them.
The BA Toolbox
Dealing with Barriers
to Elicitation

ESI 100
Elicitation and Validation Techniques (continued)

Barrier to elicitation Strategy for overcoming barrier
Stakeholder unavailability
Communicate to management and
stakeholders that they are a critical part
of the requirements elicitation process.
Make sure stakeholders understand that
they will need to invest time in the
process.
In the case of geographical dispersion,
try to colocate stakeholders for at least
part of the elicitation process.
Alternatively, send members of the
analysis team to stakeholder locations to
work with them on requirements
elicitation.
Stakeholders do not know
what they want
Stay focused on the solution vision.
If the vision is vague, begin by focusing
on aspects of the solution that are most
clearly defined.
Make use of modeling techniques to
explore/clarify stakeholders needs and
what is important to them, especially
when stakeholders have trouble
envisioning a change from the AS-IS.
Embrace change during the elicitation
stakeholders will change their minds as
they improve their understanding of the
process and possibilities. The purpose of
the elicitation is to build the best set of
requirements possible, not to discourage
improvement as the elicitation
progresses.
If stakeholders are afraid to commit to
requirements because they might be
wrong, reassure them that the process is
iterative and the requirements will
evolve over time, providing the
opportunity for improvement and
correction.

to Elicitation
(continued)

ESI 101
Elicitation and Validation Techniques (continued)

Too many stakeholders Thank everyone for their enthusiasm.
Select the best people for the
elicitation, making sure that all key
stakeholder groups have sufficient
representation.
Remember that those stakeholders with
whom you are working most closely
may become too attached to the
requirement elicited to provide an
unbiased view of potential problems.
Stakeholders are focused
on solutions, not
requirements
Ask the right diagnostic questions (who,
what, why, when, where) to try and
shift the focus from solution to
requirement.
If that does not work, elicit beyond the
solution statement, If you had that
solution in place, what would you do
with it?
Stakeholder bias Elicit requirements from a wide range of
stakeholders to ensure you get a
balanced view of the solution.
Use requirements gap to determine if
you are missing a critical stakeholder or
user group.
Reviewing the AS-IS
Techniques for reviewing the AS-IS include research, observation, and
verbal protocols. They involve looking at the current situation through
either research or direct observation. These techniques are useful for both
uncovering potential requirements and improving analysis team and
stakeholder understanding of the current situation.
to Elicitation
(continued)
Overview

ESI 102
Reviewing the AS-IS (continued)
Research involves looking through business and business-related
documentation in search of relevant information that can be applied to
the current project. Often, a wealth of information is available to the
analysis team, such as
Current system documentation (policy, operating manuals,
standards documentation, human resources documentation, and
so on)
Archived files from similar past projects (contracts, statements of
work, requests for proposals)
Existing models (AS-IS models that were done in the past, such as
logical data models, use case diagrams, workflow models,
functional decomposition models)
Business plans, market studies
External Web sites or documentation on similar systems
Textbooks covering the solution domain
Lessons learned database
Successfully researching the past depends on the availability of legacy
information, the currency and relevance of information gathered with
regard to the current situation, and having enough time to do the
research. Some advantages and challenges of the technique are that it
Advantages Challenges
Provides insight into how the
organization arrived at the
current AS-IS state (internal
research)
May reveal windfalls in
previous work, documentation,
or partially completed systems
that can be reapplied to the
current project (internal
research)
May identify organizations that
have already solved the
problem under investigation
(external research)
May uncover requirements that
may not occur to internal
stakeholders (external research)
Can be time-consuming, with
no guarantee of finding
anything useful
Is less likely to prove relevant
in the current situation if the
information is old
Often differs from what is
written down
Research

ESI 103
This technique involves obtaining data from direct observation of the
processes, activities, or behaviors. Observation allows the analysis team
to capture natural task performance data, along with significant
audiovisual events, in a format that makes subsequent analysis easier.
Depending on the situation, the BA may choose to conduct either a
direct observation (in which the observer is physically present and
interacts with the conducting of the test scenario) or an indirect
observation (in which the observer uses some medium such as audio or
video to capture the observation). In either case, the BA must be careful
when scheduling the observation in order to cause the least intrusion
possible.
In general, the more honest the observer can be about conducting the
observation the better. Being able to be up front about the elicitation
process will help gain user support and allow the BA to schedule the
observation at a time convenient to all participants; however, there will
be times when the observer must remain anonymous to avoid
compromising the results.
Some advantages and challenges of observation are that it
May reveal information that
cannot be acquired any other
way (or that you would never
think to ask)
Allows the analyst to become
more familiar with the task
Can be used to identify and
explain individual differences
in task performance
Provides objective information
that can be compared with
information collected by other
observers or methods
Can capture information that
would otherwise go
unrecorded or unnoticed
Affects what, or whom, is being
observed; subjects may alter
their behavior in the presence
of an observer
Requires strong interpersonal
skills on the part of the
observer (in direct
observations)
Can require considerable effort
to structure raw data collected
Does not provide information
about underlying thought
processes and is of little use for
cognitive task analysis
Observation

ESI 104
The verbal protocol, or thinking aloud technique, also uses direct
observation to examine processes, activities, and behaviors. In verbal
protocols, the analyst observes the worker while the worker describes
actions being taken during the process. The worker in effect trains the
observer in how to perform the work under observation.
This technique depends on users spoken comments as they verbalize
how they use the system, explaining what they are trying to do and the
type of problems they experience. The analyst can collect verbal
protocols using video or audio recording or direct notes. In order for
verbal protocols to be successful, the verbalizations must not interfere in
any way with task performance, and users must be able to freely report
on what they are doing without any direction. Like all direct observation
techniques, the BA schedules verbal protocol sessions in advance to
minimize disruption in the workplace. It may even be to the BAs
advantage to ask users to practice their commentaries prior to the actual
observation session.
While verbal protocols can be effective under certain situations, they can
also be highly disruptive and the technique should be used with caution.
Some advantages and challenges of the verbal protocol technique are
that it
Is good for identifying common
errors users make
Provides access to more
information on underlying
thought processes
Helps to identify expectations
or preconceptions users bring
to the process
Provides insights into the
decisions that the worker has to
make and the variables that
influence decision making
Helps to identify differences
between models of how a
process operates and how it
actually operates in practice
Disrupts task performance
ask the worker to practice the
commentary before you start
collecting data
Can disrupt others in the work
environment
Depends heavily on the
subjects ability to articulate
actions and thoughts and to
stay on task during
commentary
Is time-consuming because the
analyst can only work with one
person at a time
May be an inadequate
descriptive technique for the
process under investigation
Verbal Protocols

ESI 105
The key to using observation techniques successfully is to minimize the
intrusion experienced by the user. In some cases, using a combination of
techniques can help. For example, in an observation of a complex, highly
cognitive task, the analyst may want to videotape the user performing the
task (indirect observation), and then sit down with the user and have the
user explain the task and thought processes behind the actions while
watching the videotape (a variation on verbal protocols).
Survey Techniques
Survey techniques include interviews and questionnaires and involve
asking questions to gather information. These popular techniques are
used to gather a wide range of information.
Interviews are one of the most common techniques for requirements
elicitation. Interviews use two primary formats: informational or survey.
Informational interviews are helpful in gathering a wide range of
information on a particular task or situation. Survey interviews are helpful
in collecting data in a more systematic and codified way, much like a
questionnaire.
The type and order of questions asked can be critical in determining the
success of interviews. Consider these four broad categories of questions:
Question Type Characteristics
Open-ended Expects an elaboration for an answer
Encourages the speaker to share information,
expand on an idea, or give further details
Often uses words such as what, why, how, tell
me about to elicit more information
Verbal Protocols
(continued)
Overview
Interviews

ESI 106
Survey Techniques (continued)

Closed Expects a simple, to-the-point yes or no, the
selection of an alternative, or an exact amount
as a response
Used when looking for a specific piece of
information or when time is not available to
explore the issues fully
Often uses words such as which, who, where,
when, how many/much/often
Helps to narrow down answers, confirm
understanding, seek specific details, and
provide more concrete focus to an interaction
Clarifying Used to get the other person to expand on or
clarify his or her comments
Ensures that you have clearly understood what
the other person has said
Often begins with Can you give me an
example of
Demonstrates your respect and willingness to
listen
Is particularly important when linguistic or
cultural differences could easily lead to
misunderstanding; or when you are under
pressure, in a hurry, or distracted

Interviews
(continued)

ESI 107

Confirming Used once you are confident that you fully
understand the message being sent
Used to confirm your understanding and receive
an acknowledgment from the other person that
you have indeed captured the essence of the
message, so that you can move on to the next
step
Often involves paraphrasing or restating what
the other party has said in different words
Increases awareness of areas where you and the
other person agree and disagree
When conducting interviews, a general strategy is to begin with open-
ended questions; narrow down answers to gain details and facts with
closed questions; use clarifying questions to elicit examples, definitions,
and exceptions; and finally, ask confirming questions to ensure mutual
understanding of the information elicited. If you detect problems, move
back a level in your questioning. Some general guidelines for
interviewing are
Make an appointment with the person to be interviewed and be
on time
Write your questions down but be prepared to deviate from your
list, if necessary
Be confident but not overbearing
Maintain control of the situation to ensure feedback remains
relevant to the situation
Use context-free questions (that is, questions that do not suggest a
particular response)
Do not interrupt
When you are finished, thank the interviewee for his or her time
Successful interviews depend on preparation, flexibility, question quality
and strategy, environmental factors, ability to accurately record results,
and the use of confirming questions and statements to verify
understanding. Potential interviewers must develop and assess their
interviewing skills before beginning work in critical situations.
Interviews
(continued)

ESI 108
Some advantages and challenges of interviews are that
Respondents are usually very
comfortable with the interview
process
The interviewer can adjust to
the individual and deal with
unexpected information and
revelations
Interviews are usually fairly
easy to arrange in the normal
workplace
They use a flexible format,
allowing follow-up of new
points and interesting lines of
discussion, if time permits
Interviewing encourages buy-in
from participants
One-on-one interviews can be
time-consuming
Subsequent analysis can be
time-consuming
The interviewer must guard
against focusing on routine
aspects of the task or situation
Personal biases may affect the
interview, depending on the
relationship established
between the interviewer and
respondent
What people say is often very
different from what they do
The interviewer may need to
acquire domain knowledge in
order to know what questions
to ask and to understand the
responses
Questionnaires offer a less personal approach than interviews and are
more suitable for isolating problems and gauging opinions and attitudes
toward a system. This technique is especially appropriate for sampling
responses from a large number of users and prioritizing requirements
later in the analysis process.
When developing questionnaires, the analysis team should
Start with a well-defined objective to help keep your survey
design on track.
Ask only questions that directly address your survey objectives;
avoid asking questions about things that would be merely
interesting to know.
Interviews
(continued)
Questionnaires

ESI 109

Plan how you will analyze the questionnaire results. If you
cannot plan how to analyze a question or use the information
elicited, throw it away.
Remember that long questionnaires get fewer responses than
short questionnaires. The most effective way to raise your
response rate is to keep your questionnaire short.
Provide a well-written introduction or cover letter. This sets
expectations and is your best chance to persuade the respondent
to complete the questionnaire.
Include clear instructions on completing and returning the
questionnaire.
Thank the respondent for completing the questionnaire
(especially if you ever want them to complete another one).
Provide a meaningful incentive for completing the questionnaire.
Use words familiar to the user in short sentences.
Use positive questions; avoid the use of negatives.
Carefully plan questions on sensitive issues (if necessary, ensure
anonymity or confidentiality for the respondent).
Avoid expressing personal bias.
Avoid leading questions.
Move from simple to more complex questions.
If comments are appropriate, be sure to leave enough space for
the respondent to make them.
The types of questions asked can be critical in determining the success of
interviews. Consider these six broad categories of questions:
Question Type Characteristics
Dichotomous Have respondents choose between two
answers. For example
Have you ever eaten in our restaurant?
Yes No
Questions are usually yes/no or true/false type
questions.
It may be used to screen respondents into
different groups.
Questionnaires
(continued)

ESI 110

Multiple choice Have respondents choose among three or more
exhaustive, mutually exclusive answers. For
example
How many times have you eaten in our
restaurant in the last year?
1 2 3 4 or more
Allows for easy analysis
Must be carefully worded to avoid ambiguity
and misunderstandings
Rating scales Give an indication of the nature and magnitude
of users opinions about certain tasks or
experiences. For example
Which of the following best describes your last
experience eating in our restaurant? Would you
say that your experience was
Very pleasant
Somewhat pleasant
Neither pleasant nor unpleasant
Somewhat unpleasant
Very unpleasant
Are very sensitive to subjective bias and
distortion
Should have no more than seven alternatives
Have response intervals that should be as equal
as possible
Questionnaires
(continued)

ESI 111

Paired
associates
Have respondents decide which of two specific
alternatives is the most appropriate. For
example
In each of the following pairs of words, pick the
term that best describes our restaurant:
1. noisy lively
2. crowded popular
3. lively exciting
Can be highly effective when alternatives are
paired in a variety of ways
Ranking Have respondents order items according to
some specific criterion. For example
Based upon what you have seen, heard, and
experienced, please rank the following
restaurants according to their quality of service.
Place a "1" next to the restaurant that has the
best service, a "2" next to the restaurant with
the next best service, and so on. Remember, no
two restaurants can have the same ranking.
__ Restaurant A
__ Restaurant B
__ Restaurant C
__ Restaurant D
Is very reliable if there are no more than 10
alternatives
Questionnaires
(continued)

ESI 112

Open-ended Have respondents write own answer or
comments on the question
Seeks to explore the qualitative, in-depth
aspects of a particular topic or issue
Requires increased effort on the part of the
analyst to organize useful information
Can be useful to put one open-ended question
at the end to allow respondents to comment on
anything else they would like to add
In order to obtain the most accurate, unbiased results from a
questionnaire, the analysis team may want to consult a survey specialist
to determine sample size and have the questionnaire validated prior to
distribution. At minimum, the analysis team tests the questionnaire
internally to check for problems and bias. Several good sample size
calculators are available online. (Just search for sample size calculator
using the search engine of your choice.)
Questionnaires are either paper or Web-based. Web-based surveys offer
the ability to reach large numbers of respondents quickly, and they can
be integrated with automatic scoring tools; paper surveys can be
completed by a worker anytime and anywhere with no special
equipment required.
Questionnaires
(continued)

ESI 113
Some advantages and challenges of questionnaires are that
They are quick and relatively
inexpensive to administer
They can be distributed
simultaneously to a large group of
people
They can prevent tangential issues
from being introduced
The correct use of statements and
rating scales can produce answers
that can be rated for reliability and
consistency
Respondents may or may not fill
them out
Respondents may not be
committed to give correct answers,
and may be influenced by what
they think they should answer
They require a large, identifiable
user pool that is prepared to
complete and return the
questionnaire
They may not gain as much
information as other techniques,
especially in the area of subjective
insights
Facilitated Techniques
Facilitated techniques, including focus groups, brainstorming, and Joint
Application Design (JAD), are group techniques that make use of an
impartial facilitator to build trust and guide the groups decision making
and problem solving.
Depending on the environment and the level of facilitation needed, the
facilitator can be an independent third party or a trusted individual from
within the organization. Although having an independent third-party
facilitator can often hasten the group process and reduce risks and
conflicts, the analysis team needs to recognize that in some contexts,
participants may prefer having a known facilitator rather than an
outsider.
Questionnaires
(continued)
Overview

ESI 114
Facilitated Techniques (continued)
The facilitator role will vary depending on the technique chosen
including
Managing the process to encourage participants by
Improving communication among participants
Directing questions to move the process forward
Modeling active listening skills
Seeking clarification of progress made and agreements
reached
Relating comments to underlying interests and motivations
Planning the session, taking into account participant dynamics,
the time available, objectives to be met, and tools that will be
used
Recording the session in a manner consistent with participants
intent and language to encourage ownership of the results
In addition to these roles, it is the facilitators responsibility to
Maintain impartiality
Maintain confidentiality
Stay out of the debate
Encourage participation
Explain the process
Negotiate cultural differences
In the case of an internal facilitator (who may also be a stakeholder in the
process), it may be acceptable to ask permission of the group to step out
of the facilitator role to present an opinion or comment for consideration.
Focus groups involve getting concerned parties (or their delegated
representative) together in one place at one time. This technique is very
useful early in the requirements elicitation to get a general understanding
of requirements as well as specifics regarding high-priority items.
Two fundamental types of focus groups exist, homogeneous and
heterogeneous:
Overview (continued)
Focus Groups

ESI 115

Homogeneous Focus Group Heterogeneous Focus Group
Includes personnel with the
same job function (such as all
contract managers or all
accounts payable clerks)
Brings out the variety of
opinions or experiences that
can exist among peers
Allows mitigation of conflicting
information
Focuses on process details
within a process group or area
Is good for eliciting different
approaches to a process and
best practices
Includes representatives from
across functions
Allows each representative to
hear the viewpoints of the
others
Is good for gaining agreement
from a variety of stakeholders
and managing expectations
Focuses on connection,
dependency, and handoff
points (rather than internal
workings of any given process)
Successful focus groups depend on participant selection, preparation,
flexibility, group process and control skills, accurate recording of the
proceedings (videotaping or audiotaping the session is not uncommon),
management of expectations, agreement on authority and accountability
delegation, and strong facilitation skills. Focus groups can easily spiral
out of control without strong facilitation skills. If there are no strong
facilitators available on the project team, it is best to hire a professional
facilitator.
Focus Groups
(continued)

ESI 116
Some advantages and challenges of focus groups are that they
Can capture a lot of
information quickly
Allow participants to compare
and contrast their perceptions,
priorities, and needs
Allow the analyst to rapidly
obtain a wide variety of views
from a range of people with
different, but relevant,
perspectives
Must be skillfully facilitated to
prevent off-topic tangents and
open conflict among
participants
Can become a destructive
activity (whine session) rather
than a constructive one
May lead to inaccurate results
due to peer pressure
Brainstorming involves both idea generation and idea reduction by
identifying as many ideas as possible in a completely nonjudgmental
environment, then structuring and ranking the ideas into those
considered most useful by the group. Brainstorming encourages creativity
and unusual ideas with an initial goal of generating as many ideas, facts,
and descriptions as possible without worrying about their details,
chronology/hierarchy, or organization.
One approach to brainstorming is structured brainstorming, in which
participants begin by brainstorming ideas individually, then move to
grouping related ideas, and end with having a discussion to structure the
data captured, expanding and widening options as they go. The basic
steps are as follows:
1. Define topic: Define the problem or idea to be brainstormed. Make
sure everyone understands the topic being explored.
2. Free association: Collect ideas at any level, in any order, and record
them using marker pens on sticky notes. (Ideas should be written
large enough for all participants to see because creativity will be
inspired by seeing others ideas.) At this stage, do not evaluate,
criticize, or eliminate any ideas.
3. Cluster: Group requirements that seem to be related to one another.
Focus Groups
(continued)
Brainstorming

ESI 117

4. Structure components: Identify or create ideas that summarize the
clusters. Build small hierarchies throughout the clusters. Eliminate
ideas that definitely do not fit.
5. Structure system: Organize the small hierarchies under a global
heading that names the complete system. Discuss the remaining ideas
as a group.
Keys to success in brainstorming include
Using a facilitator to guide the process and set the rules
Maintaining an atmosphere of acceptance
Making all ideas visible
Keeping ideas simple (the details can come later)
Preparing participants by giving them time to think about the
issue prior to the session
Some advantages and challenges of brainstorming are that
Brainstorming
(continued)
Its nonjudgmental nature
allows for out-of-the-box
thinking where all ideas are
considered
It is a good approach at the
beginning of the process to get
a general feeling for what users
have in mind
The group process creates a
feeling of ownership
Analysis of data collected can
be very time-consuming
Participants may focus on what
might be wrong with new ideas
instead of what might be
creative and valuable
It may be necessary to hold
subsequent meetings to
reconcile strongly held
differences of opinion

ESI 118
IBM developed JAD in the 1970s, and many believe it is still the best
method for resolving issues in the requirements process (such as deciding
on requirements and their priorities). JAD is a method used in rapid
development and crisis management through which customers, user
representatives, and developers work with a strong facilitator in a series
of meetings to produce a consensus decision that is supported by the
entire team.
JAD sessions rely on highly structured agendas with clear objectives,
including a mechanism for resolving open issues that often bog down the
requirements (and design) process. The sessions differ from
heterogeneous focus groups in that JAD sessions are designed specifically
to work toward resolving issues, making decisions, and building action
plans, whereas focus groups are for discussion and discovery. JAD
sessions require a higher level of facilitation than other elicitation
techniques. Note that in order for the session to be successful, the
business sponsor/decision maker must be present throughout the entire
JAD session as a tiebreaker and to make spot decisions.
The general guidelines for JAD sessions are that they
Bring together all stakeholders including nontechnical users,
technical solution designers and developers, the business
sponsor, the project manager, subject matter experts, and others
Have support from upper management for the time and effort
spent on the sessions, as well as for the results of the session
Have a skilled facilitator adept in both systems analysis and group
dynamics
Include no more than 15 members
End with decisions that resolve issues
JAD requires strong, objective facilitation that encourages an
environment in which all voices can be heard. The process can be high
risk, but when well-managed it can elicit enormous amounts of
information and, most importantly, a decision in a short time frame.
Success factors for JAD sessions include
Predocumented, clear objectives
Prereading for each session, providing background information
and action items to be resolved
Full stakeholder representation
Presence of the business sponsor throughout the entire process to
make decisions
Full stakeholder representation (if an important voice cannot be
present, the session must be rescheduled)
Full and accurate recording/reporting of each session
JAD

ESI 119

Authority to make and implement action plans
Some advantages and challenges of JAD are that it

Product-Based Techniques
The goal of product-based techniques is to make the abstract more
concrete, allowing users to see whether a proposed solution (or part of
a solution) actually meets their needs. Two common product-based
techniques are prototyping and product evaluation trials. These
techniques work well as a test of requirements captured so far and for
identifying areas that may require additional elicitation and analysis.
JAD (continued)
Is a powerful technique in
rapid development or a crisis
situation where a decision and
an action plan are required
immediately
Allows for all voices to be
present and heard
Can create an intense
atmosphere, leading to stress
and open conflict
Can be disruptive and
expensive due to the need to
have everyone present for the
entire session
Overview

ESI 120
Product-Based Techniques (continued)
Prototyping is a technique for building multiple scenarios or versions of
the solution (or parts of the solution) for users through partial builds of
the solutions or storyboards of user interfaces, graphics, and models. The
prototypes illustrate the capabilities of the proposed solution to both
users and designers. They also serve as a communication mechanism,
helping reviewers to visualize the way the system will work instead of
reading long lists of requirements. Prototyping can be very effective when
combined with other approaches such as process models.
Prototyping allows users to play what if and work with analysts and
designers in an iterative fashionthis may be especially important in
volatile technology environments or where requirements cannot be fully
understood up front.
Prototyping requires
Strong, effective coordination of effort with the technical team
Users who are open to alternative solution approaches
A what if mindset
Some advantages and challenges of prototyping are that
Both functional and
nonfunctional prototypes allow
users to see a simulation of the
real thing, often serving as the
catalyst for further requirements
analysis
If managed well, prototyping
can create a very positive
environment for requirements
clarification, rather than the
traditional confrontational one
Simple prototypes can be built
fairly quickly, allowing for
what if scenarios
Prototypes can look a lot like a
finished solution, leading users
to think the team is closer to a
solution than they actually are
Managing user expectations
can be a challenge
Users often want to move the
discussion into design
specifications rather than
focusing on requirements
Prototyping can contribute to
scope creep
Prototyping

ESI 121
Product-Based Techniques (continued)
Product evaluation trials are useful if purchasing a commercial off-the-
shelf (COTS) product is a possibility. They are used if a product (or
process) already exists that appears to meet users needs. In this method,
a small group of users or subset of the work population obtains the
product (or process) and tests it. The group then evaluates the suitability
of the solution and reworks requirements as needed.
Product evaluations are typically used in a procurement process such as a
request for information (RFI). As a guideline, ensure that a company
procurement officer is part of the evaluation to set expectations of
potential product vendors. The procurement officer can also assist with
terms of use and application of any evaluation fees to the final purchase
price.
Some advantages and challenges of product evaluation trials are that
they
Let everyone see what is really
on the market
Can be a catalyst for gap
analysis between what a
product provides and what is
actually needed
Can artificially constrain
thinking on requirements
May lead users to focus on
product features and distract
them from the requirements
focus
Can be time-consuming
Product Evaluation
Trials

ESI 122
Chapter Summary
The key to business analysis is the requirements elicitation.
Having a diagnostic mindset greatly enhances the BAs
ability to gain the trust of stakeholders and elicit complete,
correct, and usable requirements.
Focus the elicitation on those stakeholders most likely to
provide the information needed.
The requirements elicitation is complete when the business
sponsor has enough support information to make an
acceptable risk go/no-go decision.
A number of techniques are available for eliciting
requirements. This course introduces 10 techniques.
Techniques for reviewing the AS-IS include research,
observation, and verbal protocols. They involve looking at
the current situation through either research or direct
observation.
Survey techniques include interviews and questionnaires
and involve asking questions to gather information. These
popular techniques are used to gather a wide range of
information.
Facilitated techniques, including focus groups,
brainstorming, and JAD, are group techniques that make
use of an impartial facilitator to build trust and guide the
groups decision making and problem solving.
The goal of product-based techniques is to make the
abstract more concrete, allowing users to see whether a
proposed solution (or part of a solution) actually meets their
needs. Two common product-based techniques are
prototyping and product evaluation trials.

ESI 123
Requirements:
listed.
Next-Steps Action
Plan

ESI 124
How to Gather and Document User Requirements Chapter 5: Requirements Elicitation

Action Plan:
Apply what you have learned about requirements elicitation by developing a list of actions you will complete when you return to your
organization.
Questions
to Consider:
What techniques can I use for eliciting requirements? How do I select these techniques?
How can I determine if the requirements set is sufficient for developing or deciding on a solution?

Time
1.

2.

ESI 125
Time
3.

4.

5.

ESI 126
Developing the Business Requirements Document
Reference Material
This chapter focuses on developing the business requirements document
(BRD), the major milestone deliverable for the Analysis phase. As a major
deliverable, the BRD requires formal review and sign-off by the business
sponsor (representing the interests of business area stakeholders).
Chapter Overview
6

ESI 127
Developing the Business Requirements Document
What Is the BRD?
The BRD is the synthesis of all information that has been elicited and
documented to date. The BRD is a major milestone deliverable, often
representing the completion of the Analysis phase of a project in a typical
project management methodology.
This reference document
Elaborates and updates final formal requirements before hand-off
to the systems analyst and technical team
Becomes the foundation for project planning and scope control
Serves as the documented basis for formal business area
management commitment
As a major deliverable, the BRD requires formal review and sign-off by
the business sponsor (representing the interests of business area
stakeholders). Under normal circumstances, the BRD is created by the
senior business analyst (BA) delegated to a project.
Although the requirements gathered are the focus of the BRD and will
likely be the largest part of the document, a number of other elements
must be included. Each element listed below is discussed in detail in
following sections:
Executive Summary
Approvals
Purpose
Types of requirements
Requirement prioritization
Intended audience
Analysis approach
Solution scope
Regulatory requirements
Business requirements
User requirements
Assumptions, dependencies, and constraints
Solution options
Functional requirements
BRD Defined
Elements of the BRD
4 6

ESI 128
What Is the BRD? (continued)

Nonfunctional requirements
Transition requirements
Traceability matrix
Risks
Revision Log
Glossary
Appendixes
Models
Business rules catalog
Decision tables
This format conforms to industry best practices in business analysis but
may be scaled as appropriate for a project. In practical use, interim
feedback loops and approvals for BRD sections occur in an iterative
manner, as requirements become clear over successive meetings with
project stakeholders and primary and secondary users. This facilitates the
final review and approval of the overall document, which by then will
contain no surprises.
Restate, in summary form, statements from prior project documentation,
such as the project charter and the vision and scope report. Reconfirm
the understanding of project objectives, and state any clarification
needed for those statements that may be required due to the passage of
time.
In the form of a matrix, highlight the results of the business analysis
including
A summary of the functional requirements
Next steps (prepare a formal business case? Draft a request for
proposals? Hand off to systems analyst for creating
specifications?)
Lessons learned
A summary of planned versus actual analysis duration and cost
Document the approvals required for sign-off of the BRD and
establishment of the Analysis phase milestone. Describe each signatory
by both organizational title and project functional role. Required
signatories are the BA and the business sponsor. Other signatories may
be required by company policy.
Elements of the BRD
(continued)
Executive Summary
Approvals

ESI 129
In some cases, projects have a number of key stakeholders who must
discuss and provide interim approval for all or for specific sections of the
BRD. However, a single business sponsor ultimately approves the
document, representing the requirements viewpoint of the business area
addressed by the project.
This section describes the purpose, methodology, and background of the
analysis. Typical topics covered in this section include a description of
the different types of requirements elicited, how requirements are
prioritized, who is the intended audience of the BRD, and what approach
was used for the elicitation. For example
Levels of Requirements
Functional requirements can only be derived following elicitation and
documentation of business and user requirements. The distinctions
between these different requirements levels are important.
Regulatory Requirementsencompass all the restrictions, licenses,
and laws applicable to a product or business. They may be internal
(driven by the company itself) or external (driven by a government or
other regulatory body) and are usually nonnegotiable.
Business Requirementsplace the business at the center of focus and
tie the project to documented strategic, tactical, and operational
goals. If you are developing products or services as part of the overall
direction of the company, product or service features need to be
covered at a high level, then in detail under User Requirements.
User Requirementsplace the user at the center of focus and
describewith flowcharts, use case diagrams, use case scenarios, and
other process modelsthe TO-BE user experience with the new
system. In some cases, especially where business processes are being
modified, it may also be necessary to document the AS-IS state of
user experience with the current system.
Solution Requirements:
o Functional Requirementsplace the proposed system at
the center of focus and provide a prioritized list of
capabilities the system must demonstrate in order to
satisfy business and user requirements.

Approvals
(continued)
Purpose

ESI 130

Requirements Prioritization
o Nonfunctional Requirementsrefer to system
characteristics that must be fulfilled including the user
interface, access security, availability, robustness, system
failure, integration, migration, and documentation. As
such, they do not deal with the actual functionality of the
system, but represent key project success factors.
o Transition Requirementsrefer to characteristics of the
solution that are not directly related to the functionality of
the proposed system but are needed to facilitate the
implementation of the solution.
Requirements that determine project success (must have)are
included in this release. These items represent core functionality and
must be present. The absence of any must-have functionality
represents project failure.
Requirements that add value (should have)are included in this
release provided that all must-have requirements have been met and
sufficient project resources and time remain.
Requirements that add convenience (nice to have)are included in
this release provided that all must-have and should-have
requirements have been met and sufficient project resources and time
remain.
Intended Audience
[Both readers and approvers of the BRD are identified here.
Organizational titles and functional project roles for each individual are
included. An organization chart is very helpful in complex
reader/approver environments.]
In priority order, the main reviewers and approvers of this document are
the
Business sponsor: Review and approve
Project manager: Review and integrate into construction project
phase
Systems analyst: Review and translate into system specifications
Stakeholders: Review and provide feedback to business sponsor
Users: Optionally review and provide feedback to stakeholders
Purpose (continued)

ESI 131

Analysis Approach
[This section describes the approach that was used for business analysis
activities within this project. Be sure to document any variance between
what was in the requirements work plan (RWP) and what actually took
place. Also, the choice of modeling technique may be discussed in this
section.
7
]
The analysis team conducted interviews, focus groups, and a customer
survey. Due to budget limitations, the team was unable to perform
observations as planned. A homogenous focus group substituted this lack
of direct experience. The team used the focus group to develop workflow
models and document best practices for each process role.
The customer survey was developed by the analysis team and distributed
and collected by the managers of each affected business area.
Use this section to summarize the project vision and scope from prior
project documentation, such as the vision and scope report, project
charter, or opportunity analysis. Restate project objectives, allowing for
any clarification of those statements that may be required due to the
passage of time. Also document high-level project deliverables (what is
needed) without drilling down into details or straying into solution
specifications (how we will do this).
However, the BRD is not a project scope change device. If scope has
significantly changed, previous project activities must be reopened,
because the reality represented by the official documentation and the
signatures they contain is no longer valid.
Also, use this section to summarize high-level regulatory, business, and
user requirements; document assumptions, dependencies, and
constraints; and document any solution options that have come to light
during the course of the requirements elicitation.

7
Note that the choice of modeling techniques will depend somewhat on the
audience for the BRD. For example, in a system application environment, the BA
needs to discuss with the system application group what development method is
used and what method of requirement documentation will be most convenient.
If the system application group uses traditional structured analysis, functional
decomposition diagrams may be appropriate; however, if the group uses object-
oriented (OO) modeling, then use case diagrams will be more appropriate.
Purpose (continued)
Solution Scope

ESI 132
Summary of regulatory, business, and user requirements: When present,
regulatory requirements are documented first
8
. Documenting these
requirements is a critical exercise, because
Regulatory requirements often provide clear, nonnegotiable
project constraints and quantitative success factors
They assist in budgeting when there are specific moneys
preallocated to business goals
They facilitate prioritization according to the varying priorities of
business goals
They serve as a gauge regarding the ongoing importance of a
project (if the business goals or their relative priorities change
during the project, your projects goals and priorities will also
change)
Assumptions, dependencies, and constraints: Document any
assumptions, dependencies, or constraints identified. These items may
feed the risk section, which follows.
List any assumptions about resources, schedule, and cost. All
projects operate in a less-than-perfect world. Not everything can
be officially verified as existing or available ahead of time. These
unknowns are documented as assumptions. An example might be
The project assumes the continued availability of funding
following the upcoming merger.
List any dependencies on other projects. These include, but are
not limited to, the availability of project resources, applications,
and systems that interact with this one, hardware, facilities,
equipment, business processes, and regulatory approvals. Of
particular importance are dependencies on the availability of
project stakeholders and users, and conformance to approval and
change management processes.

8
Although it is not common to include the complete text of regulatory
documents, excerpts that are of particular significance to a project are often
spelled out here.
Solution Scope
(continued)

ESI 133

List any constraints, such as technology infrastructure and
information architecture compliance. These regulatory,
technological, or business realities legitimately constrain solution
development. An example might be The new system must be
built in Oracle
. Although this example might sound, on the

surface, like a specification (and therefore not part of a BRD), it
becomes a constraining requirement when stated up front and
validated as a true constraint. For this reason, users must be
cautioned against careless statements of constraints.
Solution Options: As a business analysis vehicle, the BRD focuses on
requirements, not specifications or solutions. Nevertheless, as
requirements are elicited and documented, discussion around solution
options will occur. This section is used to document those options that
have been considered to date, rejected, or approved for further
investigation. Include rejected entries for the historical record of the
project and preempt future readers who may ask did they consider such-
and-such?
Provide detailed functional requirements information through text and
process modeling. Most companies have standard tools that have been
approved for use. These may include
Flowcharts
Context-level data flow diagrams
UML-based use case diagrams and scenarios
Swim lane or UML-based activity process workflow diagrams
IDEF0 process models
A clear description of functional requirements defines success factors for
the project. As such, functional requirements are closely tied to the
projects quality plan. One of the functions of the BRD is the
establishment of project quality standards for project deliverables. An
overall focus on the identification, definition, elicitation, and
documentation of quantitative measures versus qualitative descriptions is
a key element of functional requirement definition. Although you may
want to begin descriptions using qualitative language such as improved
or faster, be sure to follow this with quantifiable measures.
Solution Scope
(continued)
Functional
Requirements

ESI 134
Document characteristics of the solution that are not directly related to
the functionality of the proposed system in this section but that instead
focus on operational characteristics that support user requirements. As
with functional requirements, the clear, quantitative definition of these
requirements feeds the projects quality plan. Conscientiously investigate
nonfunctional requirements, as these are often overlooked or given
insufficient attention. Some key areas tied to nonfunctional requirements
are
Operational environment
User interface
User access and security
Service level, performance, and capacity
Business continuity and recovery
Integration and migration
Administrative, backup, and archive
Expected life span
Documentation
Training
Document the characteristics of the solution that are not directly related
to the functionality of the proposed system but are needed to facilitate the
implementation of the solution. These requirements are temporary,
transition-specific requirements and will not be needed once the solution
is in place. Transition requirements typically include
Generation of production data
Conversion and migration of production data
Transition requirements are often overlooked or given insufficient
attention.
Create a matrix that traces all functional requirements to higher-level
requirements. This task ensures that all functions support the business-
and user-level requirements.
Document project risks that have been identified during the analysis or
that relate to the business analysis itself (such as not having adequate
time to perform the required analysis and unavailability of key
requirements voices). For unresolved risks this section should include
The impact and probability of each risk
Who owns the risks, and deadlines for risk resolution
The strategy for managing each risk event (opportunity or threat)
Nonfunctional
Requirements
Transition
Requirements
Traceability Matrix
Risks

ESI 135
For risks that have been resolved, include all of this information as well
as the outcome.
This section provides important historical information on project risks,
and assists the business sponsor in the determination of an acceptable
level of risk and whether to proceed with the project. If the project
manager already has an integrated risk management plan for the project,
that document may be incorporated here by reference.
Record changes to requirements that have occurred over the course of
successive documentation iterations during business analysis activities.
The revision log is the central area for recording changes and
modifications to requirements that occurred during the business analysis.
Pay particular attention to any ongoing, widespread, or unresolved
requirements changes, as these may indicate high-risk areas
representing
Lack of clear business process definition
Lack of clear reporting requirements
Areas of regulatory flux
Lack of clear secondary user handoff points
Lack of clear governance related to specific requirements.
If a majority of the must-have requirements show ongoing changes, the
project itself may require reassessment at a scope level.
Identify and define any industry terms, business jargon, acronyms,
common words used in special context, and special terms that are used
within the project and the BRD itself. Pay particular attention to
acronyms that may have multiple meanings: a commonly used one and a
meaning that has special significance to the business area. For example,
the acronym PMO is an industry-wide acronym for project
management office. However, it may also stand for prime ministers
office or preventive maintenance optimization. The project and business
context determine the meaning.
Risks (continued)
Revision Log
Glossary

ESI 136
Use this section for historical information (such as the project charter,
vision and scope report, and background documentation) and working
documents that may not be of current interest to the business sponsor but
will be critical for the development team efforts once the BRD has been
approved. The appendixes each have separate headers and are listed
from AZ with an appropriate descriptive title. Following are common
areas for the appendixes.
User Class
Profiles and
Key
Delegations
Categorize users by functional groups, then by job titles
as appropriate. Supply actual names of key individuals.
Identify and describe the following groups:
Sponsorship and stakeholders
Primary users: Those who will interact with the
proposed system on a daily or regular basis and
whose job functions are directly involved with the
system.
Secondary users: Organizations, groups,
departments, and individuals who benefit from,
provide input to, or derive output from the proposed
system without direct involvement in its daily
processes. This group also involves business or
system administration personnel who must support
the proposed system.
This section may simply reference the corresponding
information in the RWP if nothing has changed.
Logical Data
Model
Elaborate on this very high-level, requirements-oriented
set of diagrams during solution design. This section may
be limited to simply identifying database systems and
their interactions with project applications. Alternatively,
it may include actual database schema diagrams and
descriptions. The amount of detail will vary by project
and company policy.
State Model Describe the various state changes of an entity as it
proceeds through the business process. Entity attribute
values may change with each state change.
Appendixes

ESI 137

Online Query
and Printed
Reporting
Describe the requirements of primary and secondary
users related to online and print output from the
proposed system. This includes but is not limited to
Ad hoc queries
Scheduled/batch reports
Audit or control reports
Recipient information mapswho gets what
information (need to know, should know, wants to
know)
Business rules that govern output generationwho,
what, where, when, why, how much
Business
Rules Catalog
Describe the rules that are followed by the business.
These rules are extracted from the management
interviews, policy and procedure documents, as well as
data and use case models.
Decision
Tables
Describe the various conditions that occur in the
business workflow. Each set of conditions results in a
business action. (Note that the number of sets is
determined by the formula 2 to the Nth power, where N
is the number of conditions.)
Use Case
Diagrams and
Scenarios
Include the use case diagrams and scenarios in this
section. The analysis draws user and functional
requirements from these models.
A Note About Technical Writing
The BRD is a technical document that must be created by applying the
principles of technical writing. The resulting document should be
dispassionate, objective, organized, and readable.
Appendixes
(continued)

ESI 138
A Note About Technical Writing (continued)
Technical writing is action oriented, characterized by a structured
noun-verb style (with few adjectives). In writing the BRD, the BA must
remove the passions, biases, and personal/professional agendas that may
be present in stated requirements. The resulting BRD provides a clear,
complete, and concise set of requirements that will serve as the
Official elaboration of the solution vision presented in the project
charter and other documents, for review and sign-off by the
business sponsor
Basis for all subsequent systems analysis, design, and
development work
Foundation for user acceptance testing and sign-off for the
completed project
In writing the BRD, the BA uses three documentation techniques:
Text, using business-level vocabulary and structure (and defining
any special terms in the glossary section)
Structured tables, using clearly defined row and column
headings
Graphical models, using graphics to illustrate processes, system
states, relationships among data elements, process and logic flow,
and object classes and their relationships
Communication is more than text, and structuring the information to be
presented in the clearest and most easily understood format will greatly
enhance the resulting document.
The BAs goal is a document that captures all solution requirements in a
format that is easily understood by everyone who reads it, from business
sponsor to user to systems analyst. To that end, the following table details
12 technical writing principles to keep in mind when drafting the BRD.
General Guidelines
for Technical Writing

ESI 139

1. Provide context before providing details.
Incorrect Repaired
512 megabytes RDRAM
200 gigabyte hard drive
100x CDRW/DVD combo
drive
200 megabyte USB memory
key
20-inch, flat-screen monitor
The new standard desktop
computer for all company
personnel will include the
following:
512 megabytes RDRAM
200 gigabyte hard drive
100x CDRW/DVD combo
drive
200 megabyte USB memory
key
20-inch, flat-screen monitor
2. Organize text into short, direct sentences.
Incorrect Repaired
The Customer Service
Representative (CSR) needs the
system log-in to be intuitive and
secure; that is, the screen layout
must clearly identify the sequence
of steps that the user needs to
follow in order to correctly log into
the system by supplying items,
such as user identification string
(user ID) and the password, after
which the user will be allowed to
enter the password with a
maximum of three attempts before
the system locks them out until
they contact the System
Administrator, who will unlock the
account and provide them with a
new password, which must be
changed the first time it is used.
The system log-in interface for
Customer Service Representatives
(CSR) shall have the following
characteristics:
Intuitive: User ID and Password
fields shall be clearly labeled.
Secure: The system shall allow
users three attempts to log in.
After the third incorrect
password attempt, users shall
be locked out. The user must
then contact the System
Administrator, who will reset
the account. The reset account
shall include a new password
that the user shall be required
to change during their next log-
in attempt.
General Guidelines
(continued)

ESI 140

3. Organize sentences into short paragraphs with a single focus.
Incorrect Repaired
The system shall provide the
Recruitment Specialist with all the
tools necessary to post a job
opening that will be visible either
on the company intranet only or
generally accessible by the public.
The system shall allow job
applicants the ability to view all
available jobs and search for
specific jobs by predefined
keywords. The system shall provide
the Recruitment Specialist with an
online form for the creation of job
postings. The system shall include
workflow such that all postings
must be approved by the Human
Resources Director before they go
live on the Web. The system shall
provide a job application form for
use by job applicants. This form
will allow them to attach resumes,
letters of introduction, and
references if they wish. The
Recruitment Specialists online
form will allow them to attach files,
such as standard company
background and marketing pieces
stored in Microsoft
Word or PDF
file formats.
Recruitment Specialist
requirements
The system shall provide
the Recruitment Specialist
with all the tools necessary
to post a job opening that
will be either visible on the
company intranet only or
generally accessible by the
public. The system shall
provide the Recruitment
Specialist with an online
form for the creation of job
postings. The system shall
include workflow such that
all postings must be
approved by the Human
Resources Director before
they go live on the Web.
The Recruitment
Specialists online form
will allow attached files,
such as standard company
background and marketing
pieces stored in Microsoft

Word or PDF file formats.
Job applicant requirements
The system shall allow job
applicants the ability to
view all available jobs and
search for specific jobs by
predefined keywords. The
system shall provide a job
application form for use by
job applicants. This form
will allow them to attach
resumes, letters of
introduction, and
references if they wish.
General Guidelines
(continued)

ESI 141

4. Ensure that each statement is testable.
Incorrect Repaired
recruitment specialist with all the
tools necessary to post a job
opening that will be visible either
on the company intranet only or
generally accessible by the public.
recruitment specialist with an
online form for the creation of job
postings. The system shall include
must be approved by the Human
Resources Director before they go
live on the Web.
1. The system shall provide the
Recruitment Specialist with all
the tools necessary to post a
job opening that will be
either
Visible on the company
intranet only, or
Generally accessible by the
public
2. The system shall provide the
Recruitment Specialist with an
online form for the creation of
job postings.
3. The system shall include
must be approved by the
Human Resources Director
before they go live on the Web.
TIP: Work to isolate requirements that can be satisfied by a small number
of test cases. If the tests that must be applied to a requirement are
complex and/or numerous, you may have an aggregate requirement that
needs to be decomposed into smaller pieces. The key is to look for
conjunctions. These may indicate areas where requirements can be
separated out.
General Guidelines
(continued)

ESI 142

5. Use proper grammar, spelling, punctuation, and plural forms. Avoid
redundancy, informality, and exclusive terms.
Incorrect Repaired
When instructors logs into the
network, she needs to be able to
see the complete list of each and
every class he is scheduled to
deliver in the next two moths.
Information on the individual
classes must include course title,
course duration, designated
classroom, client or clients
attending, and course name. So,
thats it.
When instructors log into the
network, they need to be able to
see the complete list of each and
every class they are scheduled to
deliver in the next two months.
Information on the individual
classes must include course title,
course duration, designated
classroom, client or clients
attending, and course name.
TIP: Personal pronouns such as he, she, his, and her are often
problematic. Although proper English does allow them to be used as a
gender-neutral singular, it is often more expedient to resort to the plural
form of nouns and verbs.
6. Write in the active voice.
Incorrect Repaired
The printer will be
automatically held for the
exclusive use of the auditor
reports between the hours of
9:00 a.m. and 10:00 a.m.
The database record will be
created by the sales
representative entering new
customer information.
With the large number of new
employees coming into the
system as a result of the
upcoming merger of our three
companies, the intranets
internal name and address
book will need to be upgraded
by the network administrator to
accommodate the tenfold
increase in personnel.
The system shall have exclusive
use of the printer for the
creation of hard-copy auditor
reports between the hours of
9:00 a.m. and 10:00 a.m.
Sales representatives will create
database records that contain
information on new customers.
The merger of our three
companies will require the
network administrator to
upgrade the intranets internal
name and address book so as
to accommodate the tenfold
increase in personnel.
General Guidelines
(continued)

ESI 143

TIP: In active voice, the subject does something. (The boy hit the ball.) In
passive voice, something is done to the subject of the sentence. (The ball
was hit.) Active voice is usually more emphatic, more concise, and
clearer. It always makes clear who the doer is.

7. Define abbreviations and acronyms.
Incorrect Repaired
H.R. requires online forms that are
completely WYSIWYG-related to
the hard-copy printouts that will be
produced from them. I.S. needs to
control access to these forms
according to company role: A/R,
A/P, CSR, Mgmt., and Admin. All
online forms will be accessible via
the www interface or via the
normal C/S network application.
The Human Resources Department
(HR) requires online forms that
visually correspond to the hard-
copy printouts that will be
produced from them. Information
Services (IS) needs to control
access to these forms according to
company role:
Accounts Receivable (AR)
Accounts Payable (AP)
Customer Service
Representative (CSR)
Management (MGMT)
Administration (ADMIN)
All online forms will be accessible
via the World Wide Web (WWW)
interface or via the normal
client/server (CS) network
application.
General Guidelines
(continued)

ESI 144

8. Make proper use of past, present, and future tenses.
Incorrect Repaired
The Major logs onto the system.
The password will be validated
against the federal personnel
database. Before the system logged
the Major in, it will have
performed a retinal scan after the
Major was in range to ensure the
Major will be able to log on in the
first place. The Major had learned
all about this beforehand.
The Major must be certified and
registered to access the Central
Database. As soon as the Major is
within range of the access terminal,
the system will perform a retinal
scan. After the Majors retinal
identicode is cleared, the system
will present a log-in interface. The
system will validate the password
that the Major entered against the
federal personnel database.

9. Avoid assumptions and potentially offensive language.
Incorrect Repaired
Current analysis indicates that
the companys bean counters
prefer having their own
accounts for the financial
reporting system.
It is critical that company brass
in the ivory tower have access
to all summary reports detailing
the job openings posted by the
Headhunters.
Any change requests must
undergo impact analysis before
the propeller heads take action.
Current analysis indicates that
Accounting personnel prefer
having their own accounts for
the financial reporting system.
It is critical that management
personnel at headquarters have
access to all summary reports
detailing the job openings
posted by the Human
Resources Department.
Any change requests must
undergo impact analysis before
the software developers take
action.
General Guidelines
(continued)

ESI 145

10. Use terms consistently.
Incorrect Repaired
The interface screens of the
automated cinema ticket kiosk
application shall provide
customers with the ability to
perform a complete transaction.
The application shall allow
patrons to select whether they
wish to conduct business in
English or Swahili.
The interface shall display the
movies that are currently
playing at the selected location.
The interface shall allow
moviegoers to select which film
they want to see and the
number of tickets desired.
users to pay with either cash or
credit card.
The interface screens of the
automated movie ticket kiosk
application shall provide
customers with the ability to
perform a complete transaction.
customers to select whether
they wish to conduct business
in English or Swahili.
The interface shall display the
movies that are currently
playing at the selected location.
The interface shall allow
customers to select which
movie they want to see and the
number of tickets desired.
customers to pay with either
cash or credit card.

General Guidelines
(continued)

ESI 146

11. Make quantitative rather than qualitative statements whenever
possible.
Incorrect Repaired
The system must be more
robust than the current system.
Users must have a more
intuitive interface.
All graphics and text must load
quickly.
Backups must be performed
regularly.
The new system shall have an
average monthly uptime of no
less than 95 percent during the
first six months of operation
and no less than 98 percent
thereafter.
The application interface shall
use 14-point Arial font labels
on function buttons that are
organized alphabetically in a
single column.
All graphics and text shall fully
load in under three seconds
with a 56K modem connection,
during the peak daily access
period from 11 a.m. through
1 p.m. Eastern Standard/
Daylight Savings Time.
Complete backups of all system
data shall be performed nightly
between the hours of 10 p.m.
and midnight, Pacific Standard/
Daylight Savings Time.

General Guidelines
(continued)

ESI 147

12. Write all requirements with the same, consistent level of detail.
Incorrect Repaired
The advertising agency menus
shall include
View current campaigns
The client menus shall include
View current campaigns:
o Television
o Radio
o Web
o Print
The advertising agency menus
shall include
View current campaigns, with the
following selections:
o Television
o Radio
o Web
o Print
The client menus shall include
View current campaigns, with the
following selections:
o Television
o Radio
o Web
o Print
Like all the BAs deliverables, the BRD should have the five quality
attributes introduced in Chapter 1. It should be
Visible: Business analysis mandates the formal documentation of
all requirements. Nothing should remain hidden or left to verbal
agreement.
Specific: All requirements and deliverables must be described in
enough detail that they can be differentiated from related
requirements and deliverables.
Traceable: Traceability ensures forward and backward mapping
of project deliverables from the various level of requirements
through their system specifications showing how the different
levels relate to one another and to business goals.
Accountable: Business analysis mandates that all requirements
documentation be approved by the business sponsor, who
represents the aggregate needs of the user community and has
authority (delegated by the project sponsor) to sign on their
behalf.
Measurable: Although users may begin by describing
requirements in qualitative language, the BA must work with
them to elicit and define quantifiable measurements of
requirement success. Only then can the project team develop
appropriate quality standards to ensure that requirements are
understood and testable.
BRD Quality
Attributes
General Guidelines
(continued)

ESI 148
Analyzing Requirements
Once the requirements have been elicited, the next step is analysis.
Although the requirements elicitation and documentation processes are
presented as discrete, sequential steps, in practice they often occur
concurrently or iteratively. For example, the analysis team may analyze
and prioritize requirements as they go while simultaneously defining
process and data models for the solution. This approach allows the team
to present requirements documentation for interim stakeholder reviews,
updating and refining models as a result of new or changed information.
Requirements analysis
Categorizes requirements
Organizes requirements into related groups
Explores relationships among requirements
Examines requirements for consistency, omissions, and ambiguity
Prioritizes requirements based on customer needs
Using an iterative approach, the BA eliminates, combines, and/or
modifies requirements so that all customer needs are captured. The
requirements are used to develop models (business process flows, use
cases, data flows) that facilitate a clearer understanding of requirements
and the solution, for both the customer and the developer.
The BAs goal in analyzing requirements and writing the BRD is to
document a set of requirements that provides customers with a clear,
complete understanding of what will be included in the solution and that
provides developers with everything required to ensure that customer
needs can be met. Remember that getting the requirements right may be
the single, most important step toward project successget them wrong
and the project team can end up doing a perfect job building the wrong
solution!
To that end, the following table details some characteristics of effective
requirements and questions to verify their achievement.
Characteristics of
Effective
Requirements

ESI 149
Analyzing Requirements (continued)

The following table details characteristics of effective requirements:
Requirements
should be
To check, ask
Clear Is each requirement stated in specific
terminology with no ambiguities that can be
misinterpreted by developers or testers?
Complete Is the total set of requirements a complete
representation of what must be delivered to
meet the needs and solution vision?
Concise Is each requirement expressed as briefly and
succinctly as possible?
Assignable Who suggested the requirement and what is the
rationale?
Consistent Do any conflicts exist between individual
requirements or groups of requirements?
Are there any conflicts with requirements of
existing or planned systems?
Do any conflicts exist between requirements
and the business strategy?
Have the requirements been validated to ensure
consistency?
Accurate Have all requirements been clearly and
correctly documented?
Do all stakeholders understand the
requirements?
Have users participated in the validation of the
requirements and confirmed them to be correct?

Characteristics of
Effective
Requirements
(continued)

ESI 150

Essential Does each requirement describe a feature of the
system that adds value or is required for
conformance to an external standard?
Does each requirement map back to the
business strategy?
Feasible Have the requirements been validated with the
design team (prior to final validation with the
users) to ensure that the resulting features can
be built within the project scope?
Is achieving requirements possible within the
expected budget and schedule?
Prioritized Has the relative importance of each requirement
been identified?
Traceable Is each requirement uniquely numbered?
Does each requirement map back to the
business strategy?
Validatable Can you envision a method to prove that each
requirement is properly implemented in the
solution?
NOTE: Ideally, testing provides the best proof,
but other methods for validating requirements
may be acceptable.
Characteristics of
Effective
Requirements
(continued)

ESI 151
In the real world, it is not always an easy matter to reconcile the quality
attributes with one another and with the wide variety of objectives
present in a project. Some of the problems that BAs encounter include
The business and users disagree on what is needed
Stakeholders disagree on relative priorities among requirements
Differences in literacy levels and knowledge of business jargon
among readers cause misinterpretations
Clear, complete documentation greatly facilitates communication with
the business sponsor, user groups, systems analysts, technical personnel,
and other stakeholders. During requirements analysis, having the input of
all stakeholders is important. Through this process, all solution
requirements are finalized and agreed to; therefore, everyone involved
must understand the relationships among requirements and the
consequences of including or excluding requirements from the solution.
The decisions made now will affect future project phases, so the analysis
team should listen to all stakeholders concerns and questions and
address them thoroughly. Keys to the success of this process include
Comprehensive and accurate stakeholder identification
The establishment of a project glossary (included in the BRD)
Thorough discussion and documentation of all issues and
decisions
Clear prioritization of all requirements to support trade-off
decisions
The BAs ultimate goal is reaching consensus and agreement among
stakeholders on the complete set of requirements documented in the
BRD to ensure that all stakeholders benefit from the solution.
Documenting Requirements
The next step in preparing the BRD is documenting the requirements.
This step involves not only capturing the requirements in textual format
but also refining the process and data models that support them. Together
the text and graphical models provide users, analysts, developers, and
other stakeholders with a complete and comprehensive view of the
requirements.
Communicating
Requirements
Overview

ESI 152
Documenting Requirements (continued)
The BA uses modeling techniques throughout the requirements
elicitation process to facilitate communication with stakeholders. These
techniques are used during visioning and scope to build conceptual
models of the business and processes that will be affected by the project
and to investigate problems and opportunities. Modeling techniques are
also used throughout the elicitation to clarify and communicate
requirements.
As the BA prepares the BRD, the TO-BE model of the final solution takes
shape with major business processes decomposed into detailed process
and models that, when combined with the detailed set of requirements,
will completely describe the business needs to be met by the solution
and how the new product, service, or system will meet them.
Keys to success in capturing the solution requirements and documenting
them in the BRD are the following:
Encourage customers and users to look beyond what they are
doing to what they could be doing. Too much focus on the AS-IS
in the early stages of the elicitation could lead to a solution that
does not really offer any advantage over the existing way of doing
thingsor worse, to the development of a bad process simply
because that is the way things have always been done.
Give users, customers, and other stakeholders periodic
opportunities to validate models and requirements as they are
being developed. The BRD should represent a solution that
attempts to meet everyones needs.
Conduct walk-throughs with the customer and development team
prior to final acceptance to map requirements to the process and
data models. This process helps to identify any requirements that
may have been missed and validate the correct and complete
capturing of all requirements.
Ensure that the business sponsor understands the ramifications of
acceptance. If any process was overlooked (and therefore not
modeled) and the BRD has been approved, change control will
be necessary.
The solution will only be as good as the requirements documented!
Modeling
Requirements

ESI 153
The successful acceptance and implementation of the solution presented
in the BRD depends not only on the quality of the elicitation but also on
the presentation of the results and their analysis. Integrating textual
information and graphical information is more than simply including
words and pictures in a document. Words, data, and images (models and
diagrams) need to be integrated and add value and clarity to the
information presented, and readers should come away from the
document with a clear understanding of the solution.
9

For example, if you wanted to show the interactions among a user, a
desktop client, and a database server, you might be tempted to draw the
following use case:

9
Statistician and graphic designer Edward Tuftes series of books on the visual
presentation of data is an excellent resource on this topic. The books in the
series include: The Visual Display of Quantitative Information, Envisioning
Information, and Visual Explanations. (All published by Graphics Press,
www.edwardtufte.com.)
A Note on
Presentation

ESI 154

The interactions may be clear to you, but they might not be at all clear to
your target audience. (Also, the UML standard prohibits diagramming
interactions between actors in a use case.) A better representation uses
two use cases:

If you need to go further and show alternate paths in your system, such as
what happens when the user requests the wrong report, then you need to
document those step-by-step interactions and branching in use case
scenarios.
Many modeling techniques are in use today, and this document only
provides a basic introduction to some of those models.
10
This section
presents an overview of UML system use case and activity diagrams.
Note that the business process examples in this section have been
simplified to illustrate the models; actual business processes are more
complex than those illustrated.
System use case diagrams (often referred to simply as use case diagrams
because they are the most common type) use the UML
notation
governed by the Object Management Group.
11
They are used to
document the interaction between the use and a system. Each use case
represents the availability of functionality, not the sequence of events,
branching, or repetition. Use case diagrams represent normal processing
without exceptions or errors in the function. For this reason, some
business analysts refer to the use case as the Happy Path.

10
ESIs courses Use Case Modeling, Process Modeling Management, and Logical
Data Modeling offer more detailed coverage of modeling techniques.
11
www.omg.org
A Note on
Presentation
(continued)
A Note on Modeling
Techniques
Documenting
Requirements Using
Use Case Diagrams

ESI 155
A use case describes something a user (or system) needs to achieve
through interaction with a system. Use cases always use business
language with noun-verb pairs, such as
Create invoice
Reconcile accounts payable
Calculate federal tax
Every use case must provide, by itself, real business value to one or more
users of the system.
Use case diagrams are excellent tools for establishing solution scope.
They can be used to identify and illustrate what
Is in scope
Will be saved for a later release
Is out of scope
Use case diagrams can also assist the analysis team in discussions about
urgency versus importance, and prioritizing requirements.
As introduced in Chapter 3, the basic elements of a system use case are
The boundary, drawn as a rectangle labeled with the name of the
application or system. The rectangle denotes the boundary
between the environment and the internal functions to be
automated and is the visual representation of scope. The
automation boundary makes the functionality limits of the system
very clear.
Actors, drawn as stick figures labeled with the name of the user
(humans, other systems, or conceptual entities, such as time).
Interactions between actors are never modeled in the use case
diagram.
Association relationships, drawn as lines between an actor and a
use case. (Note: Many software packages use arrow conventions
to expand on the UML standard.)
Use case, drawn as an oval labeled with the system name and
representing the sequence of actions performed by the actor(s).

Documenting
Requirements Using
Use Case Diagrams
(continued)

ESI 156
Common functionality between use cases may be added to the diagram:
Include relationships, drawn as a dotted arrow flowing from the
base use case to the subordinate one with include placed
beside or within the arrow in double chevrons. Include
relationships indicate use cases that can be activated by other use
cases (that is, in programming termsa subroutine call).
Essentially, the include, as a common function among used
cases, is reused instead of repeated within separate use cases.

Extend relationships, drawn as a dotted arrow flowing from the
subordinate use case to the base use case with extend placed
beside or within the arrow in double chevrons. Extend
relationships document an interruption to the base use case (note
direction of the arrow) that is activated under certain situations,
such as a special event or error function. Some analysts refer to
extend as interruptions to the Happy Path.

Documenting
Requirements Using
Use Case Diagrams
(continued)

ESI 157
The current UML standard does not allow the use of use case diagrams
for decomposition; hierarchical functional decomposition diagrams are
much better suited for this. In practice, confusion over decomposition has
led to the inappropriate proliferation of include and extend
relationships to the extent that some sources recommend avoiding them
altogether and instead placing their functionality within use case
scenarios (to be discussed later). The include and extend
relationships do provide value in business process modeling, but use
them with caution and not as a substitute for a more appropriate
modeling technique.
Use case scenarios expand on use case diagrams by providing step-by-
step descriptions of the interactions between the system and the actors in
the accomplishment of single business objectives. Use case scenarios are
written as a series of numbered steps that translate easily into user
acceptance test cases and training and support materials. There may be
many scenarios for each use case symbol in a diagram, representing
normal processing (also known as the Happy Path) and any alternative
include and exception extend processing paths that may occur.
The basic steps in developing use case scenarios are the following:
1. Diagram main use cases.
2. For each use case, document the normal processing scenario.
3. Continue by adding alternate and exception scenarios.
4. Refine further by adding details and information about user
interface and other nonfunctional requirements.
5. Illustrate how normal and alternate processing are related by
enhancing the appropriate diagrams.
6. Relate necessary business rules to the use case.
Documenting
Requirements Using
Use Case Diagrams
(continued)

ESI 158
For example, given the following use case

A sample normal processing use case scenario might read as follows:
1. The use case starts when the online customer selects Order
Computer.
2. The online customer enters the product code for the desired
computer.
3. The system supplies a product description and price for the
selected computer.
4. The online customer enters credit card payment information.
5. The online customer selects Submit.
6. If payment is authorized by the credit card company, the
system
6.1. Marks the order as confirmed
6.2. Forwards payment information to the accounting system
6.3. Returns an order confirmation number to the online
customer and the use case ends
Use case scenarios focus on what users want their interaction and
experience with the system to be.
Documenting
Requirements Using
Use Case Diagrams
(continued)

ESI 159
UML activity diagrams display similar information captured in scenarios
in a visual formal that highlights the hand-off points between actors. They
tie together the normal process with all its alternates and exceptions. The
result is an overall flow that includes decision points and iteration.
Processes in an activity diagram operate within either horizontal or
vertical swim lanes that can be configured to represent user roles or
physical and organizational locations. (The system is often assigned a
swim lane of its own.) The diagram begins with a trigger that acts as the
catalyst for running the process flow; only one start state is allowed, but
the process may have multiple ending states. Activity diagrams show
both sequence/process flow and decomposition (through child diagrams).
Branching and looping are supported.
VENDOR
ANALYST
VENDOR SALES REPRESENTATIVE CUSTOMER
Issue
Application
Enhancement
Request
Application
Enhancement
Request
RFP
Plan
Response
Prepare
Sales
Proposal
Merge Proposal
Sections
Response
Plan
Sales
Proposal
Approve
Proposal
Proposal
[approved]
Proposal
[draft]
Prepare
Technical
Proposal
Technical
Proposal
[else]
[application exists]
Issue RFP
for New
Application

Documenting
Requirements Using
Activity Diagrams

ESI 160
The visual syntax for activity diagrams is

In summary, UML use case diagrams are very effective tools to use as an
initial step in understanding requirements by focusing on solution scope
and interaction with automated business functions. Use case scenarios
expand on use cases by focusing on normal, alternative, and exception
process flows. Finally, UML activity diagrams display the same
information captured in scenarios, in a visual formal that highlights the
hand-off points between actors. Activity diagrams tie together the normal
process with all its alternate and exception flows. The result is an overall
flow that includes decision points and iteration.
When using use case and activity diagrams to document requirements for
the BRD, remember that user requirements must be captured before
functional requirements. Users sometimes express themselves in the
language of functional requirements. In order to build the models, the BA
must get users to communicate the underlying user-level requirement to
avoid artificially constraining the solution or ending up with a solution
that does not provide a benefit or solve a problem. For example
Documenting
Requirements Using
Activity Diagrams
(continued)
Documenting the
Correct
Requirements

ESI 161

User expression of need Underlying requirement
Each purchase order must be
automatically assigned a unique
number in ascending sequence.
Track purchase orders to assist in
timely and accurate shipping,
inventory management, and billing.
User must select the customer
name from a drop-down list. The
system must then display a screen
showing customer number,
address, contact name, outstanding
orders, billing status, and
receivables status.
Track customer accounts and all
current activity related to them to
support business functions
including ordering, inventory,
shipping, billing, and receivables.
In each of the cases above, the original user expression of the need
describes a clear functionality that, if developed, might or might not
provide the desired business benefit. By eliciting the underlying user
requirement, the business benefit is clarified and documented for
solution developers. The best way to get to the underlying user
requirements is to ask Why? when users begin to elaborate specific
functions prematurely. (Be sure to explain to the user the reason behind
your probing or it will quickly get annoying.)
As a final note, remember that the BRD focuses on requirements, not
specifications or solutions. That being said, there will always be
discussions of solution options that occur during requirements elicitation,
analysis, and documentation. While you may need to remind users from
time to time to move discussions away from solution options and back to
requirements, be sure to document any solution options that arise in the
appropriate section of the BRD, noting whether each has been rejected
(and why) or approved for further investigation. Maintaining this history
Lets the system analysis team know what options have already
been rejected and why and what options the customer would like
to consider
Helps to encourage user participation and interest in the process
by taking thoughts and suggestions seriously, and encouraging
the flow of ideas within the user community
Documenting the
Correct
Requirements
(continued)

ESI 162
Chapter Summary
The BRD is the synthesis of all information that has been
elicited and documented to date.
Technical writing is action oriented, characterized by a
structured noun-verb style.
The BAs ultimate goal is to reach consensus and
agreement among stakeholders on the complete set of
requirements.
The BRD needs to have quality characteristics, and they
need to be checked by the BA.
Use cases are used to document the interaction between
actors and a system.
Use case scenarios expand on use case diagrams by
providing step-by-step descriptions of the interactions
between the system and actors.
UML activity diagrams show the details of individual
processes, decisions, and hand-off points.

ESI 163
Requirements:
listed.
Next-Steps Action
Plan

ESI 164
How to Gather and Document User Requirements Chapter 6: Developing the Business Requirements
Document

Action Plan:
Apply what you have learned about developing the business requirements document by developing a list of actions you will complete
when you return to your organization.
Questions
to Consider:
How can I communicate the needs of the business and users to the technical team?
How can I analyze requirements to ensure they are effective?
How would I use modeling techniques to clarify requirements for stakeholders?

Time
1.

2.

ESI 165
Time
3.

4.

5.

ESI 166
Validating Requirements
Reference Material
This chapter addresses the validation of the business requirements
document prior to approval and building consensus with stakeholders. At
this time, risks should be reassessed prior to recommending a go/no-go
decision to the business sponsor. It is up to the business analyst (BA) to
build consensus around the final decision in order to ensure a successful
transition from the Analysis phase.
Chapter Overview
7

ESI 167
Validating Requirements
Checking the BRD
Validation occurs continuously throughout the requirements elicitation
processit is validation and the need for clarification and expansion that
drive each iteration cycle of the requirements package. However, once
the BRD is complete, the BA must still ensure that the document as a
whole is correct, complete, consistent, and feasible and that it can be
validated.
Checking the BRD is the culmination of the Analysis phase. The BA has
Worked with stakeholders to understand their needs
Communicated with stakeholders throughout the process to
ensure that their ideas are correctly captured
Documented requirements appropriately, ensuring that BA
quality attributes are present
The final step in the Analysis phase is checking the BRD before the final
management review to ensure both customer satisfaction and the
usability of the final document. While working on this group effort, the
BA has four main methods for checking the BRD prior to management
review:
Desk checking
Walk-through
Peer review
Inspection

Note that each of these methods focuses on finding (not resolving)
defects. The BA addresses defect resolution after receiving feedback.

Overview
4 7

ESI 168
Checking the BRD (continued)
Desk checking is an individual assessment used to find defects in a
document and provide feedback about defects and queries to the author.
In desk checking, the BA provides the BRD to selected stakeholders from
various groups, and each individual checks the document using a specific
checklist developed by either the group or the BA. This checklist helps
the reviewers focus on the appropriate areas. Each stakeholder then
provides individual feedback to the BA, who reviews and analyzes the
complete set of feedback to improve the BRD.
Typical stakeholder groups represented in the desk-checking process
are
Management sponsors
Users
Developers
Testers
Maintainers
For example, a management sponsor will be most interested in, and able
to check, whether the vision has been met, but a management sponsor
will be less able to determine whether the requirements will lead to a
product that is easy to maintain. Each stakeholder will work from a
checklist geared toward the particular strengths of that stakeholders
group.
The basic steps in desk checking are the following:
1. Read the whole document through without documenting defects.
2. Read the checklist through to remember particular points to
consider.
3. Determine whether any major aspects are missing and document
them.
4. Consider whether the structure of the document is clear and
document it.
5. Reread the document with the checklist in mind.
6. Record the defects and queries noticed.
7. Send the list to the author and keep a copy.
Desk Checking

ESI 169
A walk-through, which may also be used in requirements elicitation, is a
group assessment technique to find defects, with the author usually
present as part of the group. The group may be of any size, but the best
results are normally realized in a group of 10 or fewer stakeholders.
Members usually represent different reviewer types and may include any
organizational level.
In a walk-through, the group walks through the document page by
page, looking for and recording defects. Again, a checklist may be
helpful to guide the process and help keep everyone on track. The group
head or the author makes a list of the defects and queries for later
revision of the document.
A peer review is also a group assessment to find defects in a document.
Peer reviews are similar to, but much more structured than, walk-
throughs.
The peer review process has been gaining popularity as an important
technique, supported by a great deal of industry research. However, it is
a highly structured method with rules that must be followed in order for
the review to be effective. Practical application has shown that if these
rules are not followed, fewer defects are found, and missed defects cost
more to correct when they are found later.
The basic rules for a peer review are that
There are only peers in the groupno management (including the
project manager (PM))
The peer group consists of four or five members, with each
member taking on a specific role
12

Each member must prepare for the meeting by performing an
individual review of the document prior to the meeting, using a
checklist
Each member must bring a list of defects found to the meeting
Each member must track preparation time
Reviews last no longer than two hours, including a break
Everyone in the group is there to find defects and only defects
not solutions

12
The original optimum number in the peer review was set by IBM at four, while
Motorola believes it has shown that five is more efficient.
Walk-through
Peer Review

ESI 170
All the methods of recording peer review information should be standard,
for cross-project comparison.
Each member of the peer group takes on two roles: a reviewer role and a
group dynamic role. The reviewer role represents the specific reviewer
type, such as business analyst, user, tester, or developer. The group
dynamic role represents a specific function within the group, making the
process efficient. The fixed group dynamic roles are summarized in the
following table.
Author The author is always part of a peer review, not only as a
courtesy but also because only the author can confirm
whether the group has interpreted requirements as
intended. Authors are usually good at finding defects
and know better than anyone which parts of the
document are weak or poorly supported.
Note that all concerns expressed by the author (or
anyone else) are recorded as coming from the group so
that no blame attaches to any one individual.
If the author is not included, some members of the
group might be tempted to criticize the author instead
of the document, and the author might be resentful or
misunderstand the results.
Moderator The moderator chooses the other participants, ensures
that they have training in the peer review process, and
schedules the meeting. One week prior to the review,
the moderator provides review materials to all
participants, reminding them to track their preparation
time.
At the review, the moderator runs the meeting, hunts
for defects, and determines whether a second review is
needed. (Second reviews are necessary only if major
portions of the document need to be rewritten.)
Following the review, the moderator works with the
author to update the document if necessary and reviews
the updated document to ensure that all defects have
been addressed.
Peer Review
(continued)

ESI 171

Reader When requested by the moderator, the reader
Paraphrases or reads each sentence or
paragraph aloud
Stops as soon as there is discussion
The reader also joins in the discussion and hunts for
defects with other participants.
Recorder The recorder captures any identified defect as clearly as
possible, noting its location, type, and severity. When
necessary, the recorder may stop the meeting and ask
the group for clearer direction.
The recorder must write the results in defect form, not
solution form.
The recorder also joins in discussion and hunts for
Note that no prescribed vocabulary or format exists for
the description of defect types. Terminology is
company-specific, such as missing, wrong,
unclear, and incomplete. Qualitative terms are used
to denote defect severity such as major/minor or
high/medium/low.
Timer When five are in the group, the fifth person is the timer,
who
Provides a time check for the group at the
quarter, half, and three-quarter points
Gives the moderator time and coverage checks
when asked
The timer also joins in the discussion and hunts for
The basic steps in facilitating a peer review are the following:
1. Prior to the review, the facilitator asks each participant how much
preparation time is needed and schedules the peer-review
meeting.
2. At the review, the recorder notes the names of the participants
and their preparation time in the meeting minutes.
Peer Review
(continued)

ESI 172

3. The facilitator
a. Asks the group for large-scale items missing in the
document
b. Asks the group for large-scale comments on the
documents structure
c. Asks the reader to read or paraphrase each paragraph and
encourages defect finding and discussion
d. Closes down any discussion about finding solutions
4. The recorder documents the defect list, action items, or other
group decisions in the meeting minutes.
The immediate purpose of a peer review in a project is to find as many
defects as possible in the Analysis and Planning phases, to avoid later
rework. Companies that adopt peer reviews also use them to determine
Whether the reviews, as conducted, are cost-effective compared
to other defect-finding methods
How the review process can be improved
Information about regular types of defects
Company weaknesses implied by these defects
Whether money should be spent to prevent these defects
Often, an inspection is much more formal than a peer review because an
inspection implies that some responsibility will be taken by the inspector
or on behalf of someone who engaged the inspector. For example, if a
customer approves the BRD and supporting models, any changes
requested thereafter will require a formal change request and usually
more money. The designer who inspects and accepts the BRD and
supporting models is acknowledging that there is enough information
present upon which to base a design; the tester accepts the BRD and
supporting models as being good enough to create test cases.
There are two other key participants:
The scribe: The resulting defects and issues could become a key
project document, so special care should be taken to allow all
participants to review and approve this list recorded by the scribe
before leaving the meeting.
The decision maker: When there is a conflict about whether
something is a defect, which might affect acceptance of the BRD
and the supporting models, the decision maker has the final
word.
Peer Review
(continued)
Inspection

ESI 173
The inspection process includes the following steps:
1. Prior to the inspection, the BRD and supporting models are
frozen to prevent further changes.
2. A copy is formally distributed to all participants to allow adequate
time for review.
3. At the end of the inspection, the list of defects is reviewed and
agreed to by the key stakeholders.
4. If the BRD and supporting models passed the inspection, the BRD
becomes the baseline.
5. Otherwise, the BA ensures that the required changes are made.
Most defects seen at the end of the project, either during user acceptance
testing or in operation, can be traced back to problems in the BRD, such
as
Missing or inconsistent information
Requirements that are unclear or that may be misinterpreted by
the application development team or the procedure writers
Requirements that may be impossible to validate or measure
The greater the threat of defects in the project, the more carefully the
analysis team should check the BRD in the final stages prior to
management review. Some of the factors that may contribute to increased
threats include
The project is strongly tied to the business strategic plan
The project supports core business activities
Errors in the finished solution may have safety implications
Errors in the finished solution may cause significant loss of
revenue and/or increased operational costs
The schedule is crucial (no time for rework)
The type of product or service is new
The solution will involve new types of users
There is a large number of requirements
Requirements are complex or linked together
Stakeholders had difficulty explaining their requirements
There is reason to believe one or more requirements will change
The analysis team was not given the resources necessary to
complete their work (for example, time, access to stakeholders)
The format of the requirements is new (for example, use cases just
introduced)
Inspection
(continued)
Risk Revisited

ESI 174
Any of these factors can affect the amount of time that should be spent
checking the BRD. For example, a low-risk BRD (such as adding a
standard feature to a well-understood application) may require no more
than desk checking and management review. However, a high-risk BRD
(such as a new type of product or new classes of users) may require
carefully crafted checklists for desk checking (with reviews for the
checklists themselves); thorough desk checking by representatives from
each stakeholder/user group; and a formal peer review with user,
developer, and tester representation.
In the end, the goal is a final BRD that meets all the characteristics of
effective requirements discussed earlier in Chapter 6. The BA must be
confident that the final document is clear, complete, concise, assignable,
consistent, accurate, essential, feasible, prioritized, traceable, and
validatable. It should
Be clear and simple to understand
Show clear distinction between
Requirements (must do)
Goals (wants, wishes, and desires)
Descriptions (helpful information)
Be clearly stated whether the solution is to be produced
incrementally and, if so, which requirements are in which release
Be clearly stated whether other extensions are planned and, if so,
provide specific information about those extensions
The final hurdle in preparing for the management review is building
consensus among stakeholders in support of the final BRD.
Building Consensus
The BA must create a common understanding of the proposed solution
among key users and other stakeholders. This task requires both strong
communication skills and the ability to build consensus in support of the
proposed solution requirements.
Risk Revisited
(continued)

ESI 175
Building Consensus (continued)
The word communication comes from the Latin words communis,
meaning to impart or share, and communicare, meaning to make
common or to make known. Hence, the concept of communication as
we know it means to have common understanding.
In order to communicate effectively, it is helpful to have a basic
understanding of how communication works. Studies conducted by
Albert Mehrabian in the 1960s showed that, in spoken communication,
words account for only 7 percent of the meaning understood by the
listener. Paralingual elements, such as tone of voice, inflection, cadence,
and pitch have more than five times the impact of words (38 percent).
Nonverbal communication, such as body language (crossed arms, raised
eyebrows, pursed lips, or narrowed eyes), timing, and setting contribute
55 percent of an individuals meaning.

Ultimately, what this means is that people do not always say what they
mean or communicate in the most effective manner. One of the more
difficult tasks facing the BA throughout the requirements process is
looking beyond the words of users and other stakeholders in order to
accurately gauge their meaning. An awareness of the possible disconnect
between an individuals words and meaning can help to ensure that the
right requirements are documented for the right reasons. (By the same
token, members of the analysis team should be equally aware of their
own nonverbal messages and ensure that tone of voice, body language,
and so on match their own words.)
Communication

ESI 176
A further complication to communication is correctly interpreting and
using different communication styles. Understanding an individuals
communication style can be key in correctly interpreting the individuals
meaning. Simply put, three basic communication styles exist: aggressive,
passive, and assertive. Each is described in the table below.
Communication Style Description
Aggressive
Involves the indirect expression of
feeling through insults, sarcasm,
labels, put-downs, and hostile
statements and actions
Involves individuals expressing their
thoughts, feelings, and opinions in a
way that violates others rights of
being treated with respect and dignity
Passive
Involves saying nothing in a response,
keeping feelings to oneself, and hiding
feelings from others
Involves individuals not necessarily
expressing their thoughts honestly,
and allowing other people to violate
their own personal rights of being
treated with respect and dignity
Assertive
Involves the expression of feelings,
thoughts, opinions, and preferences
directly to another person in an
honest, appropriate, and respectful
manner
Enables individuals to act in their own
best interest, to stand up for
themselves without undue anxiety, to
express honest feelings comfortably,
and to exercise personal rights without
denying the rights of others
Aggressive and passive styles are dysfunctional and counterproductive
(especially in group settings). In contrast, assertive behavior is direct,
honest, and self-enhancing, offering a method of self-expression that is
not hurtful to others and is appropriate for any communication. During
the requirements elicitation and documentation process, the BA should
encourage assertive communication from all participants by modeling the
behavior. However, the BA should be prepared to encounter aggressive
and passive behavior (especially when participants are in disagreement),
respond effectively, and read the participants meaning from their actions.
Communication Style

ESI 177
In consensus building, as in elicitation, active listening can help uncover
stakeholders underlying interests and reasons for disagreement. Active
listening is a way of listening and responding that improves
understanding by requiring the listener to
Stop talking and concentrate on what the other is saying
Avoid formulating a response while the other is talking
Avoid making assumptions about the others point of view
Make eye contact
Acknowledge the others points through gestures or sounds
such as nodding
Avoid engaging in other activities such as reading, organizing
papers, or thinking about something else
Ask probing, relevant questions to clarify and expand
understanding of what the other has said
Paraphrase the others points to demonstrate understanding
and seek confirmation of meaning
By following these guidelines, the BA is more apt to reach a common
understanding with dissenting stakeholders and to know what
clarifications or trade-offs may be necessary to reach consensus.
Ultimately, communication (both giving and receiving information) is the
key to building a common understanding among the stakeholders about
what the proposed solutions capabilities should and will be. Only
through skilled communication and facilitation is the BA able to manage
dissenting viewpoints into a common understanding, agreement, and
support of the solution requirements as documented in the BRD.
The requirements elicitation process usually reveals a jumble of disparate
and sometimes competing ideas about how the solution should work and
what capabilities and characteristics it should have. The BAs must sift
through the requirements that they have uncovered, distill them down to
common denominators, and build consensus among key users and other
stakeholders, so that all can come to an agreement on the solutions
ultimate requirements.
Consensus, or consensus building, is a deliberative, decision-making
process that includes all participants in making the decision. It takes into
account and validates each and every participants viewpoint, ensuring
that everyone has the opportunity to contribute his or her opinion, and it
seeks to include and be informed by all key stakeholders.
Active Listening
Consensus

ESI 178
Consensus is a concept integral to the success of the elicitation. If key
project stakeholders do not agree on the solution, then there is a high risk
that the project will fail due to lack of support. In addition, if end-users
are not involved in the decision-making process and have no buy-in to
the solution, then those users will be reluctant to use the solution and the
project will likely fail upon implementation. Because the BA is
responsible for eliciting the requirements of the solution, the BA must
also work to ensure that all stakeholders come to consensus on what the
solution ultimately should look like.
The goals of consensus building are to
Move from positions (or ideas on the solution) to interests (or
underlying needs)
Seek a creative solution that meets the interests of all
stakeholders
Facilitate implementation, because all key stakeholders have
helped craft the solution
Focusing on underlying interests rather than positions is so important
because stakeholders probably have much more in common in terms of
the needs the solution must satisfy (interests) than in terms of how they
believe the solution should go about satisfying those needs (positions).
The graphic below shows the intersection of two individuals interests
and positions, represented by circles. The area of the circles above the
line represents the individuals positions. As you can see, there is a very
small area of overlap between the two individuals positions. However,
the area below the line represents the individuals interests, with the
large, shaded area in the middle representing shared interestsor
interests that both individuals have in common. If the BA is successful in
keeping the focus of the elicitation on underlying interests, then the
project team will have a much easier job of finding a creative solution
that meets all stakeholders needs.

Consensus
(continued)

ESI 179
A major advantage of consensus building is that it ensures that all
involved get what they need out of the solution, so they all have a stake
in its success. This is in contrast to a majority rule system, in which there
are clear winners and losers, which can create conflict and dissent. This
approach can create major problems when implementing the solution, as
even a very small minority can paralyze the implementation if they do
not feel they have a stake in the solutions success.
However, it is important to remember that consensus does not
necessarily mean unanimity but overwhelming agreement. Although
most consensus-building efforts set out to achieve unanimity, it may not
be possible in reality. In such cases, consensus is reached when all
participants agree that they can live with the solution, after every effort
has been made to address outstanding issues.
Building and managing consensus must be a part of the requirements
validation process in order to ensure that everyone understands and
agrees on the requirements and their priorities. There are as many
approaches to building consensus as there are groups that are attempting
to come to an agreement. Sometimes the BA can build consensus among
stakeholders through individual discussions, but other situations may
require the BA to facilitate a consensus-building session with key
stakeholders. The following shows a basic process the BA can use to
facilitate a consensus-building session:
1. Convene: The BA initiates the effort and brings key stakeholders
together.
2. Present: The BA, or some other neutral party, presents the goals
of the consensus-building effort, describing the elicited
requirements and indicating points of both agreement and
contention.
3. Clarify: The BA clarifies the roles of each participant in the
session, asks the participants to create the ground rules, and gains
agreement on the issues to be discussed.
4. Discuss and deliberate: The group discusses the issues,
consulting experts and breaking into working groups as needed,
and then drafts preliminary proposals. Techniques such as
brainstorming may be helpful in this stage of the process. The BA
continues to serve as a facilitator, reminding participants of the
established ground rules and mediating conflicts as they arise.
Consensus
(continued)
How to Build
Consensus

ESI 180

5. Decide: The group should seek unanimity and settle for nothing
less than overwhelming support. The BA must make every effort
to ensure that the concerns of dissenters are addressed and
satisfied if possible. Asking those who cannot live with the final
set of requirements to suggest modifications or additions provides
dissenters with an opportunity to buy in to the total solution.
6. Implement: The BA, or other designated individual, documents
the agreed-upon decision and has all participants sign the
document to indicate their approval. If the group is the final
decision-making body, the requirements can be finalized in the
BRD. If the group is an advisory committee, the BA takes their
recommendations to the business sponsor for final approval.
Whether the BA holds a formal consensus-building session or seeks
agreement on requirements informally through a series of one-on-one
meetings with stakeholders, the following general guidelines will help in
winning commitment to the proposed solution:
Present goals as clearly and logically as possible.
Share information among participants.
Do not assume that someone must win and someone must
lose.
Distinguish between major objections, strong concerns, and
minor disagreements.
Discourage participants from changing their minds simply to
avoid conflict and reach agreement.
Avoid conflict-reducing techniques such as majority vote,
averages, and bargaining.
Seek out differences of opinion; they are natural.
Focus on decision making through discussion and
accountability of interests as opposed to power struggles.
In order for consensus building to be successful, the process must include
a full range of stakeholders and allow the participants to set the ground
rules. The BA must be a skilled facilitator, encouraging a mutual
understanding of interests (underlying needs) and discouraging
bargaining about positions (ideas on how those needs should be met).
Creating this mutual understanding builds trust and allows for meaningful
communication among stakeholders. Perhaps most importantly, the BA
must explore all interests and make every effort to satisfy those concerns
in order to create a solution that adds value for all stakeholders.
How to Build
Consensus
(continued)

ESI 181
Consensus management is a key piece of the consensus-building process.
In the real world, one person is often ultimately responsible for deciding,
even when using consensus building. As such, that person (or someone
that person designatesin this case, the BA) must be prepared to manage
the input that comes from consensus building and be accountable for the
decision. Managing consensus is a process in which listening to others
and considering each participants input is key.
The push-pull model of consensus building originates in the martial art
judo. Judo teaches that a stronger opponent is easily overcome if the
concepts of push and pull are applied correctly. According to the model,
if a stronger opponent pushes you and you push back, you will surely
lose. However, if your stronger opponent pushes you and you pull, then
you will overcome your opponent through the combination of your
strengths. Conversely, if your opponent is pulling you can overcome your
opponent by taking advantage of the force he or she is generating and
pushing.
The push-pull model is a powerful technique for building consensus and
gaining commitment to a solution. The push model involves declaring
ones own agenda (advocacy), while the pull model involves eliciting the
others agenda (inquiry). In general, a higher frequency of pull statements
is associated with group consensus, whereas push statements tend to be
associated with decisions or outcomes based on one persons opinion.
However, using a combination of push and pull processes produces the
most positive outcomes.
How to Build
Consensus
(continued)
Push-Pull Approach
Push Pull
Declare own agenda Elicit others agenda and build
vision
Focus on own needs Focus on others needs and find
common ground
Share own motivation, interest,
and/or reasoning
Discover others motivation,
interest, and/or reasoning and
develop a common interest
Make proposals or suggest ideas Ask for others proposals or ideas
and identify areas of agreement

ESI 182
The BA must use pull statements to elicit stakeholders needs and
requirements for the solution (that is, allow the stakeholders to push), but
when building consensus among all stakeholders the BA must be able to
push and pullboth communicate group needs and make the attempt to
understand and affirm each individuals position. A combination of push
and pull results in all stakeholders expressing their needs and
understanding the needs of others. The BA can then build a set of
requirements upon which all stakeholders can agree.
Building consensus can be a time-consuming and sometimes frustrating
task. However, the advantages of forming consensus far outweigh the
disadvantages, and the BA can ask some questions to capture stakeholder
interests on the way to building consensus.
Perhaps the biggest challenge that the BA faces in building consensus is
moving stakeholder discussions of requirements from positions on how
the solution should look to underlying interests of what need the solution
should fulfill. In order to reveal stakeholders underlying interests, the BA
should ask a series of questions, beginning with, What are your
issues/problems/needs? This question reveals WHAT the particular
stakeholder needs the solution to do rather than HOW the solution
should do it.
Next, the BA should ask, What would you like to do about these
issues? This question elicits an answer expressed as a position and
desired outcome. Although this approach may seem counterintuitive to
encouraging interest-statements as opposed to position-statements, the
follow-up question reveals the underlying interest behind the expressed
position: How would that outcome address your issues? By discovering
why a stakeholder has taken a certain position, the BA and the
stakeholder can gain a deeper understanding of what the underlying
needs and interests are, thus creating room to explore a wider range of
options.
Push-Pull Approach
(continued)
to Consensus

ESI 183

Barrier to consensus Strategy for overcoming barrier
Complex issues Clarify the issue by breaking it into
logical parts
Assign issue to a working group for
analysis
Disagreement on facts Clarify facts by calling on experts
Assign responsibility to research and
resolve factual discrepancy
Conflicting stakeholder
priorities
Again, focus on interests instead of
positionsstakeholder interests may
align more readily than their positions
Refer back to original solution scope;
some stakeholder priorities may be out
of scope
Stakeholders unfamiliar
with others positions/
interests
Share information gathering during
requirements elicitation with all key
stakeholders
Antagonistic relationships
and disruptive behavior
Build trust through active listening and
affirmation of others positions
Remind participants of agreed-upon
ground rules
Ultimately, when consensus seems elusive, the BA must identify areas
where consensus HAS been reached, work with elicitation participants in
coming to an agreement on as much as possible, and assign outstanding
issues to a working group for further research. The BA can then take the
working groups recommendations back to the stakeholders and begin
working on building consensus on the more controversial issues.
to Consensus
(continued)

ESI 184
Approval and Change Management
The final steps in the Analysis phase are the approval of the BRD by the
business sponsor, the final management review to determine whether the
project will proceed as planned, and the shift from requirements
elicitation to requirements management under the project change control
plan.
Approval of the BRD by the business sponsor is a critical step in closing
out the Analysis phase. The document cannot be considered finished
until the business sponsor has signed it. Note that if the analysis team has
done its job, nothing in the BRD should come as a surprise to the
business sponsor. The BA and the analysis team should work with the
business sponsor throughout the process to address concerns and create
comfort around the decision. The BRD is not ready for approval until the
business sponsor has enough decision support information to
comfortably assess the document.
During the elicitation, the BRD is a living document, subject to editing
and reorganization as requirements are uncovered and as they change, or
as priorities shift. However, once the document has been approved and
signed, it becomes a contract between the business sponsor, the PM, and
the BA for solution development. Any future changes must be made
through the project change control process put in place by the PM.
The management review is a group assessment by management (which
can mean either project management and/or senior management) to
determine whether the project will
Move to the next project phase
Repeat the last project phase
Be abandoned
The management review is a critical step because the BRD affects
everything else going forward on the project, and only management has
the authority to authorize more work on requirements.
Closing Out the
Analysis Phase
Approval
Management Review

ESI 185
Approval and Change Management (continued)
For a typical project, completion of the BRD marks the end of the
Analysis phase and the beginning of the Design phase. Although it marks
the end of the requirements elicitation and documentation process, the
BRD is not the end of the BAs involvement in the project. Ideally, the BA
remains involved in requirements management and risk decision support
throughout the remainder of the project as the BRD becomes the basis for
solution design, test strategy and planning, and user acceptance.
Once the project moves out of the design phase, the BAs continued
involvement varies depending on the company or department, the
perceived risk associated with the project, and the BAs skill level as the
project moves into development and testing. No matter what the role, the
BAs primary focus will still be the end users requirements and whether
those requirements have been met. Some typical postanalysis BA roles
include
Solution testing support
Developing the test plantest strategies, test scenarios, and
test cases
Checking usability of the evolving solution
Checking customer satisfaction with the final solution (user
testing and acceptance testing)
Requirements management
Checking the continued accuracy and completeness of
requirements as work progresses
Managing changes to requirements
What Happens Next?

ESI 186
Chapter Summary
The BA must check the quality attributes of the BRD prior
to stakeholder approval.
The BA must build consensus among stakeholders
concerning the requirements and their priorities.
After BRD approval, changes to requirements are addressed
through the change management process established by the
project manager.

ESI 187
Requirements:
listed.
Next-Steps Action
Plan

ESI 188
How to Gather and Document User Requirements Chapter 7: Validating Requirements

Action Plan:
Apply what you have learned about validating requirements by developing a list of actions you will complete when you return to your
organization.
Questions
to Consider:
How can I select and apply appropriate consensus-building techniques in order to come to an agreement on the finalized set of
requirements documented in the BRD?
How can I obtain formal approval of requirements?

Time
1.

2.

ESI 189
Time
3.

4.

5.

Business Analysis - How To Gather and Document User Requirements

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Business Analysis - How To Gather and Document User Requirements

Cargado por

Copyright:

Formatos disponibles

Copyright ESI International

does not endorse or otherwise sponsor this publication and

Guide, p. 440, is the sum of

. Although this example might sound, on the

También podría gustarte