CBAP / CCBA Certified Business Analysis Study Guide

CBAP

/CCBA

™

Certified Business Analysis

Study Guide

Second Edition

Susan Weese

Terri Wagner

Senior Acquisitions Editor: Kenyon Brown

Development Editor: Mary Ellen Schutz

Technical Editor: Peter Honebein, PhD

Production Editor: Rebecca Anderson

Copy Editor: Kim Wimpsett

Editorial Manager: Mary Beth Wakefield

Production Manager: Kathleen Wisor

Executive Editor: Jim Minatel

Book Designers: Judy Fung and Bill Gibson

Proofreader: Nancy Carrasco

Indexer: John Sleeva

Project Coordinator, Cover: Brent Savage

Cover Designer: Wiley

Cover Image: ©Getty Images Inc./Jeremy Woodhouse

Published simultaneously in Canada

ISBN: 978-1-119-24883-5

ISBN: 978-1-119-24885-9 (ebk.)

ISBN: 978-1-119-24884-2 (ebk.)

Manufactured in the United States of America

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, scanning or otherwise, except as

permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior

written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to

the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978)

646-8600. Requests to the Publisher for permission should be addressed to the Permissions

Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201)

748-6008, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or

warranties with respect to the accuracy or completeness of the contents of this work and specifically

disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No

warranty may be created or extended by sales or promotional materials. The advice and strategies

contained herein may not be suitable for every situation. This work is sold with the understanding that

the publisher is not engaged in rendering legal, accounting, or other professional services. If professional

assistance is required, the services of a competent professional person should be sought. Neither the

publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or

Web site is referred to in this work as a citation and/or a potential source of further information does not

mean that the author or the publisher endorses the information the organization or Web site may

provide or recommendations it may make. Further, readers should be aware that Internet Web sites

listed in this work may have changed or disappeared between when this work was written and when it is

read.

For general information on our other products and services or to obtain technical support, please contact

our Customer Care Department within the U.S. at (877) 762-2974, outside the U.S. at (317) 572-3993 or

fax (317) 572-4002.

Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material

included with standard print versions of this book may not be included in e-books or in print-on-

demand. If this book refers to media such as a CD or DVD that is not included in the version you

purchased, you may download this material at http://booksupport.wiley.com. For more information

about Wiley products, visit www.wiley.com.

Library of Congress Control Number: 2016957688

TRADEMARKS: Wiley, the Wiley logo, and the Sybex logo are trademarks or registered trademarks of

John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be

used without written permission. CBAP and CCBA are registered certification marks of International

Institute of Business Analysis. All other trademarks are the property of their respective owners. John

Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.

Good luck to all the planners, crammers, and refreshers getting ready to sit

for the CBAP

or CCBA

™

business analysis certification exam!

Dedicated to my family, friends, and colleagues who put up with me

spending so much time on this book.

—Susan

Lovingly dedicated to my niece, Jenna, for her generous spirit, keen

analytic skills, and leadership acumen. Fueled by passion and purpose,

blended with the right mix of values, skills and experience, I have no doubt

her leadership influence will be felt around the world. And it all started with

being an awesome Business Analyst!

—Terri

Acknowledgments

Thank you to Mary Beth Wakefield, Editorial Manager; Kenyon Brown, Senior

Aquisitions Editor; Rebecca Anderson, Production Editor; Kim Wimpsett, Copy

Editor; John Sleeva, Indexer; and Nancy Carrasco, Proofreader. Without all of

their contributions and assistance, this book would never have made it to the

presses. In particular, thank you to Development Editor Mary Ellen Schutz. Her

attention to detail, requests for clarity, and questions about what was really

meant kept me on target to produce the complete study guide you are reading

right now. ME, if you were here with me, I would give you a big hug! Without

your herding and nipping during the revision process, this book would never

have become such a great product. Your gentle editing is subtle, targeted, and

effective. Peter Honebein, your technical edits were right on target and made

everything in this book better.

A big thank-you goes out to the founders and supporters of the International

Institute of Business Analysis (IIBA™) and the team who developed the

contents of the BABOK® Guide. I would also like to thank my colleagues and

good friends, Ginger Sanchez, Peggy Oglesby, and Phil Bennett, for sharing their

wonderful business analysis stories and ideas that became the basis for many

tales in this book. Thanks also to Melisa Pearce of Touched by a Horse for

sharing her barn project.

This book is the result of collaboration between Susan Weese and Terri Wagner.

Susan authored the book. Terri reviewed text and lent her experience and

expertise to parts of the overall project.

Finally, Little Man, thank you for lying on my computer every morning and

helping me think through things. You are the prince of cats.

—Susan

My deepest gratitude to Susan for taking the helm and navigating these waters.

Your dedication, talent, and wisdom never cease to amaze me. Thank you for all

your hard work and perseverance masterfully integrating the many

enhancements to the Business Analysis Body of Knowledge into this updated

study guide. I admire your professionalism and cherish your friendship!

—Terri

About the Authors

Susan Weese, PgMP, PMP, PRINCE2, MSPM, MoP Susan is a

management consultant, curriculum designer, and professional speaker

specializing in project management and requirements development process

development and implementation for complex information technology projects.

She started her work career as a software engineer, designing and developing

complex mathematical algorithms for satellite and radar systems. Halfway

through her work life, Susan crossed to the dark side of technology and became

actively involved with managing programs, projects, large consulting

organizations, and business processes. She is still having a blast and has never

looked back.

Susan founded Colorado-based Rhyming Planet, Inc., in 2000 to motivate, lead,

and enable technical and business professionals to accomplish their program

and project goals. Susan is also an adjunct faculty member at Colorado State

University, delivering courses on project management and the underlying

competencies that turn good managers into great managers.

Terri Wagner (Aurora, CO) M.A., PMP, CSM is owner/managing member

of Mentor Source, Inc., a Colorado-based project management consulting and

training company. She has co-authored and been the technical editor for several

project management and business analysis books, including the Project

Manager Street Smarts (Wiley). She has also taught project management,

portfolio management, program management, business leadership,

interpersonal skills, quality management, and other topics to state agencies,

governmental entities, corporate clients, and at the graduate level in the

university system.

CONTENTS
Introduction
Assessment Test
Chapter 1 Foundation Concepts
What Is Business Analysis?
Reviewing the Business Analysis Core Concept Model (BACCM™)
Exploring the Business Analysis Knowledge Areas
Exploring Requirements
Understanding How This Applies to Your Projects
Perspectives on Business Analysis
Summary
Exam Essentials
Key Terms
Review Questions
Chapter 2 Controlled Start: Business Analysis Planning and Monitoring
Business Analysis Planning and Monitoring
How This Applies to Your Projects
Summary
Exam Essentials
Key Terms
Review Questions
Chapter 3 Controlled Start: Strategy Analysis
Strategy Analysis
How This Applies to Your Projects
Summary
Exam Essentials
Key Terms
Review Questions
Chapter 4 Overarching Tasks: Requirements Life Cycle Management
Requirements Life Cycle Management
How This Applies to Your Projects
Summary
Exam Essentials
Key Terms
Review Questions
Chapter 5 Controlled Middle: Elicitation and Collaboration
8

Requirements Elicitation
How This Applies to Your Projects
Summary
Exam Essentials
Key Terms
Review Questions
Chapter 6 Controlled Middle: Requirements Analysis and Design Definition
Requirements Analysis and Design Definition
How This Applies to Your Projects
Summary
Exam Essentials
Key Terms
Review Questions
Chapter 7 Controlled End: Solution Evaluation
Solution Evaluation
How This Applies to Your Projects
Summary
Exam Essentials
Key Terms
Review Questions
Chapter 8 Underlying Competencies
Essential Skills of Effective Business Analysts
How This Applies to Your Projects
Summary
Exam Essentials
Key Terms
Review Questions
Chapter 9 Five Perspectives on Business Analysis
The Agile Perspective
The Business Intelligence Perspective
The Information Technology Perspective
The Business Architecture Perspective
The Business Process Management Perspective
Understanding How This Applies to Your Projects
Summary
Exam Essentials
Key Terms
Review Questions
9

Appendix A Advice on Completing Your Exam Application
The Competency-Based Certification Model
CBAP
®
 Experience Requirements
CCBA
™
 Experience Requirements
Calculate Your Experience Hours
Additional Exam Eligibility Requirements
The Exam Application Process
Appendix B Knowledge Areas, Tasks, and Elements
Review the Six Knowledge Areas
Knowledge Areas, Tasks, and Elements
Appendix C Mapping Techniques, Stakeholders, and Deliverables to
Knowledge Areas and Tasks
Techniques
Stakeholders
Deliverables
Appendix D Summary of Business Analysis Techniques
Business Analysis Techniques
Appendix E Summary of Business Analysis Outputs
Business Analysis Outputs
Appendix F Answers to Review Questions
Chapter 1: Foundation Concepts
Chapter 2: Controlled Start: Business Analysis Planning and Monitoring
Chapter 3: Controlled Start: Strategy Analysis
Chapter 4: Overarching Tasks: Requirements Life Cycle Management
Chapter 5: Controlled Middle: Elicitation and Collaboration
Chapter 6: Controlled Middle: Requirements Analysis and Design
Definition
Chapter 7: Controlled End: Solution Evaluation
Chapter 8: Underlying Competencies
Chapter 9: Five Perspectives on Business Analysis
Advert
EULA
10

List of Tables
Introduction
TABLE 1.1
Chapter 1
TABLE 1.1
TABLE 1.2
Chapter 2
TABLE 2.1
TABLE 2.2
TABLE 2.3
TABLE 2.4
TABLE 2.5
TABLE 2.6
TABLE 2.7
TABLE 2.8
TABLE 2.9
TABLE 2.10
TABLE 2.11
TABLE 2.12
TABLE 2.13
TABLE 2.14
TABLE 2.15
TABLE 2.16
Chapter 3
TABLE 3.1
Table 3.2
TABLE 3.3
TABLE 3.4
TABLE 3.5
TABLE 3.6
TABLE 3.7
TABLE 3.8
11

TABLE 3.9
TABLE 3.10
Chapter 4
TABLE 4.1
TABLE 4.2
TABLE 4.3
TABLE 4.4
TABLE 4.5
TABLE 4.6
TABLE 4.7
TABLE 4.8
TABLE 4.9
TABLE 4.10
TABLE 4.11
TABLE 4.12
TABLE 4.13
Chapter 5
TABLE 5.1
TABLE 5.2
TABLE 5.3
TABLE 5.4
TABLE 5.5
TABLE 5.6
TABLE 5.7
TABLE 5.8
TABLE 5.9
TABLE 5.10
TABLE 5.11
Chapter 6
TABLE 6.1
TABLE 6.2
TABLE 6.3
TABLE 6.4
TABLE 6.5
12

TABLE 6.6
TABLE 6.7
TABLE 6.8
TABLE 6.9
TABLE 6.10
TABLE 6.11
TABLE 6.12
TABLE 6.13
TABLE 6.14
TABLE 6.15
TABLE 6.16
TABLE 6.17
TABLE 6.18
TABLE 6.19
TABLE 6.20
TABLE 6.21
TABLE 6.22
Chapter 7
TABLE 7.1
TABLE 7.2
TABLE 7.3
TABLE 7.4
TABLE 7.5
TABLE 7.6
TABLE 7.7
TABLE 7.8
TABLE 7.9
TABLE 7.10
TABLE 7.11
TABLE 7.12
TABLE 7.13
Chapter 8
TABLE 8.1
TABLE 8.2
13

Chapter 9
TABLE 9.1
TABLE 9.2
TABLE 9.3
TABLE 9.4
TABLE 9.5
TABLE 9.6
TABLE 9.7
TABLE 9.8
TABLE 9.9
TABLE 9.10
TABLE 9.11
TABLE 9.12
TABLE 9.13
TABLE 9.14
TABLE 9.15
TABLE 9.16
TABLE 9.17
TABLE 9.18
TABLE 9.19
TABLE 9.20
TABLE 9.21
TABLE 9.22
TABLE 9.23
TABLE 9.24
TABLE 9.25
Appendix A
TABLE A.1
TABLE A.2
TABLE A.3
TABLE A.4
Appendix C
TABLE C.1
TABLE C.2
14

TABLE C.3
TABLE C.4
TABLE C.5
TABLE C.6
TABLE C.7
TABLE C.8
TABLE C.9
TABLE C.10
TABLE C.11
TABLE C.12
TABLE C.13
TABLE C.14
TABLE C.15
TABLE C.16
TABLE C.17
TABLE C.18
TABLE C.19
Appendix D
TABLE D.1
Appendix E
TABLE E.1
TABLE E.2
TABLE E.3
TABLE E.4
TABLE E.5
TABLE E.6
15

List of Illustrations
Chapter 1
FIGURE 1.1 Relationships between knowledge areas
FIGURE 1.2 Requirements and design cycle
FIGURE 1.3 Classes of requirements
FIGURE 1.4 Mapping the BABOK
®
Guide to a generic life cycle
Chapter 2
FIGURE 2.1 Task summary: Plan business analysis approach.
FIGURE 2.2 Task summary: Plan stakeholder engagement.
FIGURE 2.3 Onion diagram
FIGURE 2.4 Task summary: Plan business analysis governance.
FIGURE 2.5 Task summary: Plan business analysis information
management.
FIGURE 2.6 Task summary: Identify business analysis performance
improvements.
FIGURE 2.7 The Shewhart cycle
Chapter 3
FIGURE 3.1 Task summary: Analyze current state.
FIGURE 3.2 A fishbone diagram offers the opportunity to analyze and
discuss.
FIGURE 3.3 Task summary: Define future state.
FIGURE 3.4 Relating strategy and implementation
FIGURE 3.5 Task summary: Assess risks.
FIGURE 3.6 Task summary: Define change strategy.
Chapter 4
FIGURE 4.1 Responding to changing requirements
FIGURE 4.2 Task summary: Trace requirements.
FIGURE 4.3 Task summary: Maintain requirements.
FIGURE 4.4 Task summary: Prioritize requirements.
FIGURE 4.5 Task summary: Assess requirements changes.
FIGURE 4.6 Task summary: Approve requirements.
FIGURE 4.7 A framework for configuration management
Chapter 5
16

FIGURE 5.1 Task summary: Prepare for elicitation.
FIGURE 5.2 Task summary: Conduct elicitation activity.
FIGURE 5.3 Applying the elicitation techniques
FIGURE 5.4 Task summary: Confirm elicitation results.
FIGURE 5.5 Task summary: Communicate business analysis
information.
FIGURE 5.6 Task summary: Manage stakeholder collaboration.
Chapter 6
FIGURE 6.1 Task summary: Specify and model the requirements.
FIGURE 6.2 Gane-Sarson and Yourdon models for Palmer Divide
FIGURE 6.3 ERDs and class diagrams for Palmer Divide
FIGURE 6.4 Workflow mode for Palmer Divide
FIGURE 6.5 Summary-level use-case diagram for Palmer Divide
FIGURE 6.6 Task summary: Verify the requirements.
FIGURE 6.7 Task summary: Validate the requirements.
FIGURE 6.8 Task summary: Define requirements architecture.
FIGURE 6.9 Task summary: Define design options.
FIGURE 6.10 Task summary: Analyze potential value and recommend
solution.
Chapter 7
FIGURE 7.1 Task summary: Measure solution performance.
FIGURE 7.2 Task summary: Analyze performance measures.
FIGURE 7.3 Task summary: Assess solution limitations.
FIGURE 7.4 Task summary: Assess enterprise limitations.
FIGURE 7.5 Task summary: Recommend actions to increase solution
value.
Chapter 8
FIGURE 8.1 Lines of communication
17

Introduction

The content of this book revolves around A Guide to the Business Analysis Body

of Knowledge

(BABOK

Guide) Version 3.0, published in 2015 by the IIBA

™

headquartered in Toronto, Canada. You will notice references to the BABOK

Guide throughout this book. Its contents drive the discussions on performing

successful business analysis work across the project life cycle. In some cases,

certain phrases are used verbatim to ensure strict conformance with the

BABOK

Guide. Both certification exams focus on the contents of the BABOK

Guide. Consider getting a copy of the guide to assist you while you are using this

book to prepare you for the exams.

The book contains many hints and tips about preparing for and passing the

exam and using what you have learned in your everyday work. The first tip for

anyone wanting to become familiar with the BABOK

Guide is that you need to

learn its language. Speaking this language gives you a common business analysis

language, regardless of the industry or organization you work in. The terms and

definitions found there may be different from the terms and definitions you use

at work. So, your first step is to familiarize yourself with the terms and

definitions so you are comfortable with BABOK

Guide–speak.

The second tip is that you need to be familiar with the six knowledge areas

defined in the BABOK

Guide. These knowledge areas divide your business

analysis knowledge and skills into six common areas. You will start with the

high-level definitions and then drill down into the detailed tasks and techniques

that successful business analysts use to get the job done. Let’s move on and talk

a little bit about the focus of this book.

What You Will Learn

This book helps you prepare to take the CBAP

or CCBA

™

certification exam.

The CBAP

exam is designed for experienced business analysts, while the

CCBA

™

exam targets people who have less experience in the business analysis

profession. Reading this book does not guarantee that you will pass the exam,

but ideally you will find its contents motivating and helpful.

In the new certification exam structure, the CCBA

™

exam provides less

experienced business analysts with their first step toward obtaining the CBAP

designation. This exam targets individuals who are proficient in some aspects of

business analysis, are in the process of developing business analysis skills and

expertise, and who apply business analysis to smaller scope projects and less

complex tasks. The CCBA

™

certification expires after five years. The expectation

is that you will then apply to take the CBAP

exam when you have gained more

business analysis experience. You can also retake the CCBA

™

exam if you have

not yet met the required CBAP

exam level of business analysis experience.

What Is Covered in This Book

The CBAP

/CCBA

™

: Certified Business Analysis Study Guide, Second Edition

follows a simple project life cycle frequently used as the basis for many projects.

The life cycle consists of three high-level phases.

Controlled start, where you plan for your project’s business analysis

activities and define the scope of the new solution your project will create

Controlled middle, where the project work is actually being performed to

define, design, and build the new solution

Controlled end, when you wrap up your work activities and transition the

new solution into operational use

The knowledge areas of the BABOK

Guide are placed within these three life

cycle phases in order to work through the business analysis tasks and

techniques from project start to end.

To get the most out of this book, you should read each chapter from start to

finish and then check your memory and understanding with the chapter-end

elements. Even if you’re already familiar with a topic, you should skim the

chapter; business analysis is complex. There are often multiple ways to

accomplish a task, and you may learn something even if you’re already

competent in an area.

Chapter 1, “Foundation Concepts,” lays the groundwork for navigating

and understanding the content and intent of the BABOK

Guide. This

chapter gives you a high-level look at what it means to be a business analyst

and reviews the underlying competencies of the business analyst, the key

business analysis stakeholders, and the BABOK

Guide requirements

classification scheme.

Chapter 2, “Controlled Start: Business Analysis Planning and

Monitoring,” takes you through planning the business analysis activities

for your project using tasks from your first knowledge area. To achieve a

controlled start to a project or project phase, you must plan what needs to be

done, how to go about doing it, and who needs to be involved with the work.

Chapter 3, “Controlled Start: Strategy Analysis,” steps you through

translating your organization’s business strategy into a proposed new

business solution. During your project’s controlled start, you will define and

document the business requirements for your project. The business

requirements justify why a particular project should be initiated to address a

particular business need.

Chapter 4, “Overarching Tasks: Requirements Life Cycle

Management,” focuses on ensuring that the right people are involved with

developing, understanding, and approving the project requirements. In

addition, your project requirements must be accessible and managed during

your requirements development work and throughout the project life cycle.

Chapter 5, “Controlled Middle: Elicitation and Collaboration,”

guides you through gathering, organizing, and understanding the necessary

information to develop the business, stakeholder, solution, and transition

requirements for your project, and understanding what your project

stakeholders need from the new solution.

Chapter 6, “Controlled Middle: Requirements Analysis and

Design Definition,” takes your elicited requirements information and

makes sense of it. The tasks in this knowledge area focus on analyzing the

stated requirements from your elicitation efforts and building the real

stakeholder or solution requirements for your project.

Chapter 7, “Controlled End: Solution Evaluation,” focuses on

assessing proposed solutions, allocating requirements to solution

components, and validating the solution to make sure that it will meet the

business need and deliver value to the organization and its stakeholders.

Chapter 8, “Underlying Competencies,” defines the core framework of

business, technical, and domain knowledge possessed by effective business

analysts. Your core framework of knowledge is enhanced by your

management, interpersonal, business, and structured problem-solving skills.

Chapter 9, “Perspectives,” steps through five perspectives on business

analysis. You will dig into business analysis work on agile, business

intelligence, information technology, business architecture, and business

process management projects.

Appendix A, “Advice on Completing Your Exam Application,”

examines the required qualifications and application process for successfully

completing and submitting your application to sit for the CBAP

or CCBA

™

certification exam.

Appendix B, “Knowledge Areas, Tasks, and Elements,” lists the

knowledge areas, tasks, and elements to assist you in your study efforts.

Appendix C, “Mapping Techniques, Stakeholders, and

Deliverables to Knowledge Areas and Tasks,” provides you with a

coverage matrix mapping business analysis techniques, deliverables, and

stakeholders to the knowledge area tasks that use them.

Appendix D, “Quick Summary of Business Analysis Techniques,”

provides you with brief descriptions of each business analysis technique in

the BABOK

Guide.

Appendix E, “Quick Summary of Business Analysis Deliverables,”

provides you with brief descriptions of each deliverable produced as a

business analysis task output in the BABOK

Guide.

Appendix F, “Answers to Review Questions,” contains both the

answers and explanations for the chapter review questions.

Glossary: A glossary of terms is available with the online testing materials

in PDF format.

BABOK

Techniques Matrix: Maps of techniques, stakeholders and

deliverables across the knowledge area tasks are available for download in

Microsoft Excel format.

How to Become CBAP®/CCBA™ Certified

The CBAP

and CCBA

™

certification exams each address all six knowledge

areas from the BABOK

Guide. The exams also test your knowledge of sources

referenced by the BABOK

Guide and your own business analysis experience.

The CBAP

exam is designed for experienced business analysts, while the newer

CCBA

™

exam targets folks who have less experience in the business analysis

profession. You can apply and pay for the exams online using the IIBA

™

website. Most people schedule and take the exams in a testing center and

complete the questions on a computer. Feedback is immediate as to whether

you have passed or failed the exam once you submit your finished set of

questions. Let’s take a look at each exam in a bit more detail.

More on the CCBA™ Exam

The CCBA

™

exam provides newer, less experienced business analysts with their

first step toward obtaining the CBAP

certification. This exam targets

individuals who are proficient in some aspects of business analysis, are in the

process of developing business analysis skills and expertise, and who apply

business analysis to smaller scope and less complex tasks and projects.

Requirements for candidates taking the CCBA

™

exam include a minimum of

3,750 hours of business analysis work, aligned with the BABOK

Guide, in the

last seven years with at least 900 hours in two of the six knowledge areas or 500

hours in four of the six knowledge areas, a minimum of 21 hours of Professional

Development, and a high-school education or equivalent. You will also be

required to provide two references from a career manager, client, or CBAP

The CCBA

™

certification expires after five years. The expectation is that

recipients will then apply to take the CBAP

exam as a more experienced

business analyst. There is also an option to retake the CCBA

™

exam if you have

not yet met the required CBAP

exam level of experience during that time

period.

What’s on the Exams

Both CBAP

and CCBA

™

exams contain 150 questions that must be answered

within 3.5 hours. The passing mark for your scored exam is calculated based on

psychometric procedures that the IIBA

™

does not disclose to the public. The

CBAP

and CCBA

™

Exam Blueprints indicate the relative weight of each

knowledge area by providing you with the percentage of questions from that

knowledge area on your exam. The percentages are provided for you in Table

1.1. Because of rounding issues, some of the percentages do not add up to exactly

100 percent.

TABLE 1.1 Exam knowledge area and question breakdown

Knowledge Area CBAP

Exam % of

Questions

CCBA

™

Exam % of

Questions

Business Analysis Planning

and Monitoring

14% 12%

Elicitation and Collaboration 12% 20%

Requirements Life Cycle

Management

15% 18%

Strategy Analysis 15% 12%

Requirements Analysis and

Design Definition

32% 30%

Solution Evaluation 14% 6%

All the questions on your exam are multiple-choice questions with four possible

answers from which to select. There are no penalties for incorrect answers, so

remember to attempt to answer every question.

Types of Questions

In 1956, Benjamin Bloom, an educational psychologist at the University of

Chicago, proposed his Taxonomy of Educational Objectives, classifying learning

objectives into six hierarchical levels: knowledge, comprehension, application,

analysis, synthesis, and evaluation. This taxonomy drives the structure and style

of the exam questions you will be seeing on your CBAP

and CCBA

™

exams, as

the questions will range across this entire taxonomy. Questions may also have a

scenario for reading before the body of one or more questions.

The breakdown of questions across Bloom’s Taxonomy is not provided in the

IIBA

™

’s exam blueprint. As a rule of thumb, you should expect to see

approximately 70 percent to 80 percent of your questions taken from the easier

question types (knowledge, comprehension, application, and analysis) in the

taxonomy and 20 percent to 30 percent taken from the more difficult question

types (synthesis and evaluation).

If you are able to recognize the type of question you are being asked, you can use

this recognition to arrive at the correct answer to that question. Let’s take a look

at each question type in more detail:

Knowledge Questions Knowledge questions test your ability to know specific

facts and recall information that you have learned. This information may be

straight from the BABOK

Guide, or it may be something you have learned

from another source. These questions are straightforward and remind us of the

traditional multiple-choice questions from exams we took in our younger days.

Here is an example of a knowledge question:

Which type of requirement describes high-level organizational needs?

A. Business

B. Stakeholder

C. Functional

D. Transition

This is a “define the term” question, and the correct answer is A. As stated in the

BABOK® Guide glossary, business requirements describe the higher-level

business rationale for your project or initiative. Answering this question

correctly requires you to recall the definitions for the different types of

requirements found in the BABOK® Guide.

Exam Spotlight

Notice that the wording of the question and the correct answer may not be

word for word from the BABOK

Guide. This is something you will

commonly see in the certification exams, so be sure that you understand

what you are learning versus simply memorizing the information.

Comprehension Questions Comprehension questions require you to

interpret facts and understand meanings. This is a step up from a knowledge

question, where simple memorization and recall usually provide you with the

correct answer. Here is an example of a comprehension question:

What type of requirements contains the environmental conditions of the

solution?

A. Transition requirements

B. Stakeholder requirements

C. Business requirements

D. Solution requirements

This is a “check your understanding” question, and the correct answer is D. As

stated in the BABOK® Guide glossary, solution requirements include both

functional and nonfunctional requirements for a particular project. This

question requires understanding of the requirements types found in the

BABOK® Guide and the knowledge that environmental conditions are

nonfunctional requirements, which are a subset of the solution requirements.

Exam Spotlight

Notice that all of the answers in this example deal with the actual classes of

requirements found in the BABOK

Guide. There are no distracter answers

that jump up and tell you they are incorrect. Each possible answer is

something you have been studying. Beware of the distracter answers that

are good answers, and make sure you know the correct answer for the

question you are being asked!

Application Questions Application questions raise the bar a bit more by

asking you to use information to solve problems. These questions take your

knowledge and comprehension, combine them, and ask you to do something

with the result. Here is an example of an application question:

Transition requirements are typically prepared after which requirements

document is completed?

A. Solution requirements

B. Stakeholder requirements

C. Business requirements

D. System requirements

This is a “use the information” problem asking you about the logical sequence

for developing the types or classes of requirements on a project. Be sure to

answer using the BABOK® Guide classification scheme and a generic life cycle

versus answering from your organization’s scheme and life cycle models unless

they are exactly the same. The correct answer is A. Once the solution

requirements are defined, the transition requirements for the solution can be

built.

Exam Spotlight

Watch for the modifiers in your exam questions, such as most, least, best, or

worst. They add difficulty to the question as they ask you to select the

correct answer that falls at the appropriate end of this sliding scale—best

versus worst or least versus most. That usually means all of the answers are

correct, but some answers may be more or less correct than others.

Analysis Questions Analysis questions are a bit more difficult to navigate.

This question type asks you to recognize patterns and seek hidden meanings in

the information you are provided. A common type of analysis question is

looking at and analyzing a series of process or activity-related steps performed

by the business analyst. Here is an example of an analysis question:

To capture the process of provisioning a circuit, the business analyst observed

an ordering supervisor for half a day. The resulting information could then be

incorporated into all of the following types of requirements except:

A. Transition requirements

B. Solution requirements

C. Stakeholder requirements

D. Functional requirements

This question is a pattern question focusing on a recommended series of steps to

be followed by the business analyst who is using observation as a technique to

elicit or analyze project requirements. The twist is that you are looking for the

wrong answer this time around. The correct (wrong) answer is A. The solution

capability is not usually found in the transition requirements for a solution.

Exam Spotlight

Watch for the positives and negatives in your exam questions, such as not or

except. If you miss the negative, it is easy to get an answer wrong, even for a

question to which you know the answer.

Synthesis Questions Synthesis questions test your ability to relate facts and

draw conclusions based on the information you are given. Here is an example of

a synthesis question:

After reviewing the existing process to approve a new cell phone order, Ginger

realized that the senior manager is not always available to manually approve the

purchase. She documented the capabilities that facilitate a faster ordering

approval process relative to the existing situation. She felt that the existing

process was inefficient and that it needed to be changed. What would be an

appropriate way for Ginger to express the cause of the current cell phone

ordering delays?

A. Blame the manual process for the inefficiencies.

B. State all of the facts in a neutral manner.

C. Express opinions on how to fix the process.

D. Insist that approvers adhere to strict deadlines.

You are being asked to “draw a conclusion” based on the specific scenario you

have been provided within the body of the question. Ginger is being asked to

effectively use her underlying competencies as a business analyst to solve a

problem. Her best choice is to confront the problem and lay out all the

information for the decision makers to analyze and then decide what to do. The

correct answer is B.

Exam Spotlight

Watch for too much information. Occasionally (as in the previous question

statement) more information is given than is needed to answer the question

correctly. Don’t let extra, unrelated information lead you to select an

incorrect answer or waste too much time on a particular question.

Evaluation Questions Evaluation questions expect you to assess ideas and

make reasoned judgments. Take a look at the following example of an

evaluation question:

To document why your project was initiated, it is appropriate to include the:

A. Business case

B. Project mandate

C. Solution approach

D. Business goals

This is a “reasoned judgment” style of question based on what you know and the

fact that you understand what is required in this particular situation. Typical

business analysis documents used to initiate a project are created in the Strategy

Analysis knowledge area and include the business case, required capabilities,

solution scope, and business need. The correct answer is A.

Exam Spotlight

When you are taking the exam, make sure you are able to read the questions

and possible answers swiftly but accurately. You need to understand what

the question is about before you can select the correct answer. Adult readers

are notorious for skimming, scanning, and searching when they read. This

can cause you to jump to selecting the wrong answer based on what you

think you just read. Train yourself out of these bad habits and learn to read

the actual question being presented.

Remember that you will face 150 questions of various question types on your

CBAP

or CCBA

™

exam. You need to navigate these questions efficiently and

effectively to achieve a passing score on your exam. Although there is no

substitute for knowing and understanding how the BABOK

Guide says you

should do your business analysis job, your comfort with question types may also

be of assistance.

How to Use This Book

The book includes several testing features, both in the book and available for

download. Following this introduction is an assessment test that you can use to

check your readiness for the actual exam. Take this test before you start reading

the book. It will help you identify the areas you may need to brush up on. The

answers to the assessment test appear after the last question of the test. Each

answer includes an explanation and a note telling you in which chapter this

material appears.

An “Exam Essentials” section appears at the end of every chapter to highlight

the topics you’ll most likely find on the exam and help you focus on the most

important material covered in the chapter so that you’ll have a solid

understanding of those concepts. However, it isn’t possible to predict what

questions will be covered on your particular exam, so be sure to study

everything in the chapter.

Review questions are also provided at the end of every chapter. You can use

these to gauge your understanding of the subject matter before reading the

chapter and to point out the areas in which you need to concentrate your study

time. As you finish each chapter, answer the review questions and then check to

see whether your answers are correct—the correct answers appear in Appendix

F. You can go back to reread the section that deals with each question you got

wrong to ensure that you answer the question correctly the next time you are

tested on the material. If you can answer at least 80 percent of the review

questions correctly, you can probably feel comfortable moving on to the next

chapter. If you can’t answer that many correctly, reread the chapter, or the

section that seems to be giving you trouble, and try the questions again.

Don’t rely on studying the review questions exclusively as your

study method. The questions you’ll see on the exam will be different from

the questions presented in the book. There are 150 randomly generated

questions on the CBAP

exam and the CCBA

™

exam, so it isn’t possible to

cover every potential exam question in the “Review Questions” section of

each chapter. Make sure you understand the concepts behind the material

presented in each chapter and memorize all the formulas as well.

Finally, you will notice various “Real World Scenario” sidebars throughout each

chapter. These are designed to give you insight into how the various tasks and

knowledge areas apply to real-world situations.

Interactive Online Learning Environment and Test Bank

The interactive online learning environment that accompanies the

CBAP

/CCBA

™

: Certified Business Analysis Study Guide, Second Edition

provides a test bank with study tools to help you prepare for the certification

exam—and increase your chances of passing it the first time! The online test

bank runs on multiple devices. It includes the following:

Sample Tests All the questions in this book are provided, including the

assessment test at the end of this introduction and the chapter tests that include

the review questions at the end of each chapter. Use these questions to test your

knowledge of the study guide material. In addition, there are two CBAP bonus

practice exams with 50 questions each, as well as two CCBA bonus practice

exams with 50 questions each. Take these practice exams just as if you were

actually taking the exams (that is, without any reference material). When you

have finished the first exam, move on to the next exam to solidify your test-

taking skills. If you get more than 85 percent of the answers correct, you’re

ready to take the real exam.

Flashcards The online text bank includes more than 100 flashcards specifically

written to hit you hard, so don’t get discouraged if you don’t ace your way

through them at first. They’re there to ensure that you’re really ready for the

exam. And no worries—armed with the review questions, practice exams, and

flashcards, you’ll be more than prepared when exam day comes. Questions are

provided in digital flashcard format (a question followed by a single correct

answer). You can use the flashcards to reinforce your learning and provide last-

minute test prep before the exam.

Other Study Tools A glossary of key terms from this book is available as a

fully searchable PDF. A BABOK

Techniques Matrix is also available as an

Excel spreadsheet.

Go to www.wiley.com/go/sybextestprep to register and gain

access to this interactive online learning environment and test bank with

study tools.

Test Taking Tips And Advice

On your exam day, it is important that you be relaxed, psychologically prepared,

and confident. Try to be well rested and adequately nourished when you take

the exam. Staying up all night before the exam for some last-minute studying is

not a good idea.

It is a good idea to make sure you know the location of your testing center prior

to exam day. We suggest that you do a “drive by” of the location so you know

where you are going and exactly how to get there. You should also call the day

before to confirm your exam date and time and the hours of operation. A friend,

Peggy, showed up at her testing center to sit a certification exam only to

discover that the testing center location had been moved the week before. Peggy

had to rush to the other location and then begin the exam. Luckily, Peggy was an

early bird, so the damage was minimal. The testing center staff told her that she

had been notified of this testing center relocation by email, but Peggy could find

no message from them in her inbox. Try to avoid that kind of last-minute stress

if you can.

When you arrive at the testing center, you will have to lock up your personal

belongings in a locker or leave them in your car for the duration of your exam.

You cannot take any food or beverages into the exam, so they must be consumed

ahead of time or stored in the locker as well. Be sure to give yourself plenty of

time to drink that extra-large latte with four shots of espresso in it. The testing

center staff will provide you with scratch paper and pencils. They will also take

you into the testing area, seat you at your computer, provide you with

headphones to muffle the noise, and confirm that the correct exam is being

provided to you.

You have some time before the exam must start if you take the tutorial on how

to use the exam software. We recommend that you take the tutorial even though

you already know how to point and click. You can use this time to jot down any

cheat sheet notes on the scrap paper that you have prepared prior to the exam.

Of course, these notes and reminders must all be in your head since you can’t

take your own paper into the testing area.

Be aware that there might be other people in the testing area taking a wide

variety of exams, so people may come and go during your testing window. If you

are easily distracted, this activity may take your attention away from your exam.

You may take a break at any time during your exam; however, the timer keeps

going while you are away from your seat.

How to Contact the Author

Feedback about this book is welcome. If you have specific questions or

comments, please send a message to Susan Weese at susanweese@icloud.com.

You can also post questions and comments on Susan’s exam-focused blog at

cbapccba.blogspot.com. Her blog offers CBAP

and CCBA

™

exam advice and

support. Sybex strives to keep you supplied with the latest tools and information

you need for your work. Please check the book’s update page on the Sybex

website at www.sybex.com/go/cbap. Additional content and updates that

supplement this book will be posted if the need arises.

CBAP®/CCBA™: Certified Business Analysts Study Guide

BABOK® Guide Version 3.0 Knowledge Areas and

Underlying Competencies

Knowledge Area Chapter

Business Analysis Planning and Monitoring

Plan Business Analysis Approach 2

Plan Stakeholder Engagement 2

Plan Business Analysis Governance 2

Plan Business Analysis Information Management 2

Identify Business Analysis Performance Improvements 2

Strategy Analysis

Analyze Current State 3

Define Future State 3

Assess Risks 3

Define Change Strategy 3

Elicitation and Collaboration

Prepare for Elicitation 5

Conduct Elicitation 5

Confirm Elicitation Results 5

Communicate Business Analysis Information 5

Manage Stakeholder Collaboration 5

Requirements Analysis and Design Definition

Specify and Model Requirements 6

Verify Requirements 6

Validate Requirements 6

Define Requirements Architecture 6

Define Design Options 6

Analyze Potential Value and Recommend Solution 6

Solution Evaluation

Measure Solution Performance 7

Analyze Performance Measures 7

Assess Solution Limitations 7

Assess Enterprise Limitations 7

Recommend Actions to Increase Solution Value 7

Requirements Life Cycle Management

Trace Requirements 4

Maintain Requirements 4

Prioritize Requirements 4

Assess Requirements Changes 4

Approve Requirements 4

Underlying Competencies

Analytical Thinking and Problem Solving 8

Behavioral Characteristics 8

Business Knowledge 8

Communication Skills 8

Interaction Skills 8

Tools and Technology 8

Perspectives

The Agile Perspective 9

The Business Intelligence Perspective 9

The Information Technology Perspective 9

The Business Architecture Perspective 9

The Business Process Management Perspective 9

The BABOK® Guide Version 3.0 is subject to change at any time

without prior notice and at the IIBA™’s sole discretion. Please visit IIBA™’s

website (www.theiiba.org) for the most current listing.

Assessment Test

1. Who determines what BABOK

Guide tasks are appropriate for their

project?

A. Portfolio governance board

B. Business analysis team

C. Program or project manager

D. Key project stakeholders

2. Which statement about business analysis stakeholders is false?

A. They are likely to participate in business analysis tasks.

B. They are a set of roles that must be filled for the project.

C. They have a vested interest in the project and its outcome.

D. They interact with the business analyst in specific ways.

3. What term is used to define an area undergoing analysis, including both an

organization and its external stakeholders?

A. Domain

B. Solution

C. Requirement

D. Scope

4. Which statement best describes the relationship between the lead business

analyst (BA) and project manager (PM) when planning the resources and

tasks for business analysis activities?

A. BA manages all stakeholders; PM manages project team.

B. BA assigns all team roles; PM manages team work efforts.

C. BA oversees project processes; PM manages overall project.

D. BA manages business analysis work; PM manages overall project.

5. The business analysis plan is typically with and is a of the overall project

plan.

A. Estimated, element

B. Managed, subproject

C. Integrated, component

D. Produced, subset

6. What output is produced from conducting stakeholder analysis?

A. Stakeholder summary matrix and chart

B. Stakeholder roles and responsibilities

C. Stakeholder RACI matrix and onion diagram

D. Stakeholder list, map, or personas

7. What does the Business Analysis Core Concept Model (BACCM™) define?

A. Roles and characteristics of stakeholder groups and individuals

B. Conceptual framework for the business analysis profession

C. Levels or types of requirements that will be defined for a project

D. Key terms and definitions used by the business analysis team

8. What describes the parts of the enterprise a change will impact?

A. Business analysis scope

B. Change scope

C. Methodologies, approaches, and techniques

D. Underlying competencies

9. Which knowledge area’s activities are often performed as pre-project work?

A. Solution Evaluation

B. Strategy Analysis

C. Requirements Analysis and Design Definition

D. Requirements Life Cycle Management

10. Your organization has received a customer complaint about errors that the

customer encountered when trying to place an order on the company

website. As a result, a business need is evaluated. At which level of the

enterprise was this business need identified?

A. Top-down

B. External drivers

C. Middle management

D. Bottom-up

11. What describes an organization’s business processes, software, hardware,

people, operations, and projects?

A. Business architecture

B. Strategic architecture

C. Enterprise architecture

D. Technical architecture

12. The business analysis team is defining new capabilities for a current software

system along with the potential value expected from these changes. Which

task are they performing?

A. Perform gap analysis

B. Analyze current state

C. Define future state

D. Define change strategy

13. Ginger has decided that making a new, innovative sales application available

to the company’s sales force is a way to increase sales revenue in the future.

Her company and their competitors have not used this technology in this

way before. Which type of risk tolerance does this example illustrate?

A. Risk-averse

B. Risk-seeking

C. Risk-neutral

D. Risk-ready

14. Which technique compares an organization’s strategies, operations, and

processes against the “best-in-class” strategies, operations, and processes of

their competitors and peers?

A. Decision analysis

B. Benchmarking

C. Feasibility study

D. Brainstorming

15. What type of elicitation is taking place when a business analyst uses a

software prototype to elicit and confirm user requirements regarding the

usability of the interface?

A. Contextual

B. Collaborative

C. Experiment

D. Research

16. Which technique is used when managing stakeholder collaboration to

stimulate teamwork and collaboration?

A. SWOT analysis

B. Observation

C. Prototypes

D. Collaborative games

17. You are preparing to elicit requirements from a group of key stakeholders.

Which of the following high-level preparation activities will you not be

performing?

A. Determine work products.

B. Conduct a contextual inquiry.

C. Decide the elicitation techniques.

D. Establish elicitation logistics.

18. All of the following are inputs, guidelines, or tools used when confirming

elicitation results except:

A. Elicitation results (confirmed)

B. Elicitation activity plan

C. Elicitation results (unconfirmed)

D. Existing business analysis information

19. As part of your elicitation efforts, you are inspecting a person’s work

environment for the tools and information assets they use to perform their

daily work. Which type of observation are you performing?

A. Active observation

B. Contextual inquiry

C. Passive observation

D. Temporary apprentice

20. What output is produced when preparing for elicitation?

A. Business analysis information

B. Stakeholder engagement

C. Elicitation results (confirmed)

D. Elicitation activity plan

21. When does the requirements life cycle begin?

A. With development of a solution

B. With representing a need as a requirement

C. With retiring all or part of a solution

D. With approval of a business case

22. What traceability relationship is used when you are including a requirement

that is necessary only if another requirement is implemented?

A. Necessity

B. Effort

C. Satisfy

D. Derive

23. Which deliverable defines how requirements will be managed for reuse in an

organization?

A. Business analysis approach

B. Governance approach

C. Requirements architecture

D. Information management approach

24. What key input should be available to the business analyst when they are

preparing to prioritize requirements?

A. Designs

B. Requirements

C. Proposed change

D. Solution scope

25. What are the things you believe to be true on your project but that you have

not actually verified?

A. Capabilities

B. Constraints

C. Assumptions

D. Limitations

26. What types of requirements are typically developed using the tasks found in

the Requirements Analysis and Design Definition knowledge area?

A. Business

B. Stakeholder

C. Solution

D. All of the above

27. Which of the following tasks is not part of the Requirements Analysis and

Design Definition knowledge area?

A. Verify requirements.

B. Allocate requirements.

C. Define solution options.

D. Validate requirements.

28. You have decided to prioritize your solution requirements based on a cost-

benefit analysis of their relative value to the organization. What is your basis

for prioritization?

A. Policy compliance

B. Business risk

C. Technical risk

D. Business value

29. You are describing the key objectives of modelling the project’s requirements

to the project manager. The first objective is to understand what models are

appropriate for the business domain and solution scope. What is the second

objective?

A. Decompose business analysis information into components.

B. Explicitly represent requirements and their attributes.

C. Articulate requirements at the right level of abstraction.

D. Define measurable evaluation criteria for each requirement.

30. Which task is an ongoing process to ensure that stakeholder, solution, and

transition requirements align to the business requirements?

A. Allocate requirements.

B. Validate requirements.

C. Organize requirements.

D. Verify requirements.

31. What is a key distinction between Solution Evaluation knowledge area tasks

and similar tasks performed as part of Strategy Analysis or Requirements

Analysis and Design Definition?

A. Iterative and incremental approach to doing work

B. Existence of a working solution or solution component

C. Involvement of the testing team and the business analyst

D. Level of detail found in the actual work efforts

32. Which of the following items is not a stage of solution development?

A. Pilot release

B. Proof of concept

C. Network diagram

D. Operational release

33. Which element is not one of the five elements used to analyze performance

measures?

A. Risks

B. Trends

C. Complexity

D. Accuracy

34. Which technique assists you in understanding current business decisions as

part of assessing solution limitations?

A. Functional decomposition

B. Business rules analysis

C. Decision analysis

D. Process modelling

35. Which tools and guidelines are used when recommending actions to increase

solution value?

A. Business objectives, current state description, and solution scope

B. Risk analysis results, change strategy, and business objectives

C. Business objectives, future state description, and change strategy

D. Risk analysis results, current state description, and solution scope

36. Sam has worked for you for 11 months and has commented several times

how much he appreciates all the coaching he has received while working for

you. He stated that he has learned a lot just by observing your leadership

style when working with others in the organization. This is an example of

which of the following types of power?

A. Reward power

B. Expert power

C. Legitimate power

D. Referent power

37. Haley is a junior business analyst assigned to job shadow a senior user to

discover how this user does their daily job. What business analysis technique

is Haley using?

A. Brainstorming

B. User stories

C. Observation

D. Interviews

38. Experienced business analysts are familiar with existing solutions and their

capabilities within the organization. This allows them to effectively:

A. Recommend appropriate team members to carry out the solution.

B. Challenge the “as-is” state and create new paradigms.

C. Identify, assess, and implement changes to those solutions.

D. Document those existing solutions to expedite project delivery.

39. What is the formula for calculating the number of lines of communication in

a network?

A. (n × (2n))/2

B. (n × (n-2))/2

C. (n × (n-1))/2

D. (n × (n-1))/4

40. You are a business analyst applying leadership and facilitation skills to help a

larger team reach a decision on a set of solution requirements. You are

exhibiting skills from which underlying competency area?

A. Analytical thinking

B. Behavioral knowledge

C. Communication skills

D. Interaction skills

Answers to Assessment Test

The chapter references given for the solutions to this exam are

chapters of this book, not the chapters of the BABOK

Guide. You will find

the BABOK

Guide reference information in parentheses following the

chapter reference.

1. B. The business analyst and the business analysis team determine which

BABOK

Guide tasks and techniques are appropriate for their organization

and their projects. For more information, see Chapter 1. (Intro)

2. B. The list of business analysis stakeholder roles is not a set of roles that

must be filled for a project or initiative. They are a suggested set of generic

stakeholder roles that may play a role in business analysis activities. For

more information, see Chapter 1. (Intro)

3. A. A domain is the area undergoing analysis and may include both the

organization and its stakeholders. For more information, see Chapter 1.

(Intro)

4. D. The lead business analyst or the business analysis team needs to develop,

define, and manage the roles and tasks associated with business analysis

activities in coordination with the project manager. The business analyst is

responsible for providing clearly defined requirements deliverables for the

project. For more information, see Chapter 1. (Intro)

5. C. The business analysis plan is typically integrated with and a component of

the overall project plan. This is the responsibility of the project manager. For

more information, see Chapter 2. (BAPM)

6. D. The output from conducting stakeholder analysis is the stakeholder list,

map, or personas. For more information, see Chapter 5. (E&C)

7. B. The BACCM™ provides a conceptual framework for the business analysis

profession. The model covers six core concepts for each knowledge area:

change, need, solution, stakeholder, value, and context. For more

information, see Chapter 1. (Intro)

8. B. In the BABOK

Guide structure, the change scope defines the parts of the

enterprise a change encompasses and to what extent it impacts the

objectives and operations of the enterprise. For more information, see

Chapter 1. (Intro)

9. B. Many activities performed by a business analyst are not part of a specific

project. Strategy Analysis activities are often considered pre-project work or

an early feasibility phase of a project. For more information, see Chapter 3.

(SA)

10. B. The business need evaluation was triggered by a customer complaint. This

trigger is an external driver. For more information, see Chapter 3. (SA)

11. C. The enterprise architecture describes an organization’s business

processes, software, hardware, people, operations, and projects, as well as

the relationships between them. For more information, see Chapter 3. (SA)

12. C. The Define Future State task in the Strategy Analysis knowledge area

defines new capabilities and the potential value expected from these

changes. For more information, see Chapter 3. (SA)

13. B. Risk seeking is the risk tolerance showing a willingness to accept or even

take on more risk relative to a change in return for higher potential value.

For more information, see Chapter 3. (SA)

14. B. Used during Strategy Analysis activities, benchmarking compares an

organization’s strategies, operations, and processes against the “best-in-

class” strategies, operations, and processes of their competitors and peers.

For more information, see Chapter 3. (SA)

15. C. When conducting elicitation, there are three types of elicitations the

business analyst can use: collaborative, research, or experiments.

Experiments can be either observational studies, proofs of concept, or

prototypes. For more information, see Chapter 5. (E&C)

16. D. Collaborative games are used during elicitation to stimulate teamwork

and collaboration by immersing participants in a safe and fun situation to

share knowledge and experience on a given topic. For more information, see

Chapter 5. (E&C)

17. B. When preparing for elicitation, the BABOK

Guide recommends the

following activities take place: Determine the work products to be produced

by the elicitation activity, decide the elicitation techniques to use, establish

elicitation logistics, identify any supporting materials, and foster stakeholder

collaboration. For more information, see Chapter 5. (E&C)

18. A. The elicitation results (unconfirmed) are an input to the Confirm

Elicitation Results task. The elicitation activity plan and existing business

analysis information are tools and guidelines for the task. The elicitation

results (confirmed) are the output of the task. For more information, see

Chapter 5. (E&C)

19. B. The three variations on the observation technique are active, passive, and

contextual inquiries. Contextual inquiries involve inspecting a person’s work

environment for the tools and information assets they use to perform their

work. For more information, see Chapter 5. (E&C)

20. D. The output produced when preparing for elicitation is the elicitation

activity plan. For more information, see Chapter 5. (E&C)

21. B. The requirements life cycle begins with the representation of a business

need as a requirement. For more information, see Chapter 4. (RLCM)

22. A. Necessity, a subset of depends, is the traceability relationship used when

including a requirement that should be implemented only if a related

requirement is also implemented. For more information, see Chapter 4.

(RLCM)

23. D. The information management approach defines how requirements will be

managed for reuse in an organization as part of the Maintain Requirements

task. For more information, see Chapter 4. (RLCM)

24. B. When preparing to prioritize requirements, the key task inputs include the

requirements themselves. For more information, see Chapter 4. (RLCM)

25. C. Assumptions are agreed-to facts that may influence an initiative.

Assumptions are typically documented in the Business Case along with the

solution alternatives to be considered. For more information, see Chapter 3.

(SA)

26. D. All types of requirements can be developed in more detail using the tasks

of the Requirements Analysis and Design Definition knowledge area. For

more information, see Chapter 6. (RADD)

27. B. The allocate requirements task is part of the Solution Evaluation

knowledge area. For more information, see Chapter 6. (RADD)

28. D. Business value is a basis for prioritizing requirements using a cost-benefit

analysis of their relative value to the organization. For more information, see

Chapter 4. (RLCM)

29. A. The four elements of the Specify and Model Requirements task are: 1.

Understand what models are appropriate for the business domain and

solution scope, 2. Decompose business analysis information into

components, 3. Explicitly represent requirements and their attributes, and 4.

Articulate requirements at the right level of abstraction. For more

information, see Chapter 6. (RADD)

30. B. The Validate Requirements task in the Requirements Analysis and Design

Definition knowledge area is an ongoing process to ensure that stakeholder,

solution, and transition requirements align to the business requirements.

For more information, see Chapter 6. (RADD)

31. D. An important distinction between the tasks performed in the Solution

Evaluation knowledge area and tasks performed in other knowledge areas is

the existence of an actual solution or solution component that is

implemented and operating in some form. For more information, see

Chapter 7. (SE)

32. C. A network diagram is a project planning technique and is not a stage of

solution development.” For more information, see Chapter 7. (SE)

33. C. The five elements used to analyze performance measures during Solution

Evaluation are solution performance versus desired value, risks, trends,

accuracy, and performance variances. For more information, see Chapter 7.

(SE)

34. C. The decision analysis technique assists you in understanding current

business decisions as part of assessing solution limitations. For more

information, see Chapter 7. (SE)

35. A. The tools and guidelines for the recommended actions to increase solution

value task are the business objectives, current state description, and solution

scope. For more information, see Chapter 7. (SE)

36. D. Referent power is given to you by your subordinates based on their

respect and regard. For more information, see Chapter 8. (Competencies)

37. C. Haley is learning what the end user does in their job by observing how end

users do their work. For more information, see Chapter 5. (E&C)

38. C. Experienced business analysts are familiar with existing solutions and

their capabilities within the organization. This allows them to effectively

identify, assess, and implement changes to those solutions. For more

information, see Chapter 8. (Competencies)

39. C. The correct calculation for the number of lines of communication in a

network is (n × (n-1)) divided by 2, where n = the number of people or nodes

in the network. For more information, see Chapter 8. (Competencies)

40. D. Interaction skills include the ability to work as part of a larger team and to

help that team reach decisions. This is done through a combination of

leadership and facilitation. For more information, see Chapter 8.

(Competencies)

Chapter 1

Foundation Concepts

CBAP

/CCBA™ EXAM TOPICS COVERED IN THIS CHAPTER

Describe business analysis and the role of the business analyst.

Explain the Business Analysis Core Concept Model (BACCM™).

Explore the six business analysis knowledge areas.

Recognize the basic contents, structure, and intent of the

BABOK

Guide.

Define the BABOK

Guide requirements classification scheme.

Map business analysis activities to a generic project life cycle.

Understand the content and intent of the BABOK

Guide.

This chapter lays the foundation for navigating and

understanding the content and intent of A Guide to the Business Analysis Body

of Knowledge

(BABOK

Guide). It is our high-level look at what it means to

be a business analyst and how to successfully perform business analysis work.

Business analysts can be found in all facets of an organization—projects,

programs, strategic planning, operations, or other initiatives. Although the

examples in this chapter use projects and the project life cycle to step through

the discipline, remember that business analysts do not have to be members of a

project team to do their jobs. They can work almost anywhere.

The set of generally accepted best practices defined by the BABOK

Guide

provides a business analysis framework defining areas of knowledge, associated

activities and tasks, and the skills required to perform them. The scope of this

standard covers pre-project activities, the full project life cycle, and the final

product’s operational life.

What Is Business Analysis?

Let’s start with an example of how difficult it can be to do business analysis

work when you are not certain where to begin. New business analysts start their

careers in a number of ways. In the past, it was not uncommon for young

software engineers to transition into the business side of an organization when

their manager called them into their office, saying, “We are short-staffed, and I

need you to figure out what the users need this new software application to do.”

The fledging business analyst needed to discover who to talk to, what to ask,

how to ask, and how to document the information that they discovered in a way

that made sense to the development team and to the business. This was not an

easy task the first time around!

In this situation, performing basic business analysis work took a lot longer than

it seemed like it should. These unprepared rookie business analysts had great

difficulty deciding exactly how to get started. There was no process in place to

guide them and no one available to point them in the right direction. They found

themselves longing to go back to their cubicles and just write some more code.

Luckily, there is no need for business analysts to feel this way today. There are

standards, books (like this one), websites, blogs, and tons of experienced folks

out there to mentor and guide business analysts in getting the job done right.

Business analysis is the glue that holds successful organizations together. It is a

distinct discipline focusing on identifying business needs, problems, and

opportunities, and on determining the appropriate solutions to address them.

The resulting projects and initiatives may focus on systems development,

process improvement, organizational change, or some combination of the three.

Business analysis touches all levels of an organization: strategic, tactical, and

operational. Business analysts participate across the project and the product life

cycles as they look at all aspects of an organization’s enterprise architecture,

stakeholder needs, business processes, software, and hardware.

The set of generally accepted best practices defined by the BABOK

Guide make

this book an essential resource for every business analyst. You should take this

basic business analysis framework and make it work for you and your projects.

The areas of knowledge, associated activities and tasks, and the skills required

to perform them will give you a valuable starting point for introducing,

validating, or improving your business analysis processes throughout an

organization. Even better, the scope of the BABOK

Guide covers pre-project

activities, the full project life cycle and the final solution’s operational life.

The BABOK

Guide focuses on building underlying competencies that make for

a successful business analyst on today’s projects and initiatives. The BABOK

Guide defines business analysis as “the practice of enabling change in an

enterprise by defining needs and recommending solutions that deliver value to

stakeholders.” Put simply, a business analyst is defined as anyone performing

these business analysis activities.

When looking at business analysis in an organization, you need to make sure

that you know how the organization views its business analysts. First, what is

the role of the business analyst? Second, what is the expected relationship

between the business analyst and the project manager? And third, who are the

stakeholders with whom the business analyst will be interacting along the way?

We will look at each of these topics next.

The Business Analyst’s Role

The linchpin of successful business analysis is the business analyst performing

the actual work. Their involvement in defining and validating solutions that

address key business needs and goals is essential to both project and business

success. According to the BABOK

Guide, “a business analyst is any person who

performs business analysis tasks described in the BABOK® Guide, no matter

their job title or organizational role.” Business analysts work as liaisons among

stakeholders in order to understand the structure, policies, and operations of an

organization, and to recommend solutions that enable the organization to

achieve its goals.

So, what exactly is the job description for the business analyst? There have been

many job postings lately that came straight from the BABOK

Guide role

definition. That is a good sign. The adoption and integration of these principles

as best practices in the corporate environment will lead to stronger business

analysis process, better business analysts, and more credibility and consistency

in the role of business analysts today. Here is a short list of the business

analyst’s job responsibilities from the BABOK

Guide:

Discovers, synthesizes, and analyzes enterprise information

Understands enterprise problems, opportunities, and goals in the context of

the requirements

Analyzes needs and solutions

Devises strategies and drives change

Facilitates stakeholder collaboration

In many organizations, the folks performing business analysis

work do not have the job title of “business analyst.” The business analyst

role can be filled by anyone performing business analysis work regardless of

job title. The BABOK

Guide lists a number of job roles that may do

business analysis work, such as business system analysts, requirements

engineers, process analysts, product managers or owners, enterprise

analysts, business architects, and management consultants.

Essential Skills of Effective Business Analysts

Business analysts must possess a wide spectrum of skills and knowledge. Being

a technical expert in a particular area does not guarantee success as a business

analyst on a project. In addition to the necessary business, technical, and

domain knowledge, the business analyst should have management,

interpersonal, business, and structured problem-solving skills.

Reviewing Requirements over a Cup of Coffee

Years ago, Phil was the technical team lead for a team working on an

executive compensation system for top-level management. The team needed

input from a small, closed community of senior and executive management

customers in order to define the current and future processes.

Unfortunately, his key contact from this group felt that the job of customer

interface had been given to a young, up-and-coming star who didn’t have a

clue. This made developing a rapport with the key customer contact almost

impossible. However, the project deadlines remained inflexible, as they

usually do.

Taking what little input was offered and doing significant research from

other sources, the team compiled their draft of the business requirements

document. The document was huge. It was single-spaced and double-sided,

and it filled a 3-inch binder. There was a meeting to step through it. The

customer contact was there and took her place at the head of the table. Phil

sat at the opposite end of the table.

During the meeting, the customer’s demeanor grew increasingly agitated.

She hurled the requirements document down the table along with the

exclamation, “I don’t do this kind of menial work.” Unfortunately, Phil

reacted by returning the document in the same manner. His aim wasn’t

quite as true, and the document slammed into her coffee cup sending a

spray of hot, sugary liquid into her lap. Her color changed from the red of

aggravation to the scarlet of rage. She stalked out of the room. So much for

creating rapport with the customer! In the end, it all worked out. Both

parties apologized, and the project (meeting the business requirements that

had been approved) was delivered. But how much better things could have

been if this situation had been avoided in the first place.

Technical skills and expertise are necessary on the project team, but they are

not the skills and knowledge that separate effective business analysts from

the pack. Superior business analysis skills are not necessarily derived from a

superior set of technical skills.

Soft skills and knowledge support and enable effective business analysis.

Knowing what to do and when to do it is a good start for a business analyst, but

how you actually do that work makes a big difference! The BABOK

Guide

refers to these behaviors as the underlying competencies of effective business

analysts. The underlying competencies are in addition to knowing what business

analysts produce from a work activity and a deliverable perspective. They

encompass the interpersonal skills and additional business and technical

knowledge that are necessary for doing the business analyst’s job well. These

essential skills range from applying structured analysis techniques to issue

management to addressing solution usability concerns.

The BABOK

Guide puts the essential skills and knowledge of effective business

analysts into six categories. Let’s take a quick look at each of these categories

that are the building blocks for the business analyst’s skill and knowledge.

Analytical Thinking and Problem-Solving Skills Facilitating solutions to

business problems would be impossible without a logical mind. Analytical

thinking and problem-solving skills enable the business analyst to assess and

understand a situation. Once that situation is fully understood, the business

analyst assesses and recommends one or more potential solutions to address the

business need, problem, or opportunity.

Behavioral Characteristics Effective business analysts apply personal

integrity and strength of character when dealing with people, including the

business analysis team, project team, and internal and external project

stakeholders. The ability to build strong, lasting working relationships serves

the business analyst, the enterprise, and the project or initiative well.

Business Knowledge It is impossible to be a liaison between the business and

the technology if you have no understanding of the business. Skilled business

analysts understand the internal and external business environment

surrounding their projects, and they use that knowledge to make good decisions

and recommendations.

Communication Skills The number-one reason for project failure is poor

communication. Business analysts must have excellent communication skills,

verbal, nonverbal, and written, in order to complete business analysis tasks.

Interaction Skills Good business analysts are team players. In large part, this

is because of their ability to interact and work well with other members of the

team. Leadership, negotiation, and facilitation skills play a key part in defining

and agreeing to a solution to a business problem or need.

Tools and Technology Software applications are typically used by the

business analyst to develop and manage requirements. This can range from

using a word processor to document project scope to using a requirements

management tool to develop detailed user and system requirements. Although

using a requirements management tool is not a required skill, the ability to

master and apply requirements management, word processing, and spreadsheet

tools are desirable traits in experienced business analysts.

The underlying competencies of effective business analysts have

numerous pieces and parts. In Chapter 8, “Underlying Competencies,” we

will discuss them in more depth along with a few additional skills that you

might want to use on your projects.

The Business Analyst and the Project Manager

There is much buzz about the potential for overlap and conflict between the

project manager and the business analyst. Interestingly enough, many project

managers perform business analysis work early in their projects—developing

feasibility studies, business cases, scope statements, and business-level

requirements as part of project selection, initiation, and scope definition. Many

project managers were part of the business analysis team earlier in their careers.

As a result, many project managers have business analysis skills to complement

and overlap their project management skill set.

The project manager’s responsibilities differ from the responsibilities of the

business analyst in several ways. The project manager focuses on meeting the

project objectives. They initiate, plan, and manage the project. The project

manager makes sure the project team delivers a solution that meets

requirements, the acceptance criteria, and the customer’s quality expectations.

The project manager juggles the many constraints present on a project, such as

scope, budget, schedule, resources, quality, and risk. On a large project, the

business analysis team is only one part of the project resources the project

manager is managing.

The business analyst and the project manager typically work closely together on

projects and must maintain good communications. However, there is potential

for the project manager and the business analyst to be in conflict with one

another. The business analyst works with key stakeholders to understand the

structure, policies, and operations of an organization and to recommend

solutions. The project manager focuses on planning and managing the project to

achieve the project objectives and deliver those solutions to the stakeholders.

Where are they going to step on each other’s toes? There are two key areas for

conflict: stakeholder communication and planning.

The project manager and the business analyst both need to communicate well

with key stakeholders. Without planning and discussion, the project manager

and the business analyst could easily come to blows about who “owns” the

stakeholders, when in actuality the project “owns” the stakeholders. A good

project-level communications plan needs to be built and followed to minimize

potential areas of political game play and conflict. As far as planning goes, the

business analysis team must remember that it is a subset of the project team. As

such, any business analysis work plans they put together must be consistent

with and roll up into the overall project plan.

Dealing with Key Stakeholders

There is no project without stakeholders. Stakeholders have a vested interest in

the project and its outcome, and they are the major source of requirements,

constraints, and assumptions for the business analyst. Remember that

stakeholder roles are like hats—one person may wear multiple hats and fill more

than one role on a project.

There are a number of generic stakeholders who will interact with the business

analyst across the project life cycle. While the list in Table 1.1 doesn’t cover every

possible role, it is a good starting point for who should be involved with your

business analysis activities. Many organizations have different names for the

same role, so don’t get excited if these are not the generic stakeholder roles with

which you are familiar. In addition to the business analyst, there are a number

of key stakeholder roles involved with business analysis activities. They are

summarized in Table 1.1.

TABLE 1.1 Key business analysis stakeholders

Stakeholder Description

Customer Uses the products, services, or solutions

Domain subject

matter expert

(SME)

Possesses detailed, in-depth knowledge of a particular topic

or problem area of the solution scope or the business need

End user Directly interacts with the resulting solution when it has been

completed and deployed

Implementation

SME

Is responsible for designing and implementing potential

solutions and providing specialist expertise Subsets of the

implementation SME role include developers, software

engineers, organizational change management professionals,

system architects, trainers, and usability professionals.

Operational

support

Helps to keep the solution functioning by providing end-user

support or day-to-day operational support

Project

manager

Manages the work performed to deliver the solution

Tester Verifies that the designed and constructed solution meets the

requirements and quality criteria for that solution

Regulator Defines and enforces standards for developing the solution or

for the resulting solution itself

Sponsor Authorizes the solution development work to be performed

and controls the budget

Supplier Provides products or services to the organization

Exam Spotlight

These stakeholder role names and definitions from the BABOK

Guide are

exactly what you will see in your exam questions. The business analyst is a

stakeholder for all business analysis activities and is responsible and

accountable for their execution. Remember that stakeholder roles are like

hats. One person can wear one or many hats across the project life cycle.

The roles are not necessarily the same as their job titles; however, they do

indicate the job responsibilities and the level of accountability for the person

filling that particular role on a project.

Reviewing the Business Analysis Core Concept Model

(BACCM™)

The Business Analysis Core Concept Model (BACCM™) provides you with a

conceptual framework that shows what it really means to be a business analyst.

This framework creates a common, generic language describing the business

analysis profession. You can use this common language to discuss what you do

with a business analyst working in a different industry.

There are six concepts in the BACCM™: change, need, solution, stakeholder,

value, and context. You need to understand all of these concepts in relation to

one another to be an effective business analyst. They are the framework for a

successful business analysis effort.

Change Change is the driving force for most projects and initiatives. Change

takes place when one responds to satisfy a need. You need to be aware of the

enterprise-level changes that will result from your project efforts and outcome.

Need Businesses and their stakeholders have needs that often result in projects.

Needs are value-driven ways to address business problems or opportunities.

Solution Solutions are the end result of projects and initiatives. They resolve

the problems or take advantage of the opportunities. Solutions satisfy needs

within the context of the enterprise and its environment.

Stakeholder Stakeholders are the people who have a relationship to the

change, need, or solution. Stakeholder analysis often groups stakeholders

relative to these relationships.

Value Value is the worth of something to a stakeholder within the context of

the enterprise. Business analysts assess value as a tangible or intangible thing.

Business analysts should assess value from the key stakeholder’s point of view.

Context Context is the environment where the change is taking place.

The BACCM™ and its six concepts help you assess the quality and completeness

of the work you are doing. As you will see, the concepts intertwine as you work

through a project. A change that affects the tasks, tools, inputs, or deliverables

covered by one of the concepts presents an opportunity for reevaluation of the

impact on the other five concepts. The magnitude of the change, as well as

where you are in the project life cycle, determines how significant the changes

may be. The effects can be felt both in your current projects and in what may

need to change moving forward.

Exploring the Business Analysis Knowledge Areas

The BABOK

Guide is based on a set of knowledge areas guiding the business

analyst when they perform business analysis activities at any point in the project

or product life cycle. Knowledge areas define what business analysts need to

understand and the tasks they should perform. They do not represent project

phases, and their activities are not intended to be performed in a linear fashion.

Tasks from one or more knowledge areas may be performed in any order (such

as in succession, simultaneously, or iteratively), provided that the necessary

inputs to each task are available.

Six knowledge areas are defined by the BABOK

Guide. If you are planning to

take the Certified Business Analyst Professional (CBAP®) or Certification of

Competency in Business Analysis (CCBA™) exam, you will need to memorize

the high-level definition of each knowledge area, as well as the more detailed

tasks, elements, inputs, and outputs. If you are interested in applying these

knowledge areas to your work world, you will need to master the tasks and the

skills in order to become an effective business analyst. Figure 1.1 shows the

relationships between the six knowledge areas listed here:

Business Analysis Planning and Monitoring

Elicitation and Collaboration

Requirements Life Cycle Management

Strategy Analysis

Requirements Analysis and Design Definition

Solution Evaluation

FIGURE 1.1 Relationships between knowledge areas

Knowledge Area: Business Analysis Planning and Monitoring

In the Business Analysis Planning and Monitoring knowledge area, a business

analyst plans how to approach the business analysis effort. The approach is a set

of processes, templates, and activities used to perform business analysis in a

specific context. The tasks organize and coordinate the performance of all other

business analysis tasks. These planning and monitoring activities take place

throughout the project life cycle. The results of this knowledge area guide the

tasks found in the remaining five knowledge areas and set the performance

metrics to be used to evaluate all business analysis work.

So, what is a business analyst to do? Well, the business analyst’s task list for this

particular knowledge area consists of the following:

Planning the business analysis approach for the project

Determining how to engage stakeholders, including stakeholder

identification, analysis, and categorization

Defining the business analysis governance activities for decision making

Addressing business analysis information management needs

Planning the requirements development and management process

Managing and reporting on the business analysis effort

Knowledge Area: Strategy Analysis

Strategy Analysis focuses on how the business analyst identifies the business

needs driving a project by performing problem definition and analysis. In

addition to defining and refining these strategic or tactical needs, the business

analyst is responsible for defining a feasible solution scope that can be

implemented by the business. This work may also include developing a business

case or feasibility study for a proposed project. Typically, the tasks in this

knowledge area occur prior to or early in the project life cycle. The business

analyst’s task list for this knowledge area includes translating business strategy

into proposed new business or enterprise solutions by doing the following:

Defining and understanding the business problem or opportunity

Assessing capability gaps in the organization by analyzing the current and

future states

Assessing risks relative to the proposed solution

Defining the change strategy for the initiative

Determining the most feasible business solution approach

Knowledge Area: Requirements Life Cycle Management

Requirements Life Cycle Management defines how the business analyst

approaches managing and maintaining requirements. Tasks and techniques for

managing changes, conflicts, and issues related to requirements are also

described. Business analysts perform requirement management tasks as part of

requirements development work by doing the following:

Managing requirements traceability

Maintaining requirements for accuracy and reuse

Addressing requirements prioritization

Determining how requirements should change

Facilitating requirements approval

Knowledge Area: Elicitation and Collaboration

Elicitation and Collaboration defines how business analysts work with

stakeholders to elicit requirements and understand stakeholder needs and

concerns. This knowledge area also addresses ongoing collaboration and

communication during all business analysis activities. The business analyst’s

task list for this knowledge area consists of the following:

Preparing for elicitation activities

Meeting with stakeholders to conduct the elicitation activity

Confirming, documenting, and recording the elicitation results

Communicating and confirming elicitation results with key stakeholders

Knowledge Area: Requirements Analysis and Design Definition

Requirements Analysis and Design Definition describes how the business

analyst progressively elaborates to define, refine, prioritize, and organize

requirements. In essence, the business analyst takes the elicited information

and makes sense of it to derive the real requirements for the project. This

knowledge area also focuses on graphically modeling the requirements and

resulting designs as well as documenting them. When performing these tasks,

the business analyst should ensure the feasibility of the requirements while

defining, describing, and refining the characteristics of an acceptable solution.

The business analyst’s task list for this knowledge area consists of the following:

Specifying and modeling requirements and designs

Verifying requirements and designs

Validating requirements and designs

Defining the architecture and structure of requirements

Defining solution options

Analyzing value and recommending a solution

Knowledge Area: Solution Evaluation

Solution Evaluation focuses on assessing and validating proposed, in progress,

and implemented solutions before, during, and after the project life cycle. A

business analyst’s attention is on the value that the solution will deliver to the

enterprise, including the constraints that may impact value. While many tasks

in this knowledge area take place later in the project life cycle, some solution-

focused activities may occur quite early. The business analyst’s task list for this

knowledge area consists of the following:

Defining solution performance measures

Collecting and analyzing solution performance data

Assessing solution limitations

Assessing enterprise limitations

Recommending actions to increase solution value

You will examine each knowledge area and every task within it in great detail in

the coming chapters. You will need this level of knowledge to successfully

prepare for and pass the certification exam. You will also need this level of

knowledge to be an effective business analysis practitioner in your organization.

How Are the Knowledge Areas Organized?

The BABOK™ Guide breaks down knowledge areas into tasks that specify what

work business analysts need to perform. The business analyst can dip into one

or more tasks at any time—in any order—to select a deliverable or learn to apply

a particular technique. The knowledge areas are not a road map or a

methodology; they simply break business analysis stuff into common areas.

To achieve the purpose of a particular knowledge area, the business analyst

must perform a defined set of high-level tasks. Each task has a particular

purpose and adds value to the overall effort when performed. The expectation is

that a business analyst will perform each task at least once during any project.

Each knowledge area task is broken down into the following pieces:

Purpose

Description

Inputs

Elements

Guidelines and Tools

Techniques

Stakeholders

Outputs

The content of each task is defined using the same structure. Let’s take a closer

look at this structure now.

Purpose Each task starts off with a short description of its purpose: why that

task is needed and what value performing the task creates.

Description The task description explains a task to the business analyst in

greater detail, including what the task actually is, why the task is performed, and

what the task should accomplish.

Inputs Inputs consist of the information and preconditions tasks require so

that task can begin. These inputs must be usable by the task that needs them.

Single or multiple business analysis tasks produce inputs externally.

Elements Elements are the detailed concepts that are necessary to perform a

particular task. For some tasks, the elements are categories of things a business

analyst must consider. For other tasks, the elements are subtasks a business

analyst performs.

Guidelines and Tools Guidelines and tools list resources a business analyst

uses to transform a task input into the resulting task output. Guidelines provide

instructions to the business analyst for executing a task. Tools provide things

the business analyst can use to perform the task.

Techniques Techniques guide the business analyst in the ways a particular

task might be done. The techniques in the BABOK

Guide are best practices

that many business analysts use. However, business analysts can certainly use

techniques that are not found in the BABOK

Guide.

Exam Spotlight

When you are reviewing and learning the techniques from the BABOK

Guide, make sure you don’t miss anything! Techniques are summarized in

Appendix C, “Mapping Techniques, Stakeholders, and Deliverables to

Knowledge Areas and Tasks,” of this book and are defined in Chapter 10 of

the BABOK

Guide. They can be used by any task, and many are used by

more than one task.

Stakeholders All tasks come with a generic list of stakeholders who may be

involved in performing that task or who might be affected by the task and its

outcome. Interestingly enough, the business analyst is a stakeholder for every

business analysis activity found in the BABOK

Guide. This makes perfect sense

—the business analyst is responsible and accountable for making sure that these

tasks are done and done well. Remember that earlier in this chapter we took a

look at the key generic stakeholder roles that typically interact with business

analysts on their projects.

Outputs Outputs are the results that successfully completed tasks deliver. One

task can have a single or many outputs.

Exploring Requirements

Projects are successful when stakeholders, including business analysts, clearly

state and agree upon desired accomplishments. For most projects, this

statement consists of defining the high-level scope of the project along with its

more detailed project requirements. The general definition of a requirement is

something wanted or needed. Business analysts in many organizations spend a

lot of time developing requirements. This is a good thing. Defining and

documenting requirements allow a business analyst to quantify and document

the needs, wants, and expectations of project stakeholders.

The BABOK

Guide uses the term requirement to cover many aspects of the

business and its needs. Their broad view of requirements addresses both the

current state of the business and its desired future state. Requirements may

focus on the business, the users, or the systems and subsystems that already

exist or are being considered. Requirements range from high-level enterprise

capabilities to organizational structure and roles to processes and policies.

Information systems fall into the requirements realm, as do business rules.

Requirements analysis activities are also quite broad in nature. There is no

prescription for the correct level of detail in your project requirements other

than what is sufficient for understanding and subsequent action.

Distinguishing Between Requirements and Design

Requirements and design are closely linked. Many times, the distinction

between requirements and design is unclear. Business analysts will use the same

techniques to elicit, model, and analyze requirements and designs on their

projects. Figure 1.2 shows the relationship between requirements and design in

the BABOK

Guide.

FIGURE 1.2 Requirements and design cycle

For the exam, remember that requirements focus on defining the opportunity or

need to be addressed. Design focuses on the solution that will result from

addressing that opportunity or need. When a business analyst is defining and

documenting project requirements, the business analyst is building a “usable

representation of a need.” When the focus of specifying and analyzing elicitation

results is on the solution, the outputs being produced are referred to as designs.

Exam Spotlight

Remember that requirements focus on the need, and designs focus on the

solution that will address that need.

Defining the Requirements Management Process

The requirements management process is a detailed subset of the business

analysis approach, targeting how the team performs requirements development

activities for a project. The process should be documented in the requirements

management plan. This deliverable defines many things, including the

following:

How the team will deal with requirements traceability

The explicit process for developing requirements

How requirements will be prioritized

What requirements attributes will be collected

How changing requirements will be handled both during requirements

development and after the requirements are agreed upon and baselined

Who will review and approve requirements and any requested changes

In addition, the requirements management process defines the types or classes

of requirements found on the project. Often, these requirements classes are

associated with a particular requirements document. Classifying requirements

allows the business analysis team to make sure that their project requirements

are reviewed and understood by the correct stakeholders. Requirements classes

help you determine the appropriate level of detail and the specificity needed in

the project requirements, and they help you decide how many documents you

will use to define what is needed.

Requirements classes can be defined using two dimensions: focus and type.

Requirements classified by focus tend to be named in a more traditional way.

Here are some examples:

High-level business requirements

User requirements

System requirements

Software requirements

Each lower level of requirements defines the level above it in greater detail. This

is a form of progressive elaboration, where the characteristics of the solution are

determined incrementally and in greater detail as the project moves forward in

time. After all, the more information you have, the better your solution

definition will become. Solutions are typically defined at a high level of detail

early in a project or initiative and then are refined into more detail over time as

additional information is gathered and analyzed.

Classifying Requirements

The BABOK

Guide defines a requirement as a condition or capability needed

by a stakeholder to solve a problem or to achieve an objective. This aligns nicely

with the International Institute of Electrical and Electronics Engineers (IEEE)

definition of requirements for software-intensive systems. Regardless of project

type, a business analyst must use project requirements to design, develop, and

deliver a solution that adds value to the business as a whole.

Different organizations use different names for requirements classes. To

implement the BABOK

Guide requirements classification scheme, a business

analyst needs to assess and map the levels of requirements in their

organization’s existing requirements process documents. While the exam

requires that you know the requirements classification scheme, you don’t have

to use BABOK

Guide requirements classes. However, it is good practice that

your requirements development approach addresses all of the BABOK

Guide

requirements classes in some way. Figure 1.3 shows the relationships between

the BABOK

Guide requirements classes.

FIGURE 1.3 Classes of requirements

Let’s take a closer look at each class of BABOK

Guide requirements.

Business Requirements Business requirements are the highest level of

requirements and are developed during Strategy Analysis activities. They define

the high-level goals, objectives, and needs of the organization. They also

describe and justify the high-level business functionality that is needed in the

resulting solution. To define a solution, business analysts will progressively

elaborate and decompose business requirements to the next level of detail, the

stakeholder requirements.

In the BABOK

Guide, business requirements are not contained within a single,

standalone document. They are contained in a set of Strategy Analysis task

deliverables, including the business need, the required capabilities, the solution

scope, and the business case. (We will look at these deliverables in more detail

later when we dig into this knowledge area in Chapter 2, “Controlled Start:

Strategy Analysis.”)

Stakeholder Requirements These requirements define the needs of

stakeholders and how they will interact with a solution. Stakeholder

requirements bridge between the business requirements and the more detailed

solution requirements. Many folks refer to stakeholder requirements as high-

level user requirements. They identify what is needed from the user’s

perspective and define “big picture” capabilities that the resulting solution must

possess.

Business analysts develop and define stakeholder requirements as part of the

tasks found in the Requirements Analysis and Design Definition knowledge

area. Like with the business requirements, the business analyst will

progressively elaborate stakeholder requirements into the more detailed

solution requirements.

Solution Requirements Solution requirements are the most detailed type of

requirements found in the BABOK

Guide. They describe the solution

characteristics that meet the higher-level business and stakeholder

requirements. Typically, a business analyst divides solution requirements into

two specific types: functional requirements and nonfunctional requirements. A

business analyst develops and defines solution requirements as part of the tasks

found in the Requirements Analysis knowledge area.

Functional Requirements Functional requirements define the

capabilities that a product or solution must provide to its users. They are a

subset of the solution requirements that the business analyst develops for

the project.

Nonfunctional Requirements Nonfunctional requirements describe

quality attributes, design and implementation constraints, and external

interfaces that the product must have. They are a subset of the solution

requirements that the business analyst develops for the project, and they are

typically paired up with the functional requirements that they constrain in

some way. They would add characteristics to the functional requirements.

Transition Requirements Transition requirements define the solution

capabilities required to transition from the current state to the future state and

are no longer needed once the transition is complete. Typically, the business

analyst creates transition requirements later in the project life cycle after

defining both the current and new solutions. Business analysts develop and

define transition requirements as part of the tasks found in the Solution

Evaluation knowledge area.

Case Study: Palmer Divide Vineyards

You are a team member at Palmer Divide Vineyards, currently defining its

new green initiative. The owners would like to conserve energy and water

resources, reduce pollution, recycle more effectively, and become a certified

Green Business. Your manager has assigned you to lead the team to discover

the IT requirements for the project.

Following discussions with the IT group, you learn that the existing

information systems will not support the ongoing green initiative research

studies. You recommend that Palmer Divide’s business requirements

include the following statement: “The vineyard operation shall upgrade

existing information systems to support ongoing green initiative research

studies.”

Breaking down the IT system business requirement for the vineyard yields

the following stakeholder requirement focusing on stakeholder interaction

with the system: “The research team sets up the tracking data for a new

green initiative study.” This would be one of many stakeholder capabilities

that the upgraded systems would provide.

Next, you look into the solution requirements for the stakeholder study

parameter capabilities and recommend that the project solution

requirements include the following: “The research study leader logs into

the system with study leader access privileges. The research study leader

defines the set of research study data fields for their research project.” This

would be a functional requirement.

A nonfunctional requirement accompanying the previous set of functional

requirements addresses the access and authentication parameters for

logging in to the system. “Logging in as a study leader provides read,

write, update, and delete capabilities for selected study data.”

Transition requirements included data conversion activities for the

upgraded IT system.

Our favorite requirements classification scheme comes from the software

engineering standards developed by the Institute of Electrical and Electronics

Engineers. It focuses on the three Cs—capabilities, conditions, and constraints.

According to the IEEE, a requirement is a capability needed by a user to solve a

problem to achieve an objective. These capabilities must be met or possessed by

a product to satisfy a contract, standard, specification, or other formally

imposed documentation. Conditions and constraints together equal the

nonfunctional requirements classification found in the BABOK

Guide.

Conditions are statements that determine a possible outcome, like the “if” part

of an “if-then” statement. Constraints are limits or boundary values for a

particular function or capability.

Classifying Project Requirements Your Way

The IEEE requirements classes align quite nicely with the BABOK

Guide

requirements classes. Basically, the capabilities are the functional requirements,

and the other two classes are the nonfunctional requirements. Functional

requirements define the capabilities provided to users and other interested

parties, while nonfunctional requirements define conditions of the system or

product as a whole as well as any constraints or limits on all or part of the

system. You can easily extend the three Cs to focus across the different levels of

requirements focus, such as the business, stakeholder, and solution

requirements found in the BABOK

Guide.

The Requirements State Machine

When you look at requirements across the project life cycle, you will notice that

they change as the project progresses. They start as a bunch of information and

are analyzed into meaningful requirements. The analyzed requirements are

reviewed and approved by their key stakeholders. Following review and

approval, the requirements are used as the basis for designing a solution. See

the pattern? Requirements development fits nicely into a state machine

approach as the requirements change over time—they transition from state-to-

state based on actions that have been taken. Many requirements deliverables are

modified based on the state that they are in at a particular point in time. This is

particularly true for the requirements found in the BABOK

Guide.

Exam Spotlight

When preparing for your exam or simply trying to apply the best practices

in the book, be aware of states and how they affect where you are in the

project life cycle relative to your business analysis work, what has been

done, and what should be done next.

You will see these different types and states of requirements used when naming

inputs and outputs to business analysis activities. This will help you recognize

where you are in the project life cycle and where you are in your requirements

development process. You may also see the term Requirements with no

modifiers attached or noted as Requirements [Any State], indicating any class

of requirement in any state. Inputs and outputs from business analysis tasks

may use this notation.

Let’s say you are developing your project’s business requirements. According to

the BABOK

Guide, the solution requirements include the business need, the

required capabilities, the solution scope, and the business case. This is the set of

deliverables produced by Strategy Analysis activities. The solution scope defines

the capabilities that a solution must possess in order to meet a business need. In

addition to modifying your requirements to the specific class of requirements

you are focusing on, business requirements, you can also reflect the state of

these business requirements at a particular point in time.

When you develop business requirements, you will need to elicit information

from key stakeholders about what they and the business actually need. These

stated requirements reflect what the users have told the business analyst about

what they need. As part of your elicitation results, these stated business

requirements will be analyzed, prioritized, validated, and verified prior to

becoming the accepted set of business requirements for the project. Once these

requirements have been reviewed and approved by the stakeholders, they would

be named Requirements [Approved] in the inputs or outputs for a particular

task. At this point, the business analysis team will have reviewed and obtained

approval for the requirements that were received from the users when they

expressed their needs.

The requirements state machine is worth watching; it provides the business

analyst with guidance and recommendations about what has already taken place

and what might be the logical next step in the requirements development

process. Table 1.2 summarizes the possible states and may be of assistance when

you are navigating the BABOK

Guide.

TABLE 1.2 The BABOK® Guide requirements state machine summary

Requirements

State

Description

Approved Agreed to by stakeholders and ready for use in subsequent

business analysis or implementation efforts

Maintained Formatted and suitable for long-term or future use by the

organization; may be saved as organizational process assets

Modelled Well-structured and represented using correct modeling

notations

Prioritized Having an attribute describing its relative importance or

assigned priority to stakeholders and the organization

Specified Well-formed requirements documented using text, matrices,

and models

Traced Having clearly defined and identified relationships to other

requirements or designs within the solution scope

Validated Demonstrated to deliver value to stakeholders; are within the

solution scope and are aligned with business goals/objectives

Verified Requirements have been checked and are of sufficient quality

to allow further work to be performed.

Keep an eye on the classes of requirements and their current states as you

navigate and use all of the knowledge area tasks. They provide valuable road

signs to keep you headed in the right direction.

Exam Spotlight

As part of your studies, be sure that you are comfortable with the

requirements classes from the BABOK

Guide. They represent

the requirements taxonomy used on the exam. If you classify your

requirements another way, try to forget about that as you take your exam! It

will also be helpful to remember which knowledge area creates which type

of requirements.

Understanding How This Applies to Your Projects

As you can tell from this first chapter, successful business analysts bring a

serious mixture of skills, dedication, and knowledge to their projects in order to

solve business problems and meet business needs. It isn’t just the ability to

execute the business analysis techniques that gets the job done, either. Effective

business analysts must also possess excellent interpersonal skills as well as a

strong set of business and technical knowledge.

The Fledging Business Analyst Makes a Mistake

Everyone has to start somewhere. Phil’s first formal solo assignment as a

fledgling business analyst was to aid in the automated tracking of key

performance measurements for one of the operating departments in a large

telecommunications firm. The process was manual, and senior management

felt that it was time to make it computer-based. Phil left his software

engineering role behind, put on his business analysis hat, and went to figure

out exactly what was required.

Phil followed the rules for being a business analyst on this new assignment.

He interviewed the client and captured every word. He parroted back the

key elements of the conversations. He carefully documented the current

processes as described. He obtained sign-off from the client sponsor. Phil

was proud of following the rules and getting this complex manual algorithm

explained in concise and well-understood terms.

When programmed (by someone else), the automated results didn’t come

close to what the manual process reported. Phil proceeded to put his

technical hat back on and spent days pouring through reams of manual

data, comparing that data with the automated results. After consulting with

the client sponsor (along with his reams of data), Phil discovered that he

had missed an unrevealed rule about how the data values were tracked on a

daily and monthly basis. Because he understood the math, the business, and

the technology of the automated system, he was able to ripple this new

requirement and deliver a solution that met the client’s requirements.

It’s OK for Phil to wear multiple hats on his projects, as long as he realizes

which hat he has on at any particular time. People often find it difficult to

leave the technical work behind and think about the business when they are

wearing their business analyst hat. Doing so can lead the fledging business

analyst into trouble, resulting in incorrect or incomplete requirements and

project problems downstream. Phil was lucky that he was able to put his

technology hat back on and address his requirements problem sooner rather

than later.

Business analysts must also be able to map the proven principles, best practices,

and deliverables of the BABOK

Guide across their organization’s project life

cycle. This allows them to create a flexible framework for the essential work

activities of the business analyst. The BABOK

Guide allows business analysts

to build a business analysis methodology providing an integrated framework of

elements for successful business analysis work that business analysts can tailor

to the project environment.

Exam Spotlight

This generic life cycle model is not on the exam. However, if you plan to use

the BABOK

Guide as the basis for your business analysis work activities,

you have to make it work for your organization. Mapping to your existing

life cycle model is the first step in integrating these best practices into your

own projects.

Different business analysis skills, techniques, and knowledge are used at

different places in the project life cycle. To implement the contents of the

BABOK

Guide on your projects, you will need to map what needs to be done to

when you would like to do it. If you have an existing project life cycle in your

organization, this is the time to dust it off and use it. If not, it’s time to build

one. Our generic project life cycle consists of three parts: controlled start,

controlled middle, and controlled end. When you think about your projects, one

way to keep track of what needs to be done is to know “when and where” you are

in this simple model (see Figure 1.4).

FIGURE 1.4 Mapping the BABOK

Guide to a generic life cycle

Don’t confuse the six knowledge areas of the BABOK

Guide with

the phases of the project life cycle. The BABOK

Guide is not a methodology

or a road map for business analysis. Instead, it is a set of best practices that

can be used to build a framework for business analysis activities supporting

the activities and deliverables defined by an organization’s project life cycle.

The organization is responsible for mapping these best practices to their

selected project life cycle.

Controlled Start The controlled start to a project includes the pre-project

activities where you determine whether this is a viable and worthwhile project

for the business. It also covers the project initiation, where business analysts do

more detailed planning for the overall project and for the next detailed project

stage. At the end of the controlled start activities, the business analyst should

have project scope finalized, business justification in place, and the high-level

project plan built. The project team should be ready to get to work. The team

uses numerous tasks and deliverables from the Strategy Analysis and Business

Analysis Planning and Monitoring knowledge areas at this point in time with a

little Requirements Life Cycle Management work thrown in for good measure.

Controlled Middle The controlled middle of a project is where the technical

work gets done, one stage or phase at a time. The project manager uses the plan

to measure and monitor project performance and to control what takes place.

This is management by walking around (MBWA), where business analysts are

into everything—regular status, informal conversations, checking the health of

the project, dealing with stakeholders, forecasting future performance, and

dealing with issues and risks. The business analysis work is a subset of this plan,

and the business analyst manages and controls business analysis work

performance during this time. Business analysis tasks typically include those

from the Elicitation and Collaboration, Requirements Life Cycle Management,

Requirements Analysis and Design Definition, and Solution Evaluation

knowledge areas.

Controlled End A controlled end to a project is when the business analyst

wraps up a job well done. This can also take place if the project was prematurely

terminated for one reason or another (ideally a rare event). The business analyst

takes stock of achievements, reports on the effort, ensures objectives and

acceptance criteria are met, and transitions the final product of the project into

its operational life. There are specific tasks in Solution Evaluation that focus on

this part of the project life cycle.

Perspectives on Business Analysis

Business analysts find themselves working on many types of projects. You may

find yourself developing requirements for a back-office IT system or defining

standard operating procedures within a research laboratory. The BABOK

Guide defines five common points of view for business analysis work.

Agile

Business intelligence

Information technology

Business architecture

Business process management

Each perspective impacts how business analysts use the knowledge area tasks in

their efforts. Remember, different types of initiatives facilitate different types of

changes to the business. Make sure you have the right people, the right

methods, and the right approach to define what has to be done.

Chapter 9, “Five Perspectives on Business Analysis,” contains a

detailed explanation of each perspective and how you might change your

business analysis activities as a result of that point of view.

Summary

You covered a lot of content in this chapter! You learned that business analysis

is an essential part of every organization. Successful business analysts bring a

serious set of skills and knowledge to every project or initiative in order to liaise

among the stakeholders to address business needs and solve business problems.

Business analysis is more than just asking questions!

You looked at how the BABOK

Guide provides a business analysis framework,

defining areas of knowledge, associated activities and tasks, and the skills

required to perform them. The scope of the BABOK

Guide covers pre-project

activities, the full project life cycle, and the final solution’s operational life. It is

also the basis for the CBAP® and CCBA™ certification exams, and it provides

the backbone of this book.

The BABOK

Guide contains its own requirements classification scheme. This

is the scheme you will see on the certification exams. A requirement is a

condition or capability needed by a stakeholder to solve a problem or to achieve

an objective. Classifying requirements allows the business analysis team to

make sure that their project requirements are reviewed and understood by the

correct stakeholders. Requirements classes help you determine the appropriate

level of detail and the specificity needed in the project requirements and decide

how many documents you will use to define what is needed.

You visited the six business analysis knowledge areas as a part of the chapter.

These knowledge areas guide business analysts when they perform business

analysis activities at any point in the project or product life cycle. The areas

define what business analysts need to understand and the tasks they should

perform. They do not represent project phases, and their activities are not

intended to be performed in a linear fashion.

To use the BABOK

Guide at work, you will need to map its business analysis

tasks to your own project life cycle (PLC) or systems development life cycle

(SDLC). This will allow you to create a business analysis methodology that

supports your project and product-focused life cycles and will help you to keep

the lights on. This book uses a simple project life cycle as the basis for a map. It

has only three phases: controlled start, controlled middle, and controlled end.

Most life cycles are far more complex!

Because many of you are planning to use this book in your preparations to take

the CBAP® or CCBA™ certification exam, this book covers the content and

structure of the exams. It takes a lot of work to successfully prepare for and pass

these exams—they are not intended to be easy! The CBAP® exam is designed

for experienced business analysts, while the newer CCBA™ exam targets folks

who have less experience working as business analysts. The questions in each

exam are built using Bloom’s taxonomy (a method for classifying learning

objectives), and questions can be quite straightforward (testing comprehension)

or rather difficult (testing analysis).

Exam Essentials

Be able to explain the pieces and parts of the BACCM™. The BACCM™

contains six concepts that define the profession of business analysis in a

common language. Effective business analysts need to keep all six related

aspects of this model when developing requirements for their project or

initiative.

Be able to list and describe each knowledge area. The names and high-

level descriptions of each of the six knowledge areas are required knowledge for

you as you prepare to take your exam. As you dig deeper into each knowledge

area, learn to also list the tasks and their key inputs/outputs/techniques as part

of your exam preparation repertoire. The six knowledge areas are Business

Analysis Planning and Monitoring, Elicitation and Collaboration, Requirements

Life Cycle Management, Strategy Analysis, Requirements Analysis and Design

Definition, and Solution Evaluation.

Be able to navigate your copy of the BABOK

Guide. Tabbing your copy

of the BABOK

Guide helps you find exactly what you need to know. You might

find it helpful to use multiple colors of durable tabs to mark the chapters in your

book, the glossary, the index, and any other information that you think will be

useful.

Be able to describe and relate the requirements classes in the

BABOK

Guide. Starting at the highest level of detail, they are business

requirements, stakeholder requirements, solution requirements, functional and

nonfunctional subsets of the solution requirements, and transition

requirements.

Be able to recognize the underlying competencies every good

business analyst should possess. The six high-level categories are

analytical thinking and problem solving skills, behavioral characteristics such as

trustworthiness, business knowledge, software knowledge, interaction skills,

and communication skills.

Be familiar with the key stakeholder roles. The exact role names and

definitions from the BABOK

Guide are what you will see in your exam

questions, so make sure you know each of them. Remember that the stakeholder

roles are like hats, and one person can wear one or many hats during a project

life cycle.

Key Terms

This chapter introduced the knowledge areas from the BABOK

Guide that you

will be using as a business analyst on your projects and other initiatives. You

will need to understand how to apply each of these knowledge areas at the right

spot in the project life cycle in order to be an effective business analyst.

Additionally, you will need to know each knowledge area by name and definition

in order to be successful on the CBAP

or CCBA™ exams. Each knowledge area

will be discussed in greater detail in the chapters to come.

Business Analysis Planning and Monitoring

Elicitation and Collaboration

Requirements Life Cycle Management

Strategy Analysis

Requirements Analysis and Design Definition

Solution Evaluation

You have learned many new key words in this chapter. The International

Institute of Business Analysis (IIBA) has worked hard to develop and define

standard business analysis terms that can be used across many industries. Here

is a list of some of the key terms that you encountered in this chapter:

business analysis

business analyst

business requirements

conditions

constraints

design

domain

elements

functional requirements

guidelines

inputs

nonfunctional requirements

project manager

purpose

requirement

solution requirements

solutions

stakeholder

stakeholder requirements

stakeholders

techniques

tools

transition requirements

underlying competencies

Review Questions

You can find the answers in Appendix F.

1. A business analyst is currently defining a set of changes to the current state

of an organization that allows the organization to take advantage of a

business opportunity. What is most likely being defined?

A. Project scope

B. Business need

C. Solution scope

D. Business domain

2. In what knowledge area is the business analyst most likely to be scoping and

defining new business opportunities?

A. Strategy Analysis

B. Solution Evaluation

C. Requirements Analysis

D. Enterprise Assessment

3. What project role focuses on understanding business problems and

opportunities?

A. Business architect

B. Project manager

C. Project sponsor

D. Business analyst

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

A. Strategy

B. Requirement

C. Solution

D. Process

5. Your project implementation plan defines 12 capabilities of the planned

systems solution that will not be needed once the new solution is

operational. What type of requirements are these?

A. Functional requirements

B. Nonfunctional requirements

C. Reusable requirements

D. Transition requirements

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

A. Program manager

B. Project manager

C. Business analyst

D. Project sponsor

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

A. Requirements

B. Preconditions

C. Techniques

D. A single task

8. To determine solutions to business problems, the business analyst applies a

set of:

A. Activities and tasks

B. Inputs and outputs

C. Tasks and techniques

D. Practices and processes

9. Knowledge areas define what a business analyst needs to understand. They

do not define the project:

A. Scope

B. Techniques

C. Phases

D. Resources

10. All of the following are part of the business requirements, except:

A. Solution scope

B. Business need

C. Required capabilities

D. Business goals

11. What knowledge area contains the next most logical steps after the business

analyst has built a business case and gained management approval for a

project?

A. Solution Evaluation

B. Business Analysis Planning and Monitoring

C. Requirements Life Cycle Management

D. Requirements Analysis and Design Definition

12. All of the following are knowledge areas except:

A. Solution Evaluation

B. Requirements Planning and Monitoring

C. Requirements Life Cycle Management

D. Strategy Analysis

13. The stakeholders have indicated to the business analysis team that the

documented requirements are ready for use in subsequent business analysis

or implementation efforts. What type of requirements has been developed at

this point in time?

A. Maintained

B. Verified

C. Validated

D. Approved

14. Identifying key stakeholder roles and selecting requirements activities is

done as part of which knowledge area?

A. Requirements Analysis

B. Requirements Development

C. Business Analysis Planning and Monitoring

D. Requirements Elicitation

15. Requirements gathering activities are also known as requirements:

A. Planning

B. Development

C. Analysis

D. Elicitation

16. What represents the information and preconditions necessary for a business

analysis task to begin?

A. Activity

B. Input

C. Output

D. Technique

17. You are a business analyst measuring alternatives against objectives and

identifying trade-offs to determine which possible solution is best. You are

most likely engaged in what activity?

A. Problem solving

B. Systems thinking

C. Creative thinking

D. Decision making

18. What defines the business analysis team roles, deliverables to be produced,

and tasks to be performed?

A. Requirements process

B. Project management plan

C. Solution approach

D. Business analysis approach

19. When does the business analyst ensure the feasibility of the proposed

requirements to support the business and user needs?

A. As part of building a business case

B. During Requirements Analysis and Design Definition

C. When organizing business requirements

D. While planning and monitoring tasks

20. The system users have stated their needs for revised online order entry

system capabilities. The users need the ability to perform online, remote

order entry when they are traveling worldwide. What type of requirements

best describe this need?

A. Stakeholder requirements

B. Business requirements

C. Transition requirements

D. Solution requirements

Chapter 2

Controlled Start: Business Analysis Planning and

Monitoring

CBAP

/CCBA™ EXAM TOPICS COVERED IN THIS CHAPTER:

Plan business analysis approach.

Plan stakeholder engagement.

Plan business analysis governance.

Plan business analysis information management process.

Identify business analysis performance improvements.

Now that you are more familiar with the discipline of

business analysis, you are ready to address planning the business analysis

activities for a project or initiative. You have learned the basic pieces of the

discipline: the underlying competencies of the business analyst, the key business

analysis stakeholders, the framework of the BACCM™, and the BABOK

Guide

requirements classification scheme. Using this foundation, you will begin to

apply business analysis tasks and techniques as we walk through the first

knowledge area, Business Analysis Planning and Monitoring.

The first skills you will put to use are analytical thinking and problem solving.

After all, before you can begin a project or project phase, it’s a good idea to know

what work you need to do. To achieve a controlled start to a project or project

phase, you must be methodical and consistent in your planning, definition, and

decisions. This is the first step in planning the business analysis work effort for a

project. Figure out what needs to be done, how you will go about doing it,

exactly who needs to be involved with the work, and how involved they should

be.

Business Analysis Planning and Monitoring

The Business Analysis Planning and Monitoring knowledge area focuses on

laying the groundwork for successfully defining, planning, and completing the

business analysis work for a project. The business analyst builds the business

analysis work plan by executing the knowledge area tasks. The business analysis

tasks that the business analyst puts in the work plan depend on what needs to

be done for the time period of the planning effort. Typically, the business

analysis work activities become part of the project management plan.

To focus on what is important to the business analyst early in the business

analysis efforts, let’s consider the tasks of this knowledge area with the

framework of the BACCM™. The business analyst needs to keep an eye on their

work at this point in time relative to the six concepts contained in the

framework: changes, needs, solutions, stakeholders, values, and contexts. Table

2.1 lists these responsibilities.

TABLE 2.1 The BACCM™: Business Analysis Planning and Monitoring

Core

Concept

The Business Analyst’s Responsibilities

Change Determine how changes to business analysis results are

requested and authorized.

Needs Choose a business analysis approach providing adequate analysis

for the change.

Solution Evaluate if business analysis performance contributed to

successful solution implementation.

Stakeholders Perform stakeholder analysis to ensure Business Analysis

Planning and Monitoring activities reflect stakeholder needs and

characteristics.

Value Conduct performance analysis to ensure business analysis

activities produce sufficient value to stakeholders.

Context Ensure complete understanding of the context being analyzed in

order to develop an efficient business analysis approach.

The tasks in this planning-focused knowledge area generate several key business

analysis deliverables:

Business analysis approach

Stakeholder engagement approach

Governance approach

Information management approach

Business analysis performance assessment

We will cover each deliverable in more detail in this chapter.

The Business Analysis Planning and Monitoring knowledge area also addresses

monitoring and reporting on the business analysis work being performed on a

project once the planning is complete and the work efforts are underway. This

ensures the project’s business analysis effort produces the desired outcome and

that the business analysis work is done right.

The Business Analyst’s Task List

The business analyst has five tasks to perform in the Business Analysis Planning

and Monitoring knowledge area. We will look at each of these tasks in greater

detail later in this chapter. The task list from the BABOK

Guide includes the

following:

Defining the business analysis approach

Planning for stakeholder engagement

Setting up business analysis governance

Outlining the business analysis information management process

Identifying business analysis performance improvements

These tasks focus on planning how the business analysis team will approach a

specific effort. The business analyst is responsible for developing, defining, and

managing the roles and tasks associated with this work. We will step through

each of these tasks in greater detail later in this chapter. The goal of the project

is to define, develop, and deliver a solution that addresses a business problem,

need, or opportunity. To achieve that goal, the business analyst must have

detailed knowledge of each task, be able to apply the recommended techniques,

and produce high-quality deliverables as a result.

Exam Spotlight

Exam questions in this knowledge area are organized and presented using

this list of tasks. Expect to see approximately 21 questions about this

knowledge area on your CBAP

exam and 18 questions if you are sitting the

CCBA™ exam. It is your job (and ours as well) to make sure you know when

this work is done and how you go about actually doing it.

When Does Business Analysis Planning and Monitoring Take Place?

“Begin at the beginning,” the King said gravely, “and go on till you come

to the end; then stop.”

—Lewis Carroll, Alice in

Wonderland

The tasks in the Business Analysis Planning and Monitoring knowledge area

occur throughout the project life cycle. Many of these tasks are done as a part of

pre-project activities as the basis of a project’s controlled start. The business

analysis deliverables created at the beginning of a project are used to define,

govern, and monitor the performance of all other business analysis tasks across

the project life cycle. The plans and approaches developed for the overall project

may require updates and additional details as each subsequent phase of the

project life cycle is planned.

The controlled start to a project includes the pre-project activities where teams

determine whether this is a viable and worthwhile project for the business.

Controlled start also covers project initiation activities, where you do more

detailed planning for the business analysis effort on a project and any associated

project stages or phases. At the end of a controlled start:

The solution scope is finalized.

The business case and justification are in place.

The high-level business analysis approach has been built.

Business analysis governance is defined and in place.

Business analysis information management is ready to go.

Business analysis stakeholders are identified and engaged.

Business analysis performance measures are agreed on.

The business analysis team should be ready to get to work.

Numerous tasks and deliverables from both the Strategy Analysis and Business

Analysis Planning and Monitoring knowledge areas are created and used during

a controlled start. Tasks in the Business Analysis Planning and Monitoring

knowledge area allow you to decide how to go about the business analysis work

that is required to define, develop, and deliver a solution. Tasks from the

Strategy Analysis knowledge area focus on defining the business requirements

and justifying delivery of the solution scope for the project. We will take a

detailed look at the Strategy Analysis tasks in Chapter 3, “Controlled Start:

Strategy Analysis.” Right now, we are concerned with planning how to do the

business analysis activities versus actually doing the work.

What Exactly Am I Supposed to Be Doing?

Russ discovered early in his career as a project manager that all plans are

not created equal. He was a replacement for the project manager on a fairly

complex data center consolidation project. Russ stepped in near the end of

the first major phase of project work, which was developing the user

requirements for the new data center.

One of his first tasks was to review the current project plan and evaluate the

progress to date. Russ noticed that the requirements development work was

shown as a single two-week task in the project plan with no additional

details about the requirements process itself. Because the resulting user

requirements document was shown as a completed deliverable and this task

was marked as 100 percent complete, he decided to look at the new

capabilities the project would provide to the business and its users. So he

did.

After reading the first four pages of the document, Russ knew there was a

problem. He finished reading the user requirements document, closed the

file on his computer, and reached for the phone to call the lead business

analyst for this effort into his office. When Mary arrived, he asked her,

“What exactly is this document supposed to be? Is this just a high-level

concept that we need to now go out and define?” Mary replied that the

document was the final, approved user requirements document. All the

business analysis team had to do now was give the document to the

developers. The developers would figure out the rest.

Russ asked Mary to explain the process she and her team had gone through

to produce the deliverable. She explained that she had worked in tandem

with the development director to elicit, analyze, and specify the user

requirements for the project. Basically, the key users had not been involved

or consulted at all. As Mary was quick to point out, “That wasn’t in the plan,

so that wasn’t how I did the work.” Basically, the user requirements work

had to begin all over again and had to be done correctly the second time.

Russ worked closely with his business analysis team to plan the

requirements development work in far greater detail. This time around, the

team gave themselves adequate time to elicit and analyze the requirements

and planned the time to validate the requirements when everything was

complete. Completing the rewritten user requirements took five additional

weeks of work. Funnily enough, this didn’t impact the scheduled end date.

The original requirements would have been impossible to use for the design

and construction of the data center.

Remember that your focus is on planning and monitoring the business

analysis work for a project, not on planning and managing the whole

project. That is the responsibility of the project manager. However, in either

case, the plans need to be built and implemented at the appropriate level of

detail.

Plan the Business Analysis Approach

The first task in the Business Analysis Planning and Monitoring knowledge area

is to define and plan the business analysis approach. There are many ways to

approach business analysis work on a project. To get the business analysis work

started on a project, you must first decide how to go about doing it. The overall

business analysis process for performing work consists of the following:

Deciding how and when business analysis tasks will be performed

Agreeing on the techniques to be used

Defining the deliverables to be produced

Figure 2.1 summarizes the inputs, outputs, techniques, and associated tasks for

planning the business analysis approach for a project. The best business

analysis approaches are based on the organizational environment where they

will be used. The business analysis approach is a subset of the overall project

approach. It defines the set of processes, templates, guidelines, tools,

techniques, and activities used to perform business analysis on a project or

initiative. When documented, the business analysis approach creates a

formalized and repeatable methodology. In comparison, the project approach

describes the way all of the project work will be approached.

Once the business analysis approach is established for a project or initiative, it is

not expected to change significantly through that project’s life cycle. However,

the business analysis approach should be revisited at each phase of the project

to ensure that it is being followed and that no changes are required for the work

that will be started or based on business analysis performance to date.

FIGURE 2.1 Task summary: Plan business analysis approach.

Predictive vs. Adaptive Approaches

When you define and plan your business analysis approach, you must decide

where it falls across the spectrum of predictive approaches and adaptive

approaches. Predictive planning approaches focus on ensuring that the solution

is fully defined before its implementation begins. Adaptive planning approaches

are used on projects where many small iterations are defined and developed en

route to the final result. Hybrid approaches combine aspects of both types and

may require additional tailoring and scaling of the business analysis approach to

combine them well. Most organizational environments and their management

teams are likely to be more comfortable with one approach over the other.

The Project Has Two Faces, Part 1

Introduced into the exciting realm of online payment processing on a

consulting assignment, Ginger discovered that projects can successfully

incorporate both predictive and adaptive approaches to get the job done.

She was brought on board by a financial services firm to lead their efforts in

launching their new online payment processing system. Of course, before it

could be launched, it had to be defined, designed, and built from the ground

up.

Early phases of this effort focused on building the actual system. Ginger

recommended that the project team use a predictive approach. This would

ensure a system that would be scalable as more customers came on board.

The architecture and infrastructure capabilities for the new system would be

thoroughly documented and well understood. The system’s payment

processing capabilities would be well defined, and all key stakeholders in

the organization would know what the final system looked like and what

services the product would provide. Senior management agreed with this

approach, and the work began.

Once system development was well underway, it was time to look for new

customers for this soon-to-be operational product. Ginger was asked to lead

the implementation team responsible for onboarding new customers. This

was the point where the game changed. Previously, her focus was on a well-

designed and well-defined online payment processing system. Now, her

focus was on marketing the product to and acquiring new customers as

quickly as possible. The goal was to complete each customer

implementation in less than 30 days.

To achieve this goal, Ginger recommended a very different approach from

the development team’s predictive project. She and the team decided that an

adaptive approach was the only way to get each implementation done

swiftly and accurately. The team developed requirements templates to use

as the basis for setting up each customer’s portal into the payment

processing system. The information in these templates was gathered by

telephone. Of course, billing information for each customer was also

collected. Customers had their own data repositories and a customized front

end for their shopping carts.

Use of the streamlined requirements templates enabled each

implementation manager to quickly walk their clients through the process of

getting the online payment processing system up and running on their

websites. Management was ecstatic when the money started flowing in from

happy customers. And Ginger the consultant was invited to the celebration

when everything was complete.

Predictive business analysis tries to minimize your up-front uncertainty (or risk)

and maximize your control over the business analysis activities on your project.

This is a more traditional style of development, such as the waterfall model of

software development or what you find in straightforward business process

reengineering initiatives. The biggest issue with predictive approaches is

whether or not the solution requirements can actually be well defined prior to

commencing the overall solution delivery efforts. In effect, predictive

approaches use structure to control project risk.

Another way to think of predictive versus adaptive business

analysis approaches is to call them traditional versus agile development

methodologies.

Adaptive business analysis approaches target rapid delivery of business value.

To achieve that goal, they accept greater uncertainty (risk) relative to the overall

solution delivery. This is an exploratory approach to finding the best solution,

using short iterations to incrementally develop components of the solution.

Adaptive approaches that you may be familiar with include agile development

methods and many continuous process improvement projects being done in

organizations. One key feature of adaptive approaches is that they use flexibility

to control project risk.

Do not confuse today’s predictive business analysis approaches

with the traditional, linear models of the past. Today’s predictive

approaches are flexible and adaptable, using time-boxing, iterative

development, and multiple releases to help folks get the job done. The

traditional linear models of the past typically use the draft-walkthrough-

revise-final-approve cycle.

Create a Business Analysis Approach

Now let’s get to the task at hand, which is planning the business analysis

approach. Every task has inputs, outputs, elements, guidelines, tools, and

techniques. This task is no exception. Let’s start with the inputs. Inputs are

either informational in nature or outputs produced by other business analysis

tasks. Inputs are acted on by the task elements and techniques, producing one

or more task outputs. Let’s take a look at the task input used when planning a

business analysis approach:

Needs The business analysis approach is impacted by the business need or

need for change that is driving the project. This makes sense. Both the project

approach and the business analysis approach will be impacted by the problem

or opportunity it is addressing. The needs for the project are defined during

Strategy Analysis.

There are additional inputs that may be used by the business analyst when

performing business analysis tasks: guidelines and tools. Guidelines are

instructions or descriptions about why or how the business analyst might

undertake a particular task. Tools are methods of conducting business analysis

tasks or shaping a task output. Let’s take a look at the guidelines and tools that

are applied when planning a business analysis approach:

Business Analysis Performance Assessment The business analysis

performance assessment contains results from business analysis activities on

previous projects for you to review and incorporate into your current approach

to getting things done.

Business Policies Business policies define the limits within which business

decisions must be made and how work will be completed. These policies also

frame and constrain the business analysis approach that you select.

Expert Judgment Expert judgment is used to evaluate and build the optimal

business analysis approach for your project. Your team will rely on individuals

or groups with specialized knowledge or skills in business analysis and other

aspects of the domain to assist in defining the approach.

Methodologies and Frameworks Methodologies and frameworks define

and govern business analysis work on a project. The business analysis approach

may be defined by a particular methodology, an organizational framework, or a

combination of the two. Don’t forget to look at historical information from

previous projects, such as risks, performance measures, schedules, and other

data. When you discover a business analysis asset treasure trove at one of your

clients, it means you don’t have to reinvent the wheel.

Stakeholder Engagement Approach Effective business analysts make sure

that they understand their stakeholders. Stakeholder concerns and interests can

impact the pieces and parts of your business analysis approach.

Table 2.2 summarizes the inputs, guidelines, and tools needed to plan the

business analysis approach for a project and also lists the task and knowledge

area that was the source of the input (if applicable).

TABLE 2.2 Inputs, Guidelines, and Tools: Plan business analysis approach.

Task Input Input

Type

Input Source Source

Knowledge Area

Needs Input Define business needs. Strategy Analysis

Business analysis

performance

assessment

Guidelines

and tools

Identify business

analysis performance

improvements.

Business Analysis

Planning and

Monitoring

Business policies Guidelines

and tools

Expert judgment Guidelines

and tools

Methodologies and

frameworks

Guidelines

and tools

Stakeholder

engagement

approach

Guidelines

and tools

Plan stakeholder

engagement.

Business Analysis

Planning and

Monitoring

The experienced business analyst spreads their attention across six elements

when they consider the contents of the business analysis approach. The results

of each element are formally documented as part of the business analysis

approach for the project. The detailed elements necessary to plan the business

analysis approach include the following:

Planning the overall business analysis approach

Deciding degree of formality and level of detail for business analysis

deliverables

Integrating the execution of business analysis activities with the overall

project plan

Determining timing of business analysis work

Considering complexity and risk

Gaining acceptance of the business analysis approach from key stakeholders

Exam Spotlight

Remember that selecting and defining your project’s business analysis

approach is situational. It depends on a number of factors, such as

organizational needs, business analysis team skills, and solution complexity.

Combining practices from predictive and adaptive approaches could result

in a stronger business analysis approach.

Let’s step through each of the elements involved in deciding on and building a

project’s business analysis approach:

Select Planning Approach Your planning approach for business analysis

activities should fit the size and type of project you are working on. It should

also fit within the organization where you work. We have already discussed the

spectrum of planning approaches available to the business analyst, ranging from

predictive to adaptive. Successful business analysts tailor their planning

approach to ensure that value is delivered to the enterprise.

Decide Formality and Level of Detail All expected business analysis

deliverables across the project life cycle should be defined in the business

analysis approach. If you forget a particular deliverable that is due later in the

life cycle or change your mind about one that has already been defined, you can

always revisit the business analysis approach and make the necessary changes.

Predictive approaches are usually quite formal and produce very detailed

document sets requiring formal approval. Adaptive approaches can be quite

informal, often limiting the documentation to a bare minimum. Project work

and business analysis deliverables are approved informally through team

interaction and feedback.

Exam Spotlight

Remember that adaptive business analysis approaches must have well-

prioritized requirements because a prioritized requirements list may well be

the only required project documentation.

Plan and Integrate Business Analysis Activities The business analyst

must decide on the process to follow for planning a project’s business analysis

activities. This requires coordination and communication with the project

manager, because this business analysis work plan is typically integrated into

the higher-level project plan. If there are planning standards to follow for the

project, the business analyst should use those standards when planning the

business analysis work. These standards could include guidelines for estimating

or specific planning and scheduling tools to be used. If the business analysis

work plan is not consistent with the project plan, it will be difficult to integrate

into the overall effort.

Determine Timing of Business Analysis Work It is critical that you

determine when the business analysis work will take place throughout the

project. This includes identifying not only the tasks to be performed but also the

business analysis resources that will perform each task. Requirements

development time is a traditionally heavy period of work for the business

analysis team. You need to know whether these efforts will align with specific

project phases early in the project (predictive) or whether the work will be done

iteratively throughout the project (adaptive).

The effectiveness of a business analyst depends on the corporate

culture. Working in a large organization seems to require more formal

written communications. We have worked in large organizations with so

many layers of management that the business analysts almost never speak

directly to a decision maker. On the flip side, many business analysts

working in smaller organizations find that formal written communications

almost never occur. In this situation, stakeholder communications are

almost always verbal and informal in nature.

Consider Project Complexity and Risk Project complexity impacts the

business analyst in a number of ways. In general, the more complex the project

is, the more complex the business analysis effort is as part of the project work.

Complex projects may result in a greater number of formal deliverables and

stakeholder review points. Complex projects can also be riskier for everyone—

the business, the project team, as well as the business analysis team and its

business analysts. Situations with a complex solution should be addressed with

more up-front modelling and planning work. Examples of complex projects

include building an airline reservation system or creating a telecommunications

circuit ordering and provisioning application.

Exam Spotlight

Be sure you remember the five factors that increase the complexity of

business analysis work. The rule of thumb is that as these factors increase,

so does the project complexity.

The size of the change

The number of business areas or systems affected

The amount and nature of risk

The technological complexity

The number of geographic and cultural considerations

Gain Stakeholder Acceptance of the Approach Key stakeholders must

review and agree to the approach the business analyst creates. In general, the

more your key stakeholders are involved with creating and thinking through the

business analysis approach, the easier acceptance will be. Some projects require

a formal sign-off on the approach from key stakeholders. Other projects may

consider the approach accepted with an email saying that a key stakeholder

agrees that all business analysis activities are identified, the estimates are

realistic, and the proposed roles and responsibilities are correct. Be sure to plan

for handling stakeholder acceptance of changes to the business analysis

approach over time as work progresses and conditions change.

There are a number of techniques that you might choose to apply when building

a business analysis approach for your project. We recommend that you use the

estimation technique in order to consider the estimate and compare the range of

costs associated with one or more business analysis approaches before making

your final decision. Let’s take a look at that technique in greater detail.

Recommended Technique: Estimation

There are many ways for the business analysis team to estimate the range of cost

and effort associated with the business analysis work on a project. These

estimates are typically developed in conjunction with the project manager and

other team members using the project-level estimating tools and techniques.

Effective business analysts use estimates to promote better stakeholder decision

making and understanding of the project. Table 2.3 summarizes of the types of

estimates commonly used for estimating business analysis efforts.

TABLE 2.3 Common estimating techniques

Technique Description

Analogous

estimation

Uses similar projects as the basis for top-down estimates

Parametric

estimation

Uses parameters and historical data

Bottom-up

estimation

Estimates smaller items first and aggregates upward

Rolling wave Refines detailed estimates for increments of work over

time

Three-point

estimation (PERT)

Estimates optimistic, pessimistic, and most likely cases

Historic analysis Uses history as the basis for bottom-up and top-down

estimates

Expert judgment Relies on those who performed similar work in the past

Delphi estimation Combines expert judgment and history

Rough order of

magnitude (ROM)

Makes a high-level estimate based on limited

information with a wide confidence interval

Additional Techniques to Consider

The BABOK

Guide lists some additional techniques that can be used when

building the business analysis approach for a project. They are summarized for

you here.

Brainstorming Brainstorming is an excellent way for the business analysis

team to generate a list of all possible business analysis activities, techniques, or

risks for the business analysis approach.

Business Cases Experienced business analysts look to the project’s business

case for time-sensitive, high-value aspects of the problem or opportunity that is

being addressed.

Document Analysis This technique is used to review existing organizational

assets that might assist in planning the business analysis approach.

Financial Analysis Financial analysis allows you to assess how different

approaches and delivery options affect the value being delivered to the

enterprise.

Functional Decomposition Functional decomposition is pretty much what it

sounds like it would be, breaking down complex business analysis activities into

smaller and easily understood pieces. It is a critical part of business analysis

planning; understanding the business analysis tasks and deliverables

sufficiently enables effective estimating.

Interviews When interviewing key stakeholders, the business analyst should

always ask the interviewees to identify additional information that might fit as

part of the business analysis approach.

Item Tracking This technique is used to track issues or risk-related items

encountered while planning the business analysis approach. Items may be

opened for the project that relate to business analysis activities. These items

should be addressed and resolved by the business analysis team.

Lessons Learned Effective business analysts compile and document

successes, failures, and recommendations for improving the performance of

business analysis activities on their projects. Be sure to use your previous

experiences (both good and bad) when building your business analysis

approach.

Process Modelling Process models document the steps of the business

analysis approach or process for a project. Think of graphically depicting a

series of business analysis process steps on a whiteboard with arrows between

them to show the sequence of events. That is a simple process map that can be

used to build and decide on a business analysis approach.

Reviews Experienced business analysts use reviews to validate the business

analysis approach with key stakeholders and team members. This is a meeting

with a tour guide. Your destination is the business analysis approach, and your

meeting agenda will walk you through the possibilities in order for the group to

decide on the approach that is right for their project.

Risk Analysis and Management Remember that the results of planning the

business analysis approach may contribute to the risks for the business analysis

effort and to the project. The people involved with your efforts can be the source

of possible risks, and they can also help the team identify additional risks that

may be important downstream.

Scope Modelling Scope models help you determine the boundaries of the

solution and its scope as an input to the planning and estimating activities.

Survey or Questionnaire Business analysts may use this technique to

identify possible business analysis activities, techniques, and risks to help build

the contents of the business analysis approach.

Workshops Conducting workshops allows you to build the business analysis

approach in a team setting. The business analyst should always ask the

participants about any additional activities, techniques, or risks that should be

considered for inclusion in the approach.

Once you have chosen one or more techniques to apply, you are ready to create

your business analysis approach. We’ll discuss that next.

Create the Business Analysis Approach

The business analysis approach specifies how the business analysis team plans

to perform the business analysis work on their project. Essentially, this

approach is the business analysis methodology for the project. If the approach is

documented and saved as a business analysis process asset, it can be revised and

reused on subsequent projects in the organization. Once the business analysis

approach is complete, it is used as an input by other business analysis tasks that

are summarized in Table 2.4. They include planning for business analysis

information management and preparing to engage your stakeholders. Both

tasks are also part of the Business Analysis Planning and Monitoring knowledge

area.

TABLE 2.4 Output: Plan business analysis approach.

Task Output Output Destinations Source Knowledge Area

Business

analysis

approach

Plan stakeholder engagement. Business Analysis Planning

and Monitoring

Plan business analysis

governance.

Business Analysis Planning

and Monitoring

Plan business analysis

information management.

Business Analysis Planning

and Monitoring

Identify business analysis

process improvements.

Business Analysis Planning

and Monitoring

Prepare for elicitation. Elicitation and

Collaboration

Conduct elicitation. Elicitation and

Collaboration

Communicate business analysis

information.

Elicitation and

Collaboration

Manage stakeholder

collaboration.

Elicitation and

Collaboration

Analyze current state. Strategy Analysis

Define change strategy. Strategy Analysis

Assess risks. Strategy Analysis

The recommended contents of the business analysis approach include the

following:

Business analysis roles and responsibilities

Business analysis activities

Business analysis deliverables

Business analysis techniques

Timing and sequencing of business analysis work

A number of stakeholders are involved with planning the business analysis

approach for a project. Some stakeholders should participate in building all or

part of the approach; others are affected only by the approach. As previously

mentioned, the project manager must make sure that the business analysis

approach aligns with the project approach. In a similar vein, testers must ensure

that the approach facilitates appropriate testing of the resulting solution.

Stakeholder availability and involvement across the project life cycle may

impact the contents of the business analysis approach. Key stakeholders

involved with this deliverable include the following:

Domain subject-matter expert (SME)

Project manager

Regulator

Sponsor

It is also important that the business analysis approach be compatible with the

development or implementation life cycle being used by the implementation

team. Once the business analysis approach is complete, the team needs to think

about who will be involved with the business analysis work on the project and

determine the level of their involvement. You figure that out during stakeholder

identification and analysis, which we will talk about next.

Plan Stakeholder Engagement

Think of the business analysis stakeholders on a project as members of a

professional sports team. Each stakeholder has a particular position to play as a

member of the team. Some of your stakeholders are starters and play for the

whole game; others substitute in and out during the game and play

intermittently. There are stakeholders on the team who don’t play the game but

might coach the team, bring water out onto the field, or cheer for the team from

the stands. Just like players on a sports team, some of your stakeholders will

play better than others. The business analysis team needs to know these

stakeholders and the role or roles they play in the project.

Effective business analysts recognize the importance of knowing,

understanding, and involving your project stakeholders. Stakeholder analysis

should begin early in the project life cycle when the business requirements are

being developed. The resulting stakeholder information is then revisited and

revised throughout the project life cycle. Without up-to-date stakeholder

analysis information, it is not easy to elicit, validate, or approve project

requirements with the appropriate individuals or groups.

The business analyst initially performs stakeholder analysis during the

controlled start phase of a project or as part of the pre-project activities.

Analysis activities at this point in time focus on key stakeholders who are

impacted by the business need and the proposed solution. The initial

stakeholder list, roles, and responsibilities are enhanced and revised with each

subsequent project phase as the business, stakeholder, solution, and transition

requirements are developed for the project. Figure 2.2 summarizes the inputs,

outputs, techniques, and associated tasks for conducting stakeholder analysis in

accordance with the BABOK

Guide.

FIGURE 2.2 Task summary: Plan stakeholder engagement.

Losing the Sponsor’s Support

The initial stakeholder analysis helps the business analyst evaluate the

attitudes of the stakeholders regarding the project at hand. Savvy business

analysts also perform analysis periodically throughout the project to track

changes in stakeholder attitudes. This is particularly true when

institutionalized processes are the target of change. If you are not aware of

changing attitudes among your key stakeholders, there could be trouble

ahead for your effort.

This happened to Phil on a project that had been divided into three phases.

The first two phases were relatively inexpensive commitments that were

easily implemented. However, the third implementation phase involved

much higher vendor involvement at a much higher cost.

When the time came to begin the third phase of this effort and the vendor’s

work estimates, which added up to several hundred thousands of dollars,

were presented to the project sponsor, the sponsor’s support for the effort

vanished. The sponsor’s recollections of support for the previous two project

phases also disappeared. Adding insult to injury, the sponsor made a point

of disparaging the entire effort in the next executive staff meeting.

What was going on? Was there anything Phil could have done to prevent

this? Phil was fortunate that he had the signed project approval documents

to protect himself and his team from imminent doom. This is a worst-case

example. Effective business analysts have learned to keep a finger on the

pulse of their key stakeholders, especially in long-term projects. This often

provides early warning signals of potential problems.

Remember that stakeholder roles are like hats. Some individuals

may be called on to play a variety of stakeholder roles on the same project,

as well as different roles in different projects. A stakeholder may wear many

hats and play multiple team roles in your project. A job position title is

typically defined and assigned by the organization and does not necessarily

correspond to the team role an individual may play in a project. Team

roles are defined project-specific roles and responsibilities. Team roles may

occur intermittently or throughout a project.

As discussed earlier in the chapter, inputs can be guidelines, tools, or outputs

produced by other business analysis tasks. Inputs are acted on by the task

elements and techniques, producing one or more task outputs. Let’s take a look

at the task inputs used when analyzing project stakeholders and planning how

to engage those stakeholders:

Needs The focus of the Plan Stakeholder Engagement task is on the

stakeholders who will be affected by the business need that is driving the

project. Over time, you may discover and analyze new stakeholders that the

business analysis team was unaware of at the beginning of the project. You also

need to beware of the stakeholders who change their position as the project

progresses. The business need for the project is defined during Strategy

Analysis.

Business Analysis Approach Successful business analysts make sure that

the business analysis approach and the stakeholder collaboration approach are

in sync with one another. Consistency across these two approaches ensures that

the business analysis activities, stakeholder collaboration activities, and

communication activities are all working together.

Let’s take a look at the guidelines and tools that are also used to build the

stakeholder engagement approach:

Business Analysis Performance Assessment The business analysis

performance assessment contains results from business analysis activities on

previous projects for you to review and incorporate into your current approach

to working with your stakeholders.

100

Change Strategy Checking the organization’s or the project’s change strategy

allows for improved assessment of stakeholder impact and development of more

effective stakeholder engagement strategies.

Current State Description How things are working right now provides

context for the work being done. Being familiar with the current state can lead

to more effective stakeholder analysis and understanding relative to the impacts

the planned change will have on your stakeholders.

Table 2.5 summarizes the inputs to the Plan Stakeholder Engagement task and

also lists the task that was the source of the input (if applicable).

TABLE 2.5 Inputs: Plan stakeholder engagement.

Task Input Input

Type

Input Source Source

Knowledge Area

Needs Input Define business needs. Strategy Analysis

Business analysis

approach

Input Define business analysis

approach.

Business Analysis

Planning and

Monitoring

Business analysis

performance

assessment

Guidelines

and tools

Identify business

analysis performance

improvements.

Business Analysis

Planning and

Monitoring

Change strategy Guidelines

and tools

Define change strategy. Strategy Analysis

Current state

description

Guidelines

and tools

Business analysts building the stakeholder collaboration plan at any point in

their projects should apply three detailed elements as they build their

stakeholder list, roles, and responsibilities. The detailed elements necessary to

analyze stakeholders and document meaningful information about them include

the following:

Perform stakeholder analysis.

Define stakeholder collaboration.

Assess stakeholder communication needs.

Let’s take a look at each element in greater detail.

Perform Stakeholder Analysis

How do you figure out who needs to be involved with the business analysis

activities for your project? It can be fairly straightforward to find the key

business analysis stakeholders for a project. Because business analysts tend to

spend a lot of time developing project requirements, identifying and analyzing

stakeholders is an absolute must. It can be quite painful to miss a significant

stakeholder early on and then discover them later in the project. There can also

be indirect or hidden stakeholders out there who are waiting to be found.

101

Exam Spotlight

Remember that the business analysis stakeholders are individuals or

organizations that are actively involved in or affected by the project’s

business analysis activities. These stakeholders might exercise influence

over the project and its results, as well as contribute to solution scope

definition and requirements development activities.

Stakeholder analysis consists of identifying stakeholders, defining stakeholder

characteristics, and analyzing the collected information. Stakeholder analysis

should occur at both the overall project level and each project phase. Business

analysts should perform this task when a business need is identified and revisit

and revise the results for as long as business analysis work continues on the

project. The business analysis stakeholders are an important subset of the

project stakeholders, so communication and coordination with the project

manager is required.

Stakeholders may have varying levels of responsibility, authority, and

participation. Their involvement can, and often does, change over the course of

the project life cycle. Business analysis stakeholder responsibilities and

authority can range from occasional contributions to the effort to having full

responsibility for the project and its outcome.

Identifying stakeholders late in the project is risky. This can lead to new

requirements late in the project life cycle, revisions to existing requirements,

solution rework, and possibly even new solution work that was not scoped out

or planned. Many stakeholders who are not involved at the appropriate time in a

project tend to be dissatisfied and often do not buy into the resulting solution.

There are four key areas for you to consider as part of your stakeholder analysis

activities: roles, attitudes, decision making, and power. Let’s look at each area in

greater detail.

Roles Understanding where and how your stakeholders will contribute to the

business analysis efforts is critical to the success of your project. The business

analyst must discover and document which stakeholders are responsible for the

work they are tasked to perform, which are accountable for making decisions,

which must be consulted prior to work being done, and which are to be

informed after work is complete. These roles may be relative to the entire

business analysis effort, a particular business analysis task, or a specific

business analysis deliverable, such as the business analysis approach you

learned about earlier in this chapter.

Attitudes Business analysts are responsible for assessing the positive and

negative attitudes and behaviors. When doing this, they need to consider a

number of factors. Stakeholder attitudes toward the project must be assessed

and then managed across the project life cycle. At a minimum, attitudes need to

be looked at relative to the business goals, objectives, and solution approach for

102

the project. Additionally, attitudes must be assessed from a people perspective,

considering things like the stakeholder’s perception of the value of business

analysis work, collaboration, and the sponsor and other key team members.

Decision-Making Authority The business analysis team needs to know

exactly which stakeholders have authority over the business analysis work and

deliverables. This includes reviewing and approving deliverables (such as

requirements), requesting and approving changes, and vetoing proposed

requirements or solutions.

Level of Power or Influence Understanding the nature of influence is

essential when building effective stakeholder relationships and trust. The

business analysis team should assess the influence of key stakeholders at the

project and organization levels. The amount of influence required for a

successful project should be analyzed relative to the amount of influence

possessed by the key stakeholders. Informal stakeholder influence with the

other stakeholders cannot be overlooked, as having informal project champions

is a gift to the business analyst.

Define Stakeholder Collaboration

How do you figure out who needs to be involved with the business analysis

activities for your project? It can be fairly straightforward to find the key

business analysis stakeholders for a project. Because business analysts tend to

spend a lot of time developing project requirements, identifying and analyzing

stakeholders is an absolute must. It can be quite painful to miss a significant

stakeholder early on and then discover them later in the project. There can also

be indirect or hidden stakeholders out there who are waiting to be found.

There are many approaches used to collaborate with stakeholders across the

business analysis life cycle. It can be challenging to keep your stakeholders

involved, interested, and engaged across the life cycle of your initiative.

Stakeholder collaboration can be planned and formal. It can also take place in a

spontaneous and informal fashion. Many business analysts document their

stakeholder collaboration approach in a stakeholder collaboration plan by

looking at the timing, location, and methods to be used for regularly scheduled

stakeholder collaboration.

Stakeholder Communication Needs

You may also find yourself building a stakeholder communication plan to

document your initiative’s stakeholder communication approaches. Typically,

these plans answer questions that address several aspects of stakeholder

communication, such as the following:

What needs to be communicated?

Who is the audience?

What is the delivery method?

When should a communication occur?

103

How often should a communication occur?

Where are the stakeholders located?

How much detail should the communication contain?

How formal should the communication be?

We recommend that you combine your stakeholder collaboration and

communication plans for the sake of efficiency and effectiveness. Both plans will

be more detailed components of your stakeholder engagement approach.

Plan Stakeholder Engagement Approach

The more business analysis stakeholders there are, the more complicated

dealing with them can become. Complexity factors that the business analyst

should consider include the number and variety of end users for the solution, as

well as the number of interfacing business processes and systems. This data is

initially discovered as a part of stakeholder analysis and factors into the

subsequent planning activities for both business analysis work and business

analysis communications. There are a number of techniques that you can use

when you are analyzing your project stakeholders. There are two techniques that

we highly recommend you use when analyzing business analysis stakeholders:

Organizational modelling

Stakeholder list, map, or personas

We usually start off our stakeholder analysis efforts with the organizational

modelling technique to get a sense of “who goes where” in the organization

relative to a project. We also like building stakeholder maps to view our key

stakeholders relative to different aspects of our projects and define who decides

what. Let’s take a look at these two recommended techniques in greater detail.

Recommended Technique: Organizational Modelling

Most of us have seen an organization chart showing the hierarchy. This is an

example of an organizational model. The model defines the purpose and

structure of an organization or an organizational unit. When you use this

technique for business analysis, you basically build an organization chart that

shows the organizational units, lines of reporting, the roles, and the people in

those roles.

When you are working with a new client, one of the first things you should ask

for is a current organization chart. This will allow you to evaluate who sits where

in the food chain and to decide who you might initially involve in your business

analysis efforts. This is an excellent way to identify business analysis

stakeholders.

Recommended Technique: Stakeholder List, Map, or Personas

Stakeholder lists, maps, and personas are essential to any business analysis

effort. The amount of information you put in your list is up to you. What you

104

draw in your graphical representation of your stakeholders depends on the

initiative itself. Personas are sometimes built to represent groups of users and

how they interact with a product, kind of like building a fictional character and

thinking about how they do things at work. Let’s take a closer look at

stakeholder maps and how they might be used when analyzing stakeholders.

Stakeholder maps are a graphical technique often used as part of stakeholder

analysis. Be aware that a stakeholder map is not the same thing as an

organization chart. While an organization chart shows people and how they fit

into the organizational reporting and common structure, a stakeholder map

looks at how these stakeholders will be involved with the resulting solution. This

takes the concept of an organizational model one step further by visually

relating the identified business analysis stakeholders to the solution, as well as

to one another.

There are two basic types of stakeholder maps: a stakeholder matrix and an

onion diagram. A stakeholder matrix provides a two-dimensional look at

stakeholder influence versus their level of interest in your efforts. By

comparison, an onion diagram depicts stakeholder involvement with the

resulting solution. Figure 2.3 shows an onion diagram.

FIGURE 2.3 Onion diagram

Another popular and useful stakeholder analysis technique is a RACI matrix.

This matrix defines business analysis stakeholder roles across four designations:

Responsible, Accountable, Consulted, and Informed. You may create the matrix

for the entire business analysis effort, a particular business analysis task, or a

specific business analysis deliverable, such as the business analysis approach

you learned about earlier in this chapter.

Responsible (R) Business analysis stakeholders are responsible for the work

that they are tasked to perform.

Accountable (A) Accountability lies with the sole decision maker who makes

105

the required decisions for the business analysis effort task or deliverable. For

any task or deliverable, there is only one accountable stakeholder.

Consulted (C) Relevant stakeholders should be consulted prior to the work

being done if their inputs or advice is needed.

Informed (I) This is usually an “after the fact” role as these stakeholders are

notified of the outcome after work is complete.

Table 2.6 shows an example of a RACI matrix.

TABLE 2.6 Example RACI matrix

Palmer Divide Vineyards Requirements Development

Tasks William Ginger Hector Sawyer Dan Hattie Taylor

Elicitation I I R, A R R I R

Analysis I I R, A R R I R

Specification A I R C C I C

Validation I I R, A R R I R

Additional Techniques to Consider

The BABOK

Guide lists some additional techniques that you can use when

analyzing your business analysis stakeholders for your project. They are

summarized for you here:

Brainstorming Brainstorming is an excellent technique to use when the

business analysis team is generating a list of all possible stakeholders for the

business analysis effort. Generating ideas about who the business analysis

stakeholders are could reveal hidden stakeholders that should be involved with

your efforts.

Business Rules Analysis We think of business rules as things that define or

constrain some aspect of how a business actually does business. They may

define the business structure or perhaps control how the business behaves day

to day. Business rules analysis allows you to identify those stakeholders who are

the source of the business rules and those who abide by the rules when

performing their jobs.

Document Analysis Document analysis is used to review existing

organizational assets that might assist in planning your stakeholder engagement

approach.

Interviews When interviewing business analysis stakeholders, the business

analyst should always ask the interviewees to identify additional stakeholders.

Lessons Learned Don’t forget to look in the past for successes and challenges

your organization has faced when it comes to engaging and collaborating with

project stakeholders.

Mind Mapping This is used to identify potential stakeholders and understand

the relationships between those stakeholders.

106

Process Modelling Anyone involved with the business processes that are

affected by the proposed solution should be identified as a stakeholder. Process

models can assist the business analyst with that identification, as they show the

related processes and systems.

Risk Analysis and Management The results of stakeholder analysis may

contribute to the risks for the business analysis effort and to the project. The

people involved with your efforts can be the source of possible risks, and they

can also help the team identify additional risks that may be important

downstream.

Scope Modelling Scope models can show the business analysis team the set of

stakeholders external to the solution scope that interact with the solution in

some way.

Survey or Questionnaire Business analysts may use this technique to

identify shared characteristics of a particular business analysis stakeholder

group.

Workshops When conducting requirements workshops on any project topic,

the business analyst should always ask the group of participants about any

additional stakeholders.

Once you have chosen one or more techniques to apply, you are ready to create

your stakeholder engagement approach. We’ll discuss that next.

Build the Stakeholder Engagement Approach

According to the BABOK

Guide, the following information about your business

analysis stakeholders should be included in the stakeholder engagement

approach:

Names

Titles

Characteristics

Location

Special needs

Authority levels

Number of individuals in each role

Description of stakeholder influence and interest

Collaboration approach

Communication plan

Remember that there are two discrete sets of information that a business

analyst needs to collect as part of their stakeholder list, map, or personas. First,

you have the administrative data, such as names, departments, contact

information, locations, roles, responsibilities, authority, and expertise. Second

are the actual results of the stakeholder analysis. This is where the business

107

analysis team assesses and records stakeholder influence, interest, expectations,

involvement, and any key requirements the stakeholders might have for the

business analysis efforts and the overall project.

Once the initial stakeholder list, map, or persona information is complete, you

use it as an input for a number of other business analysis tasks summarized in

Table 2.7. They include tasks from a number of knowledge areas such as

Business Analysis Planning and Monitoring, Elicitation and Collaboration, and

Requirements Analysis and Design Definition.

TABLE 2.7 Output: Plan stakeholder engagement approach.

Output Output Destinations Destination

Knowledge Area

Stakeholder

engagement

approach

Plan stakeholder

engagement.

Business Analysis

Planning and Monitoring

Plan business analysis

governance.

Business Analysis

Planning and Monitoring

Plan business analysis

information management.

Business Analysis

Planning and Monitoring

Prepare for elicitation. Elicitation and

Collaboration

Conduct elicitation. Elicitation and

Collaboration

Communicate business

analysis information.

Elicitation and

Collaboration

Manage stakeholder

collaboration.

Elicitation and

Collaboration

Define change strategy. Strategy Analysis

Assess risks. Strategy Analysis

A number of stakeholders are involved with conducting stakeholder analysis for

the business analysis activities of a project. Remember that the business analyst

shares responsibility for analyzing business analysis stakeholders with the

project manager. This means that any stakeholder analysis results should align

with the project stakeholder analysis results in both structure and content.

Key business analysis stakeholders may be able to recommend other

stakeholders to include in the stakeholder analysis results. This includes the

customers, domain SMEs, end users, the project manager, sponsors, the

regulator, and suppliers.

108

Case Study: Palmer Divide Vineyards Stakeholder List

Business analysts often like to use a spreadsheet to capture stakeholder

information and keep it in a single location. Table 2.8 provides a populated

template for an initial stakeholder list containing roles and responsibilities

at Palmer Divide Vineyards. You can collect the data shown here or add

information to your list based on your organization and the nature of your

project.

TABLE 2.8 Template: Stakeholder list containing roles and responsibilities

Name Position Role Responsibilities Location Influence

William Vineyard

co-owner

Project

sponsor

Governance and

funding

CO High

Ginger Product

manager

Project

manager

Project scope,

schedule, budget

CO Moderate

Hector Marketing

director

Lead

business

analyst

Requirements

development

CO Moderate

Sawyer Vineyard

manager

Cultivation

lead

Domain SME-

biodynamic

farming

CO High

Dan Winemaker Domain

SME

Domain SME -

enology

CO High

Hattie Admin.

assistant

Coordinator Project

administration

CO Low

Taylor IT director IT lead Implementation

SME

CO Moderate

Plan Business Analysis Governance

Business analysis governance is the road map for what decisions need to be

made, when the decisions need to be made, and who is responsible for actually

making those decisions. The business analysis team typically plans for business

analysis governance. The governance process also directs the change control

process, defining how changes will be analyzed, approved, documented, and

communicated.

Exam Spotlight

The BABOK

Guide governance planning activities focus only on business

analysis tasks and deliverables, such as decisions made about requirements

109

and designs.

Planning for business analysis governance is not much different from what the

project manager does to create a decision-making architecture for the project; it

is simply focused on business analysis work and deliverables. The business

analyst identifies how business analysis work will be approached and

prioritized, decides who has the authority to make certain types of decisions,

and figures out how to deal with the inevitable changes that will come their way.

If all goes well, the governance plan enables the business analysis team to work

well with the project manager and make the right business analysis decisions at

the right time.

Remember that a plan is a model of what needs to be accomplished for a

particular effort. Plans are frequently updated to reflect what is known at a

particular point in time. An initial business analysis governance plan often

requires revision based on issues that the team encounters, lessons learned

while work is being done, or changing business drivers and strategies that

impact the project. Figure 2.4 summarizes the inputs, outputs, techniques, and

associated tasks for planning business analysis governance in accordance with

the BABOK

Guide.

FIGURE 2.4 Task summary: Plan business analysis governance.

110

Planning for business analysis governance requires coordination

and communication with the project manager. The business analysis

governance should be consistent with the overarching project-level

governance that is in place.

Several key inputs for planning business analysis governance are guidelines,

tools, or outputs produced by other business analysis tasks, such as the business

analysis approach and the stakeholder engagement approach. These two

deliverables govern how the governance planning is done and who is involved

with the work to be performed. Let’s take a closer look at the two task inputs

used for planning business analysis governance:

Business Analysis Approach The business analysis approach governs

planning activities, as it defines the planning process and the development life

cycle. It is essential that you keep your business analysis governance process

consistent with the overall business analysis approach for your efforts.

Stakeholder Engagement Approach Understanding the preferences of key

business analysis stakeholders will shape the resulting business analysis

governance process to some degree. Stakeholder roles and levels of involvement

need to be understood and incorporated into your business analysis governance

process.

Let’s also take a look at the guidelines and tools that the business analyst may

use when planning business analysis governance:

Business Analysis Performance Assessment There is nothing like looking

at the past to help effective business analysts do better at planning for the

future. You can use previous business analysis work performance data on an

earlier phase in this project or on previous efforts as part of the current business

analysis planning activities.

Business Policies Every organization has limits on what decisions can be

made. Business analysts must be aware of these limits and plan for business

analysis governance accordingly. Decision making is often bounded by

contractual, legal, or regulatory constraints.

Current State Description The current state of the business area you are

planning to change provides the business analysis team with context for the

decisions that will need to be made moving forward.

Legal/Regulatory Information The business analyst should remember to

seek out and use any existing policies, procedures, methods, and templates as

part of planning business analysis activities.

Table 2.9 summarizes the guidelines, tools, and inputs to this task, and it lists

the source of the input (if applicable).

TABLE 2.9 Inputs: Plan business analysis governance.

Task Input Input Input Source Source

111

Type Knowledge Area

Business analysis

approach

Input Plan business analysis

approach.

Business Analysis

Planning and

Monitoring

Stakeholder

engagement

approach

Input Plan stakeholder

engagement approach.

Business Analysis

Planning and

Monitoring

Business analysis

performance

assessment

Tools and

guidelines

Identify business

analysis performance

improvements.

Business Analysis

Planning and

Monitoring

Business policy Tools and

guidelines

Current state

description

Tools and

guidelines

Legal/regulatory

information

Tools and

guidelines

When planning business analysis governance, a business analyst needs to put on

their project manager hat for a little while. Planning business analysis activities

includes four detailed elements that define how the business analyst will

approach it:

Decision making

Change control process

Plan the prioritization approach

Plan for approvals

Let’s take a look at each element in greater detail.

Decision Making

Business analysts must define which stakeholders are responsible for making

key decisions as part of the business analysis efforts. The decision-making

process in the business analysis governance approach defines who is involved in

making what decisions and to what degree. This is similar to defining the roles

and responsibilities in a RACI matrix, as we discussed earlier relative to

stakeholder engagement. Stakeholders may have many roles in decision making,

such as the following:

Participating in decision-making discussions

Providing subject-matter expertise as part of decision-making

Reviewing information

Approving decisions that are made

Business analysts also need to think about how to handle decisions when the

team cannot reach agreement or consensus. Setting forth escalation paths and

112

defining the stakeholders with the authority to make a final decision is a key

component of business analysis governance.

Change Control Process

The business analysis team must decide how to handle changing requirements

and designs across the project life cycle. The change control process should

address not just baselined requirements but also changes to requirements that

the business analyst develops. If the organization has a robust change

management process, the business analyst can apply it to the requirements

work on the project. If not, the business analysis governance approach needs to

address how changing requirements are to be handled. This includes

determining the process for requesting requirements or design changes,

authorizing requirements or design changes, performing impact analysis for

significant change requests, and determining how change requests are worded.

Exam Spotlight

The BABOK

Guide recommends that the requirements management

process spell out the components found in a request for change. At a

minimum, a change request should include cost and time estimates, an

assessment of benefits and risks associated with the change, a priority for

the requested change, and a recommended course of action.

Plan the Prioritization Approach

All requirements and designs are not created equal, nor do they deliver equal

value to the business and the stakeholders. Business analysts are responsible for

establishing the requirements, the design prioritization process technique, and

the level of formality for their projects. They are also responsible for defining

the prioritization scheme and process as early in the project as possible. This

enables the project stakeholders to understand and buy into the way the

business analysis team will prioritize the project requirements and designs at all

levels of detail and focus, including the business, stakeholder, solution, and

transition requirements found in the BABOK

Guide. We will spend more time

on this topic when we look at prioritizing requirements during requirements

analysis and design definition activities.

Plan for Approvals

Many organizations have defined sets of project deliverables, including

deliverables that are traditionally created as a result of business analysis work.

The business analysis team needs to decide where in the project life cycle the

business analysis deliverables are created, agreed upon, and updated. You can

find the full list of the recommended BABOK

Guide deliverables that may

113

require approvals along the way along with a brief description in Appendix E,

“Quick Summary of Business Analysis Deliverables,” of this book.

Techniques to Consider

The BABOK

Guide lists numerous techniques that can be used when planning

business analysis governance for your projects. They are summarized for you

here:

Brainstorming As part of business analysis planning, decomposing and

understanding the business analysis tasks and deliverables sufficiently enables

effective planning.

Document Analysis Be sure to review existing governance processes or

templates used for business analysis activities or for the overall project. The

existing processes may have an impact on how to define and perform

governance as part of your project.

Interviews The business analysis team may use interviews as a method to

identify and select individuals who are responsible for business analysis

decision-making, change control, prioritization, or approval activities.

Item Tracking For many business analysts, item tracking is synonymous with

issue management. Be sure to keep track of your issues while planning your

governance approach.

Lessons Learned There is no need to reinvent the wheel or to make the same

mistakes when defining business analysis governance. Effective business

analysts use lessons learned on previous projects to keep them on track with

their own planning efforts.

Organizational Modelling Organizational models show the relationships

between stakeholders and the roles and responsibilities the stakeholders have

within the organization.

Process Modelling Many business analysts use process models to document

the process or flow of business analysis decision making.

Reviews Don’t forget to review your governance approach with your key

stakeholders and get their buy-in and approval on how decisions will be made

and how change control will be used.

Survey or Questionnaire The business analysis team may use surveys or

questionnaires as ways to identify and select individuals who are responsible for

business analysis decision-making, change control, prioritization, or approval

activities.

Workshops Workshops are excellent ways to work with a group and identify

and select individuals who are responsible for business analysis decision-

making, change control, prioritization, or approval activities.

Once you have chosen one or more techniques to apply, you are ready to create

your business analysis governance approach. We’ll take a look at that next.

114

Create the Business Analysis Governance Approach

The business analysis governance approach should resemble the project

governance approach of which it is a part. The level of detail in these plans

depends on several factors, including the business analysis approach for the

effort and the overall methodology being used for planning. According to the

BABOK® Guide, the recommended content of a business analysis governance

approach answers questions such as these:

Who has responsibility and authority to make decisions about business

analysis work?

Who sets priorities for business analysis information?

Who approves changes to business analysis information?

Who defines the change management process for requirements and designs?

Once the business analysis governance approach is complete, it is used as input

by a number of other business analysis tasks summarized in Table 2.10. They

are picked up and applied by several Business Analysis Planning and

Monitoring and Requirements Life Cycle Management knowledge area tasks.

TABLE 2.10 Output: Plan business analysis governance.

Task Output Output Destination Task Output Destination

Knowledge Area

Governance

approach

Plan business analysis

information management.

Business Analysis Planning

and Monitoring

Prioritize requirements. Requirements Life Cycle

Management

Assess requirements changes. Requirements Life Cycle

Management

Approve requirements. Requirements Life Cycle

Management

Any business analysis stakeholder can be involved with planning the business

analysis governance for a project. Of particular interest is the verification and

validation of key business analysis deliverables across the project life cycle. It is

essential that the project manager participates in this effort because the

business analysis plans are part of the higher-level project plan.

Key business analysis stakeholders may provide information or use the business

analysis plans for their own planning efforts. Stakeholders involved with

planning activities may include the following:

Project manager

Regulator

The sponsor

The business analysis governance approach augments the stakeholder

engagement approach by identifying specific stakeholder responsibilities for

115

decisions about business analysis work and change control. The governance

approach also defines the process to manage requirements and design changes

across the initiative.

The business analysis team also needs to take a closer look at how they plan to

manage, store, and access all of the business analysis information produced

across the project life cycle. That is defined in the business analysis information

management approach. Let’s move on to step through how the business analysis

information management approach and its associated activities should be

planned for on a project.

Plan Business Analysis Information Management

When you ask people what business analysts do, the first answer you usually

hear is that business analysts write requirements. That’s true. However,

developing and managing requirements and design information on a project

entails significantly more than just writing skills. The business analysis team

must define their process for developing requirements and designs. They must

consider how they will approach requirements and design traceability, reuse,

requirements storage and access, and the requirements attributes to be applied.

This information is formally documented in the business analysis information

management approach.

Once the business analysis team establishes the information management

approach for a project, the approach is not expected to change significantly

across the project life cycle. However, it should be revisited at each phase of the

project to ensure that it is being followed and that no changes are required for

the work that will be started or based on business analysis performance to date.

To plan for information management, the business analyst must understand the

organizational process needs and objectives that apply to the project. These

needs and objectives may include compatibility with other organizational

processes, constraints on time-to-market, regulatory and governance framework

compliance, a desire to evaluate new approaches to solution development, or

other business objectives.

In some organizations, an information management process or approach is

already in place. If that is the case, the business analysis team needs to review

the existing process and tailor it to fit their current project and environment.

Remember that the business analysis team needs to develop project

requirements and designs before managing them across the project life cycle.

One important aspect of business analysis information

management is communicating requirements and design information across

the project life cycle. It is essential to elicit the right information from key

stakeholders about the capabilities of the desired solution and to validate

that the analyzed requirements and design information is correct and

complete.

116

Figure 2.5 summarizes the tasks required for Plan Business Analysis

Information Management.

FIGURE 2.5 Task summary: Plan business analysis information management.

Now let’s get to the task at hand, which is planning how to address business

analysis information management. Every task has inputs, outputs, elements,

guidelines, tools, and techniques. This task is no exception. Remember that task

inputs are either informational in nature or outputs produced by other business

analysis tasks. Inputs are acted on by the task elements and techniques,

producing one or more task outputs. Let’s take a look at the three task inputs

used when planning a business analysis information management approach:

Business Analysis Approach The information management approach

should align with the business analysis approach for your initiative, as well as

aligning with the other approaches defined in this knowledge area.

Governance Approach The governance approach identifies how to deal with

changes, decisions, approvals, and priorities for requirements and designs.

Stakeholder Engagement Approach The defined stakeholder collaboration

and communication needs guide specific business analysis information needs.

Basically, you must define what you need to know and who you need to get

information from. Then, go out and get that information.

There are other guidelines and tools that can be used. Guidelines are

instructions or descriptions about why or how the business analyst might

undertake a particular task. Tools are methods of conducting business analysis

117

tasks or shaping a task output. Let’s take a look at the guidelines and tools that

business analysts apply when planning the business analysis information

management approach:

Business Analysis Performance Assessment Be sure to review and

incorporate results of previous business analysis efforts into your business

analysis information management approach.

Business Policies Business policies define the limits within which business

decisions must be made and how work will be completed. These policies also

frame and constrain the information management approach that you select.

Information Management Tools Take a look at the tools your organization

currently uses to store, retrieve, and share business analysis information. These

may be the tools your organization requires you to use on your initiative.

Legal/Regulatory Information Sometimes legislative rules or regulations

have an impact on your business analysis information. If that is the case, you

need to address these additional constraints, such as information security or

privacy, in your information management approach.

Table 2.11 summarizes the inputs, guidelines, and tools for this task and lists the

source of the input (if applicable).

TABLE 2.11 Inputs: Plan business analysis information management.

Task Input Input

Type

Input Source Source

Knowledge Area

Business analysis

approach

Input Plan business analysis

approach.

Business Analysis

Planning and

Monitoring

Stakeholder

engagement

approach

Input Plan stakeholder

engagement.

Business Analysis

Planning and

Monitoring

Governance

approach

Input Plan business analysis

governance.

Business Analysis

Planning and

Monitoring

Business analysis

performance

assessment

Guidelines

and tools

Identify business

analysis performance

improvements.

Business Analysis

Planning and

Monitoring

Business policies Guidelines

and tools

Information

management tools

Guidelines

and tools

Legal/regulatory

information

Guidelines

and tools

Planning the information management approach for business analysis activities

requires the business analyst to understand both the business and technical

drivers for the project. The business analyst addresses six detailed elements

118

when planning for requirements management activities across the project life

cycle.

Organize business analysis information.

Define the levels of abstraction.

Decide the traceability approach.

Plan for requirements reuse.

Look at information storage and access.

Select requirements attributes.

Let’s take a look at each of these information management elements in greater

detail.

Organize Business Analysis Information

Organizing business analysis information is a challenging task on a complex

project. Information must be structured for efficient access and ease of use.

Duplication of requirements and conflicting requirements should be avoided.

Business analysts decide how to do this early in their projects. Planning how you

will organize your business analysis information requires consideration of the

following factors:

The type and amount of information to be collected

Stakeholder access and usage needs

Size and complexity of the change

Relationships between the types of information

When defining your organization scheme, you must also take into account how

much detail you plan to have and collect for your project. That takes us into our

next element, defining the levels of abstraction for business analysis

information.

Define the Levels of Abstraction

Deciding the breadth and depth of business analysis information can be

challenging. Business analysis information typically ranges from very high-level,

conceptual data to very detailed data about a particular capability. Three

perspectives are essential as part of this definition: the stakeholder information

needs, the complexity of what is being explained, and the importance of the

change.

Business analysts must also consider the relationships between the pieces of

information they collect and with which they work. That means defining the

traceability between the pieces and parts of the project data, particularly when it

comes to requirements and design information.

Decide the Traceability Approach

119

Traceability is a tricky thing. The business analyst wants to show the

relationships between key pieces of business analysis information while not

spending time tracing things that are not important. The information

management approach is where the business analysis team figures out how to

trace project requirements and designs. These decisions are based on project

type and complexity.

The BABOK® Guide recommends taking into account the following factors

when planning traceability for your project requirements and designs:

Complexity of the domain

Number of views of requirements that will be produced

Requirements related risks, standards, and regulations

Costs and benefits of traceability

Creating and maintaining traceability adds to the business analyst’s workload

on a project, so it should be reflected in the information management approach

as well as in all subsequent planning activities.

We will take a closer look at implementing traceability for our requirements and

designs in Chapter 4, “Overarching Tasks: Requirements Life Cycle

Management,” when we step through the trace requirements task within this

knowledge area. Now let’s move on and talk about planning for requirements

reuse.

Plan for Requirements Reuse

Some requirements developed for a particular project might also be candidates

for long-term use or reuse by the organization. The requirements that you

choose to maintain might relate to infrastructure, hardware, software, or

operational capabilities that the organization must meet on an ongoing basis

versus just for your particular project. Common features or services used across

multiple systems or process are also good candidates for reuse. Reusable

requirements are structured, stored, and accessed by other business analysts in

the organization. This “ease of reuse” requires advance planning and a common

requirements storage repository.

The BABOK

Guide lists several types of requirements that can be reused

across projects within an organization.

Regulatory requirements

Contractual obligations

Quality standards

Service level agreements (SLAs)

Business rules or processes

Product requirements

We will take a closer look at reusing requirements and designs in Chapter 4,

when we look at the maintain requirements task within this knowledge area.

120

Reuse requires the ability for people to access the saved information. Let’s look

at that element next.

Look at Information Storage and Access

It is essential that the business analysis team create an information repository

for storing requirements and designs. Use of the repository should be linked to

the process defined in the information management approach and in the higher-

level business analysis approach. Documents created during the project life

cycle should be saved in a secured area.

Practically speaking, all business analysis documents, including

the project requirements, should be saved in a business analysis document

repository. If the same requirements document is required to be stored both

in the project document repository and in the business analysis storage

area, the project document repository should contain the unofficial copy.

The storage location for requirements and design work-in-progress

documentation is at the discretion of the project manager or lead business

analyst. Documents and copies (electronic or paper) that exist outside the

project or business analysis information repositories should be made the

responsibility of the document originator.

Select Requirements Attributes

Selecting requirements attributes for a project is an important step. Attributes

are intended to be of assistance in the ongoing management of requirements

across the project life cycle. Experienced business analysts know how to select

the requirements attributes that add value to the requirements information for

their project. Attributes allow the team to associate information and add context

to individual requirements or groups of requirements.

Be careful when selecting your requirements attributes. Too many

attributes can overwhelm business analysts with too much information. Too

few attributes will cause the business analysis team to miss critical

requirements information later in the project life cycle.

The BABOK

Guide recommends that the business analysis team consider

using one or more of the common requirements attributes listed in Table 2.12.

Business analysts can also select from additional requirements attributes that

are less frequently used, such as cost, resource assignment, revision number,

traced-from, and traced-to.

121

TABLE 2.12 Common requirements attributes

Attribute Description

Absolute

reference

Unique numeric or text identifier for each requirement

Author Name of the person who wrote the requirement if you have any

questions later

Complexity Difficulty in implementing the requirement

Ownership Individual or group that needs the requirement

Priority Indicates the relative importance of requirements so you can

decide which requirements should be implemented first

Risks Associated with meeting or not meeting the requirements

Source Origin of the requirement if you need more information later

Stability Indicates requirements maturity and if you can start work on it

Status Proposed, accepted, verified, postponed, cancelled, or

implemented

Urgency How soon the requirement is needed

The BABOK

Guide lists several techniques that you can use when planning for

business analysis information management for your project. They are

summarized for you here.

Techniques to Consider

The BABOK® Guide recommends the use of one or more techniques when you

are defining the business analysis information management approach for your

project. Let’s take a closer look at each one.

Brainstorming Brainstorming with stakeholders helps them uncover and

share ideas about what their business analysis information management needs

might be.

Interviews The business analysis team uses interviews with stakeholders as a

way to identify and define their business analysis information management

needs.

Item Tracking This technique allows for managing and tracking of issues

discovered relative to information management needs on your project or

initiative.

Lessons Learned Be sure to review existing information management tools,

processes, and techniques used in your organization. The existing methods may

have an impact on how to define and perform information management as part

of your project.

Mind Mapping Mind mapping allows the business analysis team to identify

and categorize business analysis information that needs to be managed.

Process Modelling Process models graphically depict the process used to

122

manage business analysis information. These models can help your stakeholders

understand how to manage requirements, designs, and other data on your

projects.

Survey or Questionnaire Many business analysts use this technique to

remotely request stakeholder input about their business analysis information

management needs.

Workshops Workshops allow you to discover business analysis information

needs from groups of stakeholders versus asking people one by one.

Once you have chosen one or more techniques to apply, you are ready to create

your information management approach. We’ll discuss that next.

Define the Business Analysis Information Management Approach

The information management approach describes how business analysis

information will be stored, accessed, and used during and after your project.

Many components of this approach impact your process for developing and

managing requirements. The BABOK® Guide recommends that the information

management approach define the following aspects of the business analysis

information on your projects:

Organizing the business analysis information

Capturing information at the correct level of detail

Tracing the relationships between the information

Using or reusing the information across the enterprise

Accessing and storing information

Maintaining characteristics about the information

Once the information management approach is complete, the business analysis

team uses it as an input for a number of other business analysis tasks

summarized in Table 2.13. The approach provides information to tasks from

several knowledge areas that focus on eliciting, analyzing, and communicating

project requirements.

TABLE 2.13 Output: Plan business analysis information management

approach.

Output Output Destinations Destination Knowledge

Area

Information

management

approach

Communicate business

analysis information.

Elicitation and

Collaboration

Trace requirements. Requirements Life Cycle

Management

Maintain requirements. Requirements Life Cycle

Management

123

Define requirements

architecture.

Requirements Analysis and

Design Definition

The business analyst has the primary responsibility for creating or tailoring the

information management approach for their project. The project manager also

participates in this effort as they have responsibility for managing changes to

the project scope and are accountable for delivering the resulting solution.

Ideally, the change management approach for the project should also govern

any requirements or design changes.

Several business analysis stakeholders are impacted by the contents of the

information management approach.

Domain SMEs

Regulators

The sponsor

In addition to defining the information management approach, the business

analysis team needs to take a closer look at how they plan to measure and

control business analysis work performance across the project life cycle. That is

defined in the business analysis performance assessment. Let’s move on to step

through how business analysis performance improvements should be planned

for on a project.

Identify Business Analysis Performance Improvements

There is no reason to do business analysis planning if the team isn’t going to use

those plans and approaches to measure and control business analysis

performance. The primary reason for building the previous four business

approaches in the Business Analysis Planning and Monitoring knowledge area is

to be able to perform, monitor, and report on the business analysis work that is

being done. This occurs at two levels: for the overall project and for each project

phase. Monitoring and measuring business analysis performance against the

business analysis approaches and the project plan ensures that the project’s

business analysis effort produces the desired outcomes and that the business

analysis work is performed efficiently.

Implementing the Two-Faced Project

Remember the two-faced project we looked at as part of the earlier

discussions on predictive versus adaptive project approaches? Well, you are

a team lead on this online payment-processing system project. The system

itself has been defined, designed, and developed. Your job is managing one

or more of the adaptive “onboarding” of new customer implementations.

One goal is to complete a successful customer implementation of this

124

system in less than 30 days. A large part of this work is jointly defining

customer requirements and working together with the customers to get the

payment link on their websites up and running with the customer’s look and

feel.

Ginger calls you into a meeting to review the current status of your first

implementation effort. Not only are you expected to complete the work in

less than 30 days, there is also a budget indicator attached to these efforts.

Your planned budget for your “onboarding” effort is $20,000 across the

planned 30 days of work. Currently, you are one week into the effort and

have spent $9,000 of this planned budget. This budget measurement one

week into your efforts is a metric, and it will be compared to the indicator

and analyzed to see whether all is well at this point in time.

Ginger asks about this status and why almost half of your budget has been

spent when you are only a quarter of a way through this project. Lucky for

you, this is not a negative thing. You and your team have been defining the

customer requirements for the interface and are expected to front-load the

schedule and budget to get the definition as accurate as possible. Of course,

that leaves you $11,000 for the next three weeks of work, so you will watch it

closely to make sure both the work and the spending stay on track.

Monitoring and controlling the progress and performance of business analysis

work is not simply an objective task. You don’t just look at a metric at a point in

time and say that things are good or bad. Many additional factors can come into

play. Business analysts almost always do some sort of analysis when looking at

the current state of things and what is in the business analysis plan and

approaches. This is how you determine whether a particular situation is

acceptable at a point in time or whether there are issues to be addressed.

Exam Spotlight

Capturing business analysis performance metrics is done throughout the

project life cycle. Once potential performance improvements are identified,

they become guidelines for the next time a task is executed.

The business analysis team is responsible for determining the metrics used to

measure business analysis work on the project. Indicators are specific

numerical measurements that represent a measure for a specific set of business

analysis activities or deliverables. Figure 2.6 summarizes the task.

Two key inputs are used in managing business analysis performance for a

project. The following are the specific task inputs used when managing business

analysis performance on a project:

Business Analysis Approach Business analysis performance is traditionally

measured in the same way you look at project performance. The business

analysis approach is used to measure actual progress against the planned

125

deliverables, activities, tasks, and estimates.

Performance Objectives (external) Many organizations define the high-

level performance outcomes that they want to achieve as a result of the projects

or initiatives. These external performance outcomes need to be factored in to

the business analysis performance improvements.

FIGURE 2.6 Task summary: Identify business analysis performance

improvements.

In addition to inputs, there is an additional guideline used as an input to this

task. Interestingly enough, many of these inputs, guidelines, and tools are

metrics, standards, or expectations for performing business analysis work on a

project. Here is the guideline:

Organizational Performance Standards Many organizations have

mandated performance standards or expectations for business analysis work

and for their overall organization or enterprise as well. If this is the case, the

business analysis team must factor these into the business analysis performance

metrics for their project.

Table 2.14 summarizes the inputs to this task and lists the source of the input

(if applicable).

TABLE 2.14 Inputs: Identify business analysis performance improvements.

Task Input Input

Type

Input Source Source Knowledge

Area

Performance metrics

(external)

Input

Business analysis

approach

Input Plan business

analysis activities.

Business Analysis

Planning and

126

Monitoring

Organizational

performance

standards

Guidelines

and tools

Metrics can be tricky. A metric is a standard of measurement defined for some

aspect of business analysis performance. Metrics define a quantifiable level for

an indicator that the business analysis team wants to accomplish, such as

meeting a schedule date for an activity or staying on budget for a particular

phase of project work. Indicators identify specific numeric measurements

indicating progress toward achieving something, such as scheduled work

estimated to complete an activity or a particular budget number.

If the business analysis team does not select and define relevant metrics, it will

be difficult to measure and assess how well business analysis work is done

during the project. Identifying business analysis performance improvements

requires the business analysis team to address four detailed elements:

Performance analysis

Assessment measures

Analyze results

Recommend actions for improvement

Let’s take a closer look at each of these elements.

Performance Analysis

The business analysis team must decide on the methods to be used for reporting

tracking and archiving business analysis performance data. These reports can

range from formal, written documents and presentations to informal

conversations by the water cooler. If the reports are to be archived, then they

must be in writing. Again, many of these requirements may be set at the project

level by the project manager, so keep the lines of communication open with that

individual on your projects.

Assessment Measures

Business analysts don’t always find it easy to define the level of performance

required for effective business analysis work. It is necessary to determine the

appropriate performance measures for effective business analysis work on a

specific project. There are the traditional measures to report on, such as meeting

schedule dates for activities and deliverables that can be applied. There are also

more requirements-focused metrics, such as the frequency of requirements

changes or the number of review cycles needed.

According to the BABOK

Guide, performance metrics will

127

encourage certain behaviors and discourage others. Poorly chosen metrics

may drive behavior that is detrimental to the enterprise as a whole.

Performance measures may be quantitative or qualitative in nature.

Quantitative data tends to be numeric and can be measured. Qualitative data is

subjective and can be observed but not actually measured. Table 2.15 describes

potential business analysis performance measures.

TABLE 2.15 Business analysis performance measures

Measure Description

Accuracy and

Completeness

Determine whether business analysis work products are

correct and relevant when delivered or if revisions are required

to gain stakeholder acceptance.

Knowledge Assess whether the business analyst has skills and/or

experience to perform the task.

Effectiveness Assess if business analysis work products are easy to use as

standalone deliverables or if they require extensive explanation

in order to be understood.

Organizational

Support

Assess if adequate resources are available to complete business

analysis activities.

Significance Consider the benefit obtained from work products and assess if

cost, time, and resource investments expended to produce the

work products were justified for the value delivered.

Strategic Look to see whether business objectives were met, problems

were solved, and improvements were achieved.

Timeliness Evaluate whether the business analyst delivered work on time

per stakeholder expectations and schedule.

Assessing the value of business analysis work is done relative to a specific target

for performance. Be sure you know who sets these targets for analyzing

performance results in the organization.

Analyze Results

Business analysts look at the performance of the business analysis deliverables,

the resources performing the work, and the overall business analysis process

relative to the defined measures. Business analysis performance can be

measured and evaluated from more than one point of view, such as the

stakeholders, the business analysis team, a personnel manager, or an

organization’s Center of Excellence.

Recommend Actions for Improvement

After business analysts have the business analysis performance measures in

hand for a particular period of time, they can assess those measures and

determine whether any problems or improvement opportunities exist.

128

Experienced business analysts know they must engage key stakeholders to assist

the business analysis team in identifying any corrective actions or preventive

actions that might be required.

Corrective actions occur after the fact and are ways to reduce the negative

impact of an event. In contrast, preventive actions focus on reducing the

probability of a negative event happening in the first place. There is also a

positive side of the coin: improvement actions. These actions occur when you

want to increase the probability or impact of events with positive impacts on

business analysis work and deliverables.

Exam Spotlight

Corrective and preventive actions are not the same thing. Corrective actions

are steps taken to remove the causes of existing nonconformities or errors

after they occur. Preventive actions try to stop events from happening in the

first place.

Recommended Technique: Metrics and Key Performance Indicators

Metrics and key performance indicators (KPIs) are the basis for the monitoring,

evaluation, and reporting system that addresses business analysis work, the

overall project, and the resulting solution. KPIs are indicators that allow the

business analyst or business analysis team to measure performance or progress

of solutions and solution components toward strategic goals or objectives.

Metrics facilitate the more basic monitoring and evaluation of business analysis

work activities and deliverables in your quest to meet the overall solution goals.

Metrics and KPIs are essential for the ongoing monitoring and evaluation of

business analysis activities on any project. Effective monitoring, evaluation, and

reporting must address several elements: indicators, metrics, structure, and

reporting. To measure a particular aspect of a project or solution, you must have

at least one indicator. The business analyst needs to know the source of each

defined indicator, how to collect the measurement, the person or system doing

the collecting, and how often it will be done. Good indicators meet five quality

characteristics: they are clear, relevant, economical, adequate, and quantifiable.

If indicators can’t be quantified and measured when we need them, they are not

of much use.

Exam Spotlight

Metrics can be a specific point, a threshold, or a range of values based on

what is being measured. They allow the business analysis team or the

project manager to track, assess, and report on the quality of business

129

analysis work that is being done.

Other Techniques to Consider

These techniques assist the business analyst in building a thorough and

consistent approach to identifying business analysis improvements on their

projects.

Brainstorming Brainstorming is a good way for a group of stakeholders to

generate ideas for business analysis improvement opportunities.

Interviews Another source of business analysis performance data is to

interview key business analysis stakeholders and ask them for their assessment

of the business analysis work on the project.

Item Tracking Issue management activities take into account tracking

business analysis work performance issues that occur so those issues can be

addressed and resolved later.

Lessons Learned A lesson learned process allows the business analyst to

compile and document successes, failures, and recommendations for improving

performance of business analysis activities on future projects.

Observation This technique allows you to witness business analysis

performance in person and see for yourself how things are being done.

Process Analysis Process analysis is a technique to analyze existing business

analysis processes and suggest ways to improve them, either as a group or as an

individual.

Process Modelling Business analysis processes can be modelled and

improved using this technique. The business analysis team may find it helpful to

graphically depict the flow of business analysis work in order to improve

performance.

Reviews Sitting down in a review meeting can help the team identify changes

to business analysis processes and deliverables that can be incorporated into

future work activities.

Risk Analysis and Management One facet of this technique should focus on

identifying and managing potential risks that may impact business analysis

work activities and deliverables.

Root Cause Analysis Asking “why?” five times can help the business analysis

team identify the actual cause of problems encountered when performing

business analysis work.

Survey or Questionnaire If you can’t speak directly with your key

stakeholders, consider sending them a survey or questionnaire to ask them for

their assessment of the business analysis work performance on the project.

Workshops Workshops are used to assess business analysis performance and

generate ideas of improvement opportunities in a group setting.

Experienced business analysts apply one or more of these business analysis

130

techniques to manage, monitor, and control the performance of a project’s

business analysis work. On many projects, the project manager steps into this

role, looking at business analysis work as a subset of their overall project. At

other times, the lead business analyst watches what is going on, decides if all is

well, and takes action when needed. Regardless of who is monitoring the

business analysis work, the business analysis performance assessment should be

created and used by the project team. Let’s have a closer look at this key

business analysis deliverable.

Produce the Business Analysis Performance Assessment

The business analysis performance assessment helps the business analysis team

compare planned versus actual performance of business analysis work activities.

If there are significant variances from the plan or approach, this assessment

addresses the root cause of these variances and suggests approaches for

resolving issues.

The business analysis performance assessment provides ongoing performance

information to assist the team in planning future business analysis work based

on what has happened to date. As a result of assessing business analysis

performance, the business analysis team may need to revise the business

analysis processes, results, and templates that are being used. The revisions

could be adding in new approaches that increase efficiency, or they could be

correcting things that are not working well. In either case, these results should

be treated as lessons learned and incorporated into the process assets and

business analysis information of the organization.

Once the business analysis performance assessment is complete, it is used as an

input by a number of other business analysis tasks summarized in Table 2.16.

TABLE 2.16 Output: Identify business analysis performance improvements.

Output Output Destinations Destination

Knowledge Area

Business analysis

performance

assessment

Plan business analysis

approach.

Business Analysis

Planning and

Monitoring

Plan stakeholder

engagement.

Business Analysis

Planning and

Monitoring

Plan business analysis

governance.

Business Analysis

Planning and

Monitoring

Plan business analysis

information management.

Business Analysis

Planning and

Monitoring

Manage stakeholder

collaboration.

Elicitation and

Collaboration

131

The business analyst has the primary responsibility for creating the business

analysis performance assessment for their project and updating any business

analysis information. The project manager also participates in these efforts as

they have responsibility for monitoring performance and updating process

assets for the project. Ideally, the monitoring, evaluation, and reporting

approach for business analysis work should align with the project approach to

handling this data.

Several business analysis stakeholders are interested in the contents of the

business analysis performance. They include domain SMEs, the project

manager, and the sponsor.

132

How This Applies to Your Projects

In this chapter, you stepped through planning a serious set of business analysis

approaches for a project. Performing business analysis work is much more

straightforward if the team takes the time to think about and plan what they are

going to do and how they are going about doing it before they start doing the

work. Working on projects where the value of business analysis work is

discounted can result in little to no planning for the business analysis activities

and deliverables for the project. You will have to scramble and rely on your

business analysis experience to get the work done if you are not prepared for

everything that is needed. This is not the way to do good work. Planning

business analysis activities is an important piece of the overall project planning,

and it should be done for every business analysis effort.

The Shewhart “plan–do–check–act” cycle (Figure 2.7) is a four-step model that

forms the basis for all of the tasks and elements found in the BABOK

Guide.

The concept that “we plan prior to doing the work and measure what has been

done” applies throughout the activities in the Business Analysis Planning and

Monitoring knowledge area. The business analysis team plans project or project

phase activities, deliverables, and approaches prior to actually doing the work.

After the work is done, the business analysis team looks at the results to see

what was learned and how well the work was performed. Anything that requires

improvement is addressed prior to the next round. Things that worked well are

repeated and used in subsequent efforts.

FIGURE 2.7 The Shewhart cycle

A core set of business analysis planning and documentation should be required

for all projects regardless of project size or type. For complex projects, business

analysts may choose to use the full set of BABOK

Guide deliverables across the

six knowledge areas plus any project or technical documents that are required.

In some cases, the business analysis deliverables may be combined and

simplified for change-driven or straightforward project efforts. Business

analysis documents should always be consolidated where feasible.

Some documents might not be required if the information is entered directly

into other project documentation. If you choose to use other documents to

record business analysis– specific data, make a note of this new information

location in your business analysis communication plan. When work is being

133

performed at a client site, additional business analysis documentation is often

required for a particular project by either the Project Management Office

(PMO), project governance, corporate quality management, or technical

management disciplines. This additional documentation is worth discovering

early on so you plan your approach and process for producing it.

Another area that requires business analyst’s attention is the process for

endorsing and approving business analysis documents. We recommend

allowing endorsement of business analysis documents for storage in the project

document repository in one of the following two ways (as long as you are not in

a regulated environment):

On Paper Sign a paper rendition of the document, scan the signature page, and

send the scanned image along with the electronic copy of the document to the

PMO.

Electronic Sign-Off Ask the signatory to send an email stating that the

document has been reviewed and/or accepted, enter the words “email

signature” in the signature block of the document, and send a copy of the email

along with the electronic copy of the document to the PMO.

134

Summary

The five tasks of the Business Analysis Planning and Monitoring knowledge area

do a nice job of producing a core set of planning and process-focused

deliverables that can be referenced and applied across the project life cycle. The

focus of these plans is twofold: the overall project and its more detailed project

phases. Many planning techniques focused on defining and scheduling

activities, and deliverables come straight from the project management

playbook.

The BABOK

Guide recommends business analysts begin their planning efforts

by building their business analysis approach. This basically defines the business

analysis methodology to be used across the project life cycle. Concurrently, the

business analysis team also identifies, analyzes, and categorizes the business

analysis stakeholders with which they will be working. The business analysis

approach and the stakeholder engagement approach are communicated,

aligned, and shared with the project manager who is responsible for overall

project success.

One of the primary roles of the business analyst is developing and managing

requirements across the project life cycle. Decision making and change control

are also defined as part of the business analysis governance approach. The

business analysis team has to decide on how to collect and store information

while performing business analysis work. This content is found in the business

analysis information management plan.

Once these key business analysis deliverables are in place, they are revisited and

revised as necessary. The business analyst should look at them whenever they

are planning a new project phase, re-planning a phase that needs attention, or

dealing with significant changes or issues that impact solution scope or project

requirements and design. The approaches are used as the basis for the ongoing

and iterative monitoring, evaluating, and reporting on the performance of

business analysis work in the business analysis performance assessment. This

allows the business analysis team to see how things are going and take

corrective or preventive actions as needed along the way.

135

Exam Essentials

Be able to list the tasks found in the Business Analysis Planning and

Monitoring knowledge area. You will see questions about the tasks, their

associated techniques, their more detailed elements, and the key outputs that

they produce on your exam. You should memorize the six tasks of this

knowledge area and any key outputs or techniques associated with them. The

tasks are:

Plan the business analysis approach.

Plan stakeholder engagement.

Plan business analysis governance.

Plan business analysis information management process.

Identify business analysis performance improvements.

Be able to state the purpose of key deliverables. The good news is that

the key deliverables produced by the tasks in this knowledge area are easy to

remember because they align nicely with the task names. Here’s the list:

Business analysis approach

Stakeholder list, map, or personas

Business analysis stakeholder engagement approach

Business analysis governance approach

Business analysis information management approach

Business analysis performance assessment

Be able to distinguish between predictive and adaptive approaches.

Predictive approaches focus on ensuring that the solution is fully defined before

its implementation begins. Adaptive approaches are a more agile and iterative

effort to define and implement the resulting solution.

Be able to define metrics, indicators, and Key Performance

Indicators (KPIs). A metric is a standard of measurement that is defined

relative to business analysis performance defining a quantifiable level of an

indicator that the business analysis team wants to accomplish. Indicators

identify specific numeric measurements indicating progress toward achieving

something, such as an activity or deliverable. KPIs are indicators that allow the

business analyst or business analysis team to measure performance or progress

of solutions and solution components toward strategic goals or objectives.

Be able to explain the key techniques used to analyze business

analysis stakeholders. Conducting stakeholder analysis uses many

knowledge area specific and general business analysis techniques. The

knowledge area–specific techniques are a RACI matrix and stakeholder lists,

maps, and personas.

136

Key Terms

This chapter stepped through the contents of the first knowledge area from the

BABOK® Guide: Business Analysis Planning and Monitoring. Most of this

knowledge area focuses on planning for the business analysis deliverables,

approaches, and processes that the business analysis team will use throughout

the project life cycle.

You should understand how to apply the techniques and tasks in this knowledge

area in order to be an effective business analyst. Additionally, you will need to

know the five tasks and their associated elements and techniques from this

knowledge area in order to be successful on the CBAP® or CCBA™ exams. The

tasks include:

Plan business analysis approach.

Plan stakeholder engagement approach.

Plan business analysis governance.

Plan business analysis information management.

Identify business analysis performance improvements.

A number of new key words in Chapter 2 relate to managing and monitoring the

business analysis work on a project. Here is a list of some of the key terms that

you encountered in this chapter:

adaptive approaches

business analysis approach

business analysis communication plan

business analysis performance assessment

business case

corrective actions

deliverables

evaluation

governance approach

indicators

information management approach

key performance indicators (KPIs)

metrics

monitoring

onion diagram

predictive approaches

137

preventive actions

project approach

RACI matrix

reports

solution scope

stakeholder engagement approach

stakeholder list, roles, and responsibilities

stakeholder matrix

138

Review Questions

1. You are a business analyst addressing who will receive weekly business

analysis status reports containing performance against actuals for your

current project. You are performing tasks from which knowledge area?

A. Requirements Analysis and Design Definition

B. Business Analysis Planning and Monitoring

C. Requirements Life Cycle Management

D. Solution Evaluation

2. You are a business analyst working on a project where the timing of the

business analysis work is early in the project life cycle. What type of business

analysis approach best fits this project?

A. Predictive

B. Agile

C. Adaptive

D. Iterative

3. What technique might be used when determining the business analysis

approach on a project?

A. Decision analysis

B. Mind mapping

C. RACI matrix

D. Scope modelling

4. Who is responsible for ensuring that the business analysis plan is compatible

with the project plan?

A. Business analyst

B. Project manager

C. Implementation SME

D. Project sponsor

5. What key input is used to plan the business analysis approach for a project?

A. Business need

B. Business case

C. Business goals

D. Strategic plan

6. A RACI matrix describes the roles of stakeholders involved in business

analysis activities. What does RACI stand for?

139

A. Responsible, Accessible, Contacted, Informed

B. Responsible, Accountable, Consulted, Involved

C. Responsible, Accountable, Consulted, Informed

D. Responsible, Accountable, Coordinated, Involved

7. You have an implementation deadline for meeting a specific requirement on

your current project. What requirements attribute indicates how soon a

requirement is needed?

A. Status

B. Priority

C. Urgency

D. Complexity

8. Which statement about conducting stakeholder analysis for the business

analysis activities on a project is false?

A. Done as long as business analysis work continues

B. Conducted during the project phase to which it applies

C. Performed as soon as the business need is identified

D. Determines stakeholder influence and levels of authority

9. All of the following tasks are performed when planning and monitoring

business analysis activities except:

A. Plan business analysis governance.

B. Conduct stakeholder analysis.

C. Plan business analysis approach.

D. Determine solution approach.

10. Which business analysis stakeholder role is involved with all business

analysis activities on a project?

A. Domain SME

B. Implementation SME

C. Business analyst

D. Project manager

11. When identifying business analysis performance improvements, what

technique allows you to determine the metrics used for measuring

performance and determining how those metrics may be tracked?

A. Risk analysis and management

B. Metrics and KPIs

C. Surveys or questionnaires

D. Root cause analysis

140

12. The business analyst has defined how, when, and why the business analysis

team will work directly with project stakeholders to develop requirements.

What deliverable contains this information?

A. Governance approach

B. Stakeholder engagement approach

C. Information management approach

D. Business analysis approach

13. You are currently planning the business analysis information management

approach for your project. What activities will you be performing as part of

this task?

A. Plan traceability, plan reuse, and define decision making.

B. Define requirements attributes, plan traceability, and plan reuse.

C. Decide storage, define requirements attributes, and analyze stakeholders.

D. Plan change control, plan traceability, and decide level of abstraction.

14. What performance measures will the business analyst define for business

analysis activities and deliverables on a project?

A. Variables

B. Metrics

C. Measures

D. Forecasts

15. What business analysis deliverable is a guideline or direct input to all tasks

found in the Business Analysis Planning and Monitoring knowledge area?

A. Business analysis performance assessment

B. Business analysis approach

C. Business analysis governance approach

D. Business analysis information management approach

16. When planning business analysis activities, the business analyst may break

down the project tasks and then estimate the amount of work each task will

require. What technique are they using?

A. Decision analysis

B. Functional decomposition

C. Process modelling

D. Risk analysis

17. At the beginning of Business Analysis Planning and Monitoring activities,

the BABOK® Guide recommends that the business analyst create which two

planning deliverables?

A. Stakeholder Engagement Approach and Governance Approach

141

B. Business Analysis Approach and Stakeholder Engagement Approach

C. Governance Approach and Information Management Approach

D. Information Management Approach and Business Analysis Approach

18. What knowledge area allows the business analyst to define their approach

for tracing project requirements?

A. Requirements Analysis and Design Definition

B. Business Analysis Planning and Monitoring

C. Solution Evaluation

D. Requirements Life Cycle Management

19. All of the following types of requirements may be candidates for reuse on

your project, except:

A. Quality standards

B. Business processes

C. Transition requirements

D. Service level agreements

20. When planning how to address requests for change, the business analyst

should consider the cost and time estimates of the requested change, its

associated benefits and risks, and the:

A. Wording of the change request

B. Assumptions and constraints

C. Recommended course of action

D. Prioritization of the change

142

Chapter 3

Controlled Start: Strategy Analysis

CBAP

/CCBA

™

EXAM TOPICS COVERED IN THIS CHAPTER:

Understand the current state of the business.

Define the desired future state of the business.

Assess the risks inherent to the change.

Develop a change strategy to achieve the desired business

outcome.

To achieve a controlled start to a project or project phase, you

must be methodical and consistent in its planning and definition. The Strategy

Analysis knowledge area provides context for business analysts about the

business need, which reflects the gap between the current business situation and

a future business situation. One essential skill that the business analyst brings to

the big-picture work is knowledge of the internal and external business

environments surrounding the project. This is where experienced business

analysts begin to translate an organization’s business strategy into a proposed

new business solution.

143

Strategy Analysis

Now it is time to add some important context to the business analysis planning

and monitoring tasks discussed in Chapter 2, “Controlled Start: Business

Analysis Planning and Monitoring.” Planning, monitoring, and managing the

implementation of a plan isn’t going to do the team much good if you don’t have

clear goals and expected outcomes. These need to be aligned with the business

need so that everyone on the team knows the goals and expected outcomes. A

controlled project start requires a plan, but it also requires a defined target that

was developed and based upon the way things work today.

To define, design, and deliver a solution that addresses a business need or

opportunity, the team needs to define and agree on the big picture of what needs

to be done and why it needs to be accomplished. This high-level definition of the

business requirements for a project is the essential first step in producing a

successful project outcome. The BABOK

Guide defines the project’s big picture

in the Strategy Analysis knowledge area.

To focus on what is important to business analysts early in their analysis efforts,

let’s consider the tasks of this knowledge area with the framework of the

Business Analysis Core Concept Model (BACCM™). A business analyst needs to

keep an eye on their work at this point in time relative to the six concepts

contained in the framework: changes, needs, solutions, stakeholders, values,

and contexts. Table 3.1 contains a list of the responsibilities associated with each

concept.

TABLE 3.1 The BACCM™: Strategy Analysis

Core

Concept

Business Analyst’s Responsibilities

Change Define the future state and develop a change strategy to achieve

that future state.

Needs Identify and prioritize needs within the current state of the

business to determine the desired future state.

Solution Define the solution scope as part of the change strategy.

Stakeholders Collaborate with stakeholders to understand the business needs

and develop a change strategy and future state to meet those

needs.

Value Examine the potential value of the solution to see whether the

change is justified.

Context Consider the change strategy in the context of the existing

enterprise: stakeholders, processes, technology, and policies.

The Strategy Analysis knowledge area focuses on defining and documenting the

business requirements and solution scope for a project. As part of this effort,

business analysts document the current state of the enterprise relative to the

144

business needs driving a possible change in how things are done. That leads to

the business requirements, which justify why a particular project should be

initiated to address the business need.

Business requirements provide much needed context for detailed requirements

activities that take place later. A business analyst takes a close look at the

organization’s current capabilities relative to a business need, problem, or

opportunity. Once business analysts understand what needs to change, they can

define the desired future state of the business. They then define a feasible

solution scope and approach for addressing that situation.

The tasks in this business-focused knowledge area generate eight key business

analysis deliverables. (You can find a complete listing in the BABOK

Guide.)

We will cover these four significant deliverables in more detail in this chapter:

Business objectives

Business requirements

Change strategy

Solution scope

The Strategy Analysis knowledge area is addressed in Chapter 6 of the BABOK

Guide. The knowledge areas in this book are sequenced within the framework of

a simple life cycle—controlled start, controlled middle, and controlled end. The

Strategy Analysis knowledge area is addressed early in this book because big-

picture tasks and business-requirements-focused deliverables of Strategy

Analysis are key components of the controlled start to most projects.

Some folks view business analysis as a strategic discipline where

business analysts define marketing strategies, build pricing models, and

assess the financial position of a company. People who do not have an

information technology background often hold this strategic view of

business analysis. This differs from the more traditional take on business

analysis similar to the set of knowledge, tasks, and skills we are talking

about in this book. A master’s in business administration (MBA) degree is

typically a prerequisite for the strategic view of the business analyst role.

The BABOK

Guide’s more traditional view of business analysis requires a

business analyst to have an associates or undergraduate degree in almost

any subject. Augmenting this education with a business analysis certificate,

some form of training, or the CBAP®/CCBA™ designation is highly

recommended. However, there is a strategic element as part of the

traditional view of business analysis. We are going to have a look at it right

now because these big-picture activities are found in the Strategy Analysis

knowledge area.

145

The Business Analyst’s Task List

A business analyst has four tasks to perform in the Strategy Analysis knowledge

area. We will look at each of these tasks in greater detail later in this chapter.

The task list from the BABOK® Guide includes the following:

Analyzing the current state of the business

Defining the desired future state of the business

Determining the change strategy and solution scope

Assessing the risks of the selected change strategy

Tasks from the Strategy Analysis knowledge area focus on defining the business

requirements and justifying delivery of the solution scope for the project. A

business analyst is responsible for developing, defining, and managing the roles

and tasks associated with this work. Tasks performed as part of this knowledge

area are governed by the business analysis approach. Business analysis

performance metrics for the tasks and deliverables are also defined and tracked.

We will step through each of these tasks in greater detail.

Exam Spotlight

Approximately 23 of your 150 CBAP

exam questions focus specifically on

Strategy Analysis. On the CCBA™ exam, expect to see about 18 questions on

this knowledge area. The questions are organized and presented using this

list of tasks. It is your job (and ours as well) to make sure you know where

this work is done and how you go about actually doing it.

When Does Strategy Analysis Take Place?

The trick to forgetting the big picture is to look at everything close up.

—Chuck Palahniuk

The tasks in the Strategy Analysis knowledge area take place primarily at the

beginning of a project. Many of these tasks are done as part of pre-project

activities or the basis of a project’s controlled start. The business requirements

created for a project are like the frame on a painting: They frame and control the

desired solution scope and the work efforts required to build the solution. The

solution scope and high-level business requirements may require changes, need

updates, or be enhanced with additional details as each subsequent phase of the

project life cycle is performed.

As previously discussed, the controlled start of a project includes pre-project

activities to determine whether it is a viable and worthwhile project for the

business. At the end of controlled start, the business analysis team should have

the solution scope finalized and a compelling set of business requirements built

146

and approved by the senior management team.

Remember that not all business analysis work is done as part of a

project. Strategy Analysis activities may be performed as pre-project work,

part of a business initiative, or during a project’s initiation or feasibility

phase. Strategy Analysis deliverables may also be refined or revised at any

point in the project life cycle.

Analyze Current State

The business analysis team and key stakeholders must understand and be able

to articulate why a change is needed. According to the BABOK

Guide, the

business need “defines a problem or opportunity of strategic or tactical

importance to be addressed.” The business need driving the change must be

documented and agreed upon. A business analyst must understand the current

state of the enterprise today relative to this proposed change in order to have a

context for the change. Remember, not every project gets started because an

organization is having a problem. Organizations often consider adding new or

changing existing capabilities based on new market opportunities, customer

feedback, newly available technologies, or changing legal and regulatory

requirements.

Setting a baseline and a context for a change involves looking at the business

drivers and issues to determine whether a change is really necessary. The

business analyst becomes the master investigator, questioning the business

need and any assumptions to make sure that the underlying problem or

opportunity relative to the business need is understood and being properly

addressed.

Understanding the current state of the business starts the team and its key

stakeholders down the path of fully understanding a business problem or

opportunity. Organizations need to stay targeted on the business needs versus

reacting too quickly to problems, issues, or perceived inefficiencies. The current

state definition sets the stage for what comes next in the early part of a project,

including deciding on the following:

The range of solution options to consider

The set of stakeholders to involve

The appropriate solution approaches to evaluate

After the business need and the current state of the business relative to that

need are articulated for a project or initiative, they are not expected to change

significantly through that project’s life cycle. If the business need for a project

does change during that project’s life cycle, the business analyst will have to go

back to validate all of the high-level planning and definition work to make sure

everything is still okay.

147

Exam Spotlight

According to the BABOK® Guide, new business needs can be identified at

many levels of the enterprise. The four typical sources are:

Top down: To achieve a strategic goal

Bottom up: To address a current process, function, or system

Middle management: To make better decisions or perform additional

functions to meet business objectives

External drivers: To meet customer demand or business/market

competition

Figure 3.1 summarizes the inputs, outputs, guidelines, tools, techniques, and

associated tasks for analyzing the current state of the business relative to a

problem or an opportunity.

FIGURE 3.1 Task summary: Analyze current state.

148

Inputs either are informational in nature or can be outputs produced by other

business analysis tasks. Inputs are acted on by the task elements and

techniques, producing one or more task outputs. Let’s take a look at the task

inputs used when analyzing the current state:

Needs Problems or opportunities must be understood as part of analyzing the

current state of the enterprise relative to a potential change in how things are

currently done.

Elicitation Results (confirmed) Elicitation results help key stakeholders to

define and understand the current state of the enterprise relative to the business

need. Elicitation information is informally confirmed to identify and resolve any

problems with the information before it is used in some way. Confirmed

elicitation results should contain no errors, omissions, conflicts, or ambiguity

relative to other information that has been gathered or is known.

Guidelines and tools also may be inputs used by business analysis tasks.

Guidelines are instructions or descriptions of why and how a business analyst

will undertake a task. Tools, on the other hand, are methods for conducting a

business analysis task or shaping a task output. Let’s take a look at the

guidelines and tools that may be used as inputs when analyzing the current

state:

Business Analysis Approach The business analyst’s approach to analyzing

the current state of the enterprise is defined and guided by the business analysis

approach. Every time a business analyst tackles a task, they need to think about

how they will go about getting that work done. Using your organization’s

business analysis approach to performing this work can be helpful and keep you

on track. The approach can be as simple as a series of steps to produce a

deliverable or as complex as a detailed plan for gathering information and

creating a project deliverable.

Enterprise Limitation Challenges, such as the lack of resources or

knowledge/skill gaps, can exist within the enterprise relative to the business

need and the potential change. These limitations can impact the resulting

requirements and solution and must be identified and addressed.

Organizational Strategy Organizations usually have a set of business goals

and business objectives. Some of them are found in the statements of mission,

vision, and values, outlining what the organization wants to achieve and how

they see themselves doing it. A determination of how and why addressing the

problem or opportunity furthers these goals and objectives can be critical to

success.

Solution Limitation Understanding the current state means being aware of

the limits and challenges that may be present in an existing solution. Changes to

the existing solution may impact or be impacted by the existing solution, its

capabilities, and its infrastructure.

Solution Performance Goals Most organizations measure the current

performance of the enterprise and its solutions, particularly IT solutions. These

measures of existing solution performance are the baseline for setting the

desired future state goals and improvements. These goals reflect

149

enterprise/solution and baselining.

Solution Performance Measures While solution performance goals are

more focused on establishing a baseline for enterprise/solution performance,

solution performance measures describe the actual performance of existing

solutions in the enterprise. Analysts can then compare the actual to the baseline

to assess change. The measures only focus on the actual state of solutions.

Stakeholder Analysis Results Identifying the business need is the first step

in defining a project’s business requirements. As part of their identification

efforts, business analysts must elicit information from key stakeholders about

their high-level needs and knowledge of the current state.

TABLE 3.2 summarizes the inputs to this task and also lists the particular task

that was the source of the input (if applicable).

Table 3.2 Inputs, Guidelines, and Tools: Analyze current state.

Task Input Input

Type

Input Source Source Knowledge

Area

Needs Input Define business

needs.

Strategy Analysis

Elicitation results

(confirmed)

Input Confirmed

elicitation results

Elicitation and

Collaboration

Business analysis

approach

Guidelines

and tools

Plan business

analysis approach.

Business Analysis

Planning and Monitoring

Enterprise

limitation

Guidelines

and tools

Assess enterprise

limitations.

Solution Evaluation

Organizational

strategy

Guidelines

and tools

Solution

limitation

Guidelines

and tools

Assess solution

limitations.

Solution Evaluation

Solution

performance goals

Guidelines

and tools

Solution

performance

measures

Guidelines

and tools

Measure solution

performance.

Solution Evaluation

Stakeholder

analysis results

Guidelines

and tools

Business analysts need to step through several elements to analyze, understand,

and document the current state of the business. The elements necessary to

analyze the current state are as follows:

Business needs

Organizational structure and culture

Capabilities and processes

150

Technology and infrastructure

Policies

Business architecture

Internal assets

External influencers

Let’s step through each of the elements involved in analyzing the current state of

the enterprise relative to a problem or opportunity.

Business Needs Business needs consist of problems and opportunities, such

as customer complaints or the emergence of a new market. They are identified

at every level of the enterprise and drive the enterprise to define and pursue a

solution to satisfy that need. Remember to express business needs from the

enterprise’s point of view versus being too stakeholder specific to eliminate bias.

A business analyst must investigate the business problem or opportunity to

ensure that there is a good reason to move forward and address the problem or

opportunity. You are looking for a way to improve the business and add value.

Consider several factors when performing this work:

Quantify any adverse impacts.

Define any expected benefits from the proposed solution.

Estimate a timeframe for addressing the problem or opportunity.

Look at the “do nothing” option as an alternative approach.

Identify the underlying cause of the problem.

Organizational Structure and Culture Part of assessing the current state is

performing a cultural assessment of the organization. The BABOK® Guide

defines organizational culture as “the beliefs, values, and norms shared by the

members of an organization. These beliefs drive the actions taken by [that]

organization.” Communications channels and working relationships are

influenced by the organization’s structure and culture and should be accounted

for as part of analyzing the current state.

Capabilities and Processes When defining the current state, be sure to look

at the activities the enterprise performs. Core capabilities or processes describe

the essential functions of the enterprise that differentiate it from other

enterprises. The current state description should define the current capabilities

and processes of an organization relative to a business need. This description

looks at the organization’s business processes, software, hardware, people,

operations, and current projects. Activities and processes are measured by

performance indicators that will help business analysts assess the benefits

associated with a proposed change.

Business analysts can take a capability-centric view of the enterprise in their

current state description. This perspective looks at innovative ways to combine

existing capabilities and produce new outcomes. The capabilities being assessed

are organized in functional hierarchies that relate them to other capabilities. On

the flip side, business analysts may choose to take a process-centric view of the

151

enterprise, looking for ways to improve the performance of existing activities.

Processes are typically organized in a different way than capabilities, flowing in

an end-to-end fashion across the enterprise.

Technology and Infrastructure Technology is composed of information

systems that support people as they do their work, communicate with others,

and make decisions. Infrastructure is part of the enterprise environment,

consisting of physical components and capabilities, such as computer hardware

or operating a manufacturing plant.

Policies Day-to-day decision making in an enterprise is defined by policies at

different organizational levels. Any policies that may have an impact on the

change being proposed need to be identified and understood.

Business Architecture The current state of an enterprise relative to a

business need does not exist in a vacuum. Be sure to consider the business

architecture when thinking about making a change. Business architecture is the

design, structure, and behavior of every aspect of the enterprise. This view of

how things are currently working helps the business analyst align strategic

objectives with tactical demands and possible changes downstream.

Internal Assets Assets are the tangible and intangible parts of the current

state description. They include financial resources, patents, reputation, and

brand names.

External Influencers External influences add constraints, dependencies, or

drivers to the description and understanding of the current state of things.

There are many sources of external influences on an enterprise, including

industry structure, competitors, customers, suppliers, the political and

regulatory environment, technology, and macroeconomic factors such as

unemployment or inflation.

There are a number of techniques that you may choose to apply when analyzing

the current state of the enterprise. To make sure you consider a range of

business needs and desired outcomes before settling on what is driving your

potential project, we recommend that you use the document analysis and the

root-cause analysis techniques. Let’s take a look at these two techniques in

greater detail.

Recommended Technique: Document Analysis

Document analysis allows a business analyst to elicit, confirm, or crosscheck

project requirements information by studying existing documentation and other

relevant information. These secondary sources of information allow the

business analyst to gather details for existing solutions (the “as is” situation) to

see whether they have components that can be used or should be changed for

the new solution that is being proposed (the “to be” situation).

Document analysis assumes that the existing documentation is easily available

and up-to-date. If the information is not up-to-date and valid, it will be of little

help to a business analyst in eliciting or confirming the requirements. The

“existing stuff” is information prepared for another project or purpose but

152

relevant to your requirements development efforts. This type of secondary data

can be quite helpful during requirements elicitation.

To conduct document analysis, the business analyst steps through three stages:

preparation, the actual document review, and wrap-up. Preparation involves

locating and evaluating the relevant system and business documentation.

During document review, you study the material, identify the relevant details

(technical and business), and document them along with any questions you

might have to follow up on with the subject matter experts (SMEs). Wrap-up is

the “get answers, review, and confirm” step.

Secondary Information Sources Checklist

Here is the checklist of secondary information sources that we use as a

reminder when performing document analysis work or even just basic

research about something. This existing stuff may include the following:

Project and system documentation

Corporate-level documents

Annual reports, strategic plans

Books and other publications

Information out on the company intranet

The company website

Websites of competitors

Organization charts, seating diagrams, phone lists

White papers

Technical standards and guidelines

Informal and casual sources

Internet research

Competitor demos and evaluations

Benchmarking studies

Trade journals

Issue registers

Quality registers

Demographic surveys

User guides

Market research information

Change requests

153

Problem reports

Help desk reports

Help desk logs

Newsletters

Meeting minutes

Information about related projects

Recommended Technique: Root-Cause Analysis

Business analysts perform root-case analysis to determine the underlying

source of a problem. This structured technique is used to examine a situation in

order to establish the root causes and resulting effects of a particular problem.

The BABOK

Guide recommends two common methods for root-cause

analysis: the fishbone diagram and the five whys.

Fishbone Diagram A fishbone diagram allows the business analyst to show

the causes of a problem or an effect. Fishbone diagrams are also called Ishikawa

or cause-and-effect diagrams. This diagram allows the business analyst to see all

possible causes of a result in a structured way and to make sure that everyone

understands the problem or cause that is being addressed.

The business analyst and key stakeholders will brainstorm the categories and

the possible causes in each category. Typical categories include things like

people, methods, machines, materials, measurements, and environment. After

the diagram is built, the business analyst will analyze the results and (hopefully)

determine the actual cause of what is taking place.

This fishbone example looks at the possible causes for a specific effect:

decreased wine sales revenue. The possible causes are diagrammed and broken

down across four areas: people and skills, systems, distributors, and

surroundings. A fishbone diagram, like the one shown in Figure 3.2, offers the

team the opportunity to analyze and discuss what they think is leading to this

decrease in revenue.

154

FIGURE 3.2 A fishbone diagram offers the opportunity to analyze and discuss.

Five Whys The five whys is a questioning technique that asks, “Why?”

repeatedly in order to get to the root cause of a problem. This technique can be

used alone or used with the fishbone diagram technique. This is a simple and

effective facilitation tool. Many business analysts customize their use of this tool

by asking, “How?” instead of “Why?” or by alternating between the two terms.

Often the root cause is identified before the five questions are asked.

Be careful when you use this technique. We were in a meeting once where the

facilitator really annoyed the senior user by repeatedly asking, “Why?” in order

to determine whether automating an existing process would improve customer

service. The senior user ended up throwing a powdered-sugar doughnut at the

facilitator, making a big white spot right on the front of the facilitator’s black

suit jacket.

Additional Techniques to Consider

The BABOK

Guide lists some additional techniques that can be used when

analyzing the current state for your project. They are summarized for you here:

Benchmarking and Market Analysis Benchmarking is done to compare

organizational practices against the best-in-class practices from competitors,

the government, or industry associations. Market analysis researches customers

to determine what those customers need or want. Both techniques allow you to

identify opportunities for improvement in the current state.

Business Capability Analysis This technique allows a business analyst to

define the current business capabilities of the enterprise, identify performance

gaps, and prioritize those gaps and capabilities relative to the value and risk of a

business need.

Business Model Canvas A business model canvas describes how an

enterprise creates, delivers, and captures value to and from its customers. This

technique provides an understanding of the value proposition between the

enterprise and its customers as well as the critical factors in delivering that

value and the resulting cost and revenue streams.

Business Cases Many organizations use business cases to justify a course of

action based upon the benefits of a proposed solution. When analyzing the

current state, be sure to capture information regarding the business need and

the opportunity that need presents to the enterprise.

Concept Modelling Business analysts need to capture and organize the key

terms and concepts to build a “business vocabulary” or glossary for people to

use when discussing the current state and the proposed change.

Data Mining Data mining looks for useful patterns and insights in enterprise

data, such as information on the performance of the enterprise. This can

improve the decision-making process relative to a business need.

Financial Analysis Financial analysis is used to understand the profitability

of the current state and to evaluate the enterprise’s financial capability to deliver

155

change.

Focus Groups This group technique allows a business analyst to bring

together a selected group of key stakeholders to identify and discuss problems

and opportunities as part of analyzing the current state.

Functional Decomposition Functional decomposition allows a business

analyst to break down the complex systems and relationships that make up the

current state into smaller, easily understood pieces and parts.

Interviews It is essential that the business analysts talk with stakeholders to

understand the current state and any stakeholder needs relative to that current

state.

Item Tracking This technique allows issue tracking and management relative

to the description of the enterprise’s current state. We often refer to this key

technique as “issue management” on our projects.

Lessons Learned Looking at failures and opportunities from past change

initiatives can assist with facilitating a proposed change. Lessons learned may

also highlight and drive a new business need for process improvement in one or

more areas.

Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are

used to assess the performance of the current state of the enterprise. Be sure to

look for measurable ways to assess performance.

Remember, KPIs are indicators that allow a business analyst to

measure performance or progress of solutions and solution components

toward strategic goals or objectives. Metrics are quantifiable levels of an

indicator measured at a particular point in time.

Mind Mapping Mind mapping is a creative way of note taking that captures

ideas and information in a visual and nonlinear way relative to the current state.

This technique is used to explore relevant aspects of the current state and to

understand the factors affecting the business need.

Observation Observation allows a business analyst to gain insight into needs

by viewing how things are done within the current state. Often, observation also

helps business analysts discover new stakeholder and business needs based

upon what they observe.

Organizational Modelling Remember those hierarchical organization charts

with the rectangles and the lines connecting each level of job title? When

analyzing the current state, many business analysts use this technique to

describe the roles, responsibilities, and reporting structures that currently exist

within the organization.

Process Analysis Process analysis identifies opportunities to improve the

current state by looking at the efficiency and effectiveness of a particular process

156

that is part of the current state.

Process Modelling This graphical modelling technique describes how work

occurs in the current state and the current solution.

Risk Analysis and Management Risk analysis and management identifies

areas of risk or uncertainty that could negatively impact the current state. This

technique also analyzes and evaluates those uncertainties to develop responses

to deal with the risks.

Scope Modelling Ever been asked what is in scope and what is out of scope

for your project? Scope models are used to define the boundaries of the current

state description.

Survey or Questionnaire This elicitation technique helps business analysts

gain an understanding of the current state from a large, varied, or disparate

group of stakeholders in a relatively short period of time.

SWOT Analysis This tool evaluates the strengths, weaknesses, opportunities,

and threats to the current state enterprise.

Vendor Assessment This technique determines whether vendors that are

part of the current state are adequately meeting their commitments or whether

changes are needed.

Workshops Workshops help engage key stakeholders as they collaboratively

describe the current state and their current or future needs relative to that state.

Business analysts select the techniques they will apply as part of analyzing the

current state. There is no need to use all of these techniques, so choose wisely.

Let’s take a look at the outputs that result from applying your selected

techniques to this task.

Analyzing the Current State

There are two related outputs from this task: the current state description and

the business requirements. The current state description provides the context

for the enterprise’s existing scope, capabilities, resources, performance, culture

dependencies, infrastructure, external influences, and significant relationships

between these elements.

The business requirements define the problem, opportunity, or constraint

defined based upon understanding the definition and inner workings of the

current state. The business requirements include the business need, describing

the problem or opportunity that an organization is facing. The business

requirements and the current state description drive the start of your project.

Table 3.3 summarizes the output from the Analyze Current State task.

TABLE 3.3 Outputs: Analyze current state.

Task Output Output Destinations Source Knowledge Area

Current state

description

Plan stakeholder engagement. Business Analysis Planning

and Monitoring

Plan business analysis Business Analysis Planning

157

governance. and Monitoring

Define future state. Strategy Analysis

Assess risks. Strategy Analysis

Define change strategy. Strategy Analysis

Analyze potential value and

recommend solution.

Requirements Analysis and

Design Definition

Assess enterprise limitations. Solution Evaluation

Recommend actions to increase

solution value.

Solution Evaluation

Business

requirements

Define future state. Strategy Analysis

Case Study: Palmer Divide Vineyards—Business Goals, Objectives, and

Need

As you become more involved with your Palmer Divide Vineyards work, you

decide that you need to take a quick look at the organization’s existing

business goals, objectives, and needs as part of your current state analysis.

As discussed in a recent team meeting, you would like to make sure you

have it right. The team is curious about how the green initiative and your IT

requirements development part of it fit into the organization’s strategic

plan. The team likes the idea of becoming a certified Green Business.

However, they would like to validate how this business goal fits with the

organization’s long-term strategy and make sure that the project is really

worth doing.

There are many aspects to attaining green certification, and the winery has

initiated this current project to help achieve this strategic goal. A business

objective for this effort is to conserve 20 percent of the current energy and

water resource consumption within the next 18 months. The business need

triggering the project came from combining the owner’s strategic plans, a

desire to operate an organic winery, and a perceived market advantage from

selling green-labeled organic wines to the public.

Once the current state is identified, understood, and documented, it is used as

an input or guideline by many other business analysis tasks. They include

conducting stakeholder analysis, assessing risks, and analyzing the potential

value of taking action. Additionally, the remaining three Strategy Analysis tasks

require the current state as an input or guideline for performing their big-

picture activities and completing the high-level definition of the project.

158

A number of stakeholders are involved with identifying and analyzing business

needs within an organization. Typically, the business analyst is responsible for

identifying and investigating the need. It is a best practice to appoint a sponsor

who owns the business need and authorizes the actions to make sure that need

is met. Often this is done by the project that was triggered as a result of the

business need being identified and addressed.

Domain SMEs and end users can provide the business analyst with an excellent

source of existing problems or limitations with systems and processes. Other

key stakeholders involved with analyzing the current state of the enterprise

relative to the business need include the following:

Customer

Implementation SME

Operational support

Project manager

Regulator

Supplier

Tester

The business requirements and current state description guide the

identification, definition, and selection of new capabilities, possible solutions,

and solution approaches. Remember that the business need is typically

contained in the business requirements created as an output from this task.

Using the business requirements and current state description, you will now

move to the next task and define the desired future state that meets the business

need.

Define Future State

After the business analyst analyzes and understands the current state of the

enterprise relative to the business need, the next step is to define the new

capabilities required to address that business need. You must determine

whether the organization’s existing capabilities can meet the business need or

whether additional capabilities and conditions are necessary. Typically, projects

begin when organizations have to add new capabilities to the mix in order to

meet a business need.

Defining the future state allows the stakeholders to understand the potential

value of a range of solution options. This leads to making an informed decision

and selecting the best possible solution as part of the change strategy. We will

look at the change strategy in more detail later in this chapter. According to the

BABOK® Guide, the future state is defined to a level of detail that:

Allows for competing strategies to be identified and assessed

Provides clear definition of outcomes satisfying the business need

Details the scope of the solution space

159

Allows for value associated with the future state to be assessed

Enables consensus to be achieved among key stakeholders

Figure 3.3 summarizes the inputs, outputs, techniques, and associated tasks for

defining the future state at the appropriate level of detail relative to the business

need within an organization.

FIGURE 3.3 Task summary: Define future state.

Remember, the desired future state meets the business need. Let’s take a look at

the task inputs, guidelines, and tools used to assist the business analyst in

defining the future state. There is a single input to this task.

Business Requirements The business requirements are the basis for

defining the future state. Business requirements define the problems,

opportunities, or constraints that need to be addressed by the solution scope.

The business analyst is focused on what it will take to deliver the business

requirements, either by using existing capabilities or by creating new

capabilities.

Several guidelines and tools are also to be used as inputs when defining the

future state. They include the following:

Constraints Constraints may exist within the enterprise that limit or change

your solution options as part of the future state definition. The BABOK

Guide

includes them as considerations in the 6.2.3 model but does not specify

constraints in the list found in 6.2.5. We believe they are an important

160

consideration for any project.

Current State Description The current state description defines the current

capabilities of an organization relative to a business need. The description may

look at the organization’s business processes, software, hardware, people,

operations, and current projects. This is the first place you look to understand

the organization’s current capabilities relative to the business need being

addressed and the desired future state to be defined.

Metrics and KPIs When defining the future state, key performance indicators

and metrics must be considered. This allows you to determine whether the

future state has been achieved when the solution is implemented.

Organizational Strategy This strategy defines the path, method, or approach

the organization will take to achieve the desired future state. This strategy may

impact the solution that is chosen for implementation.

Table 3.4 summarizes the inputs to this task and also lists the particular task

that was the source of the input (if applicable).

TABLE 3.4 Inputs: Define future state.

Task Input Input Type Input Source Source Knowledge

Area

Business

requirements

Input Identify business

need.

Strategy Analysis

Constraints* Guidelines and

tools

Current state

description

Guidelines and

tools

Analyze current

state.

Strategy Analysis

Metrics and KPIs Guidelines and

tools

Organizational

Strategy

Guidelines and

tools

The BABOK® Guide includes constraints as considerations in the 6.2.3 model but does not specify

them in the list found in 6.2.5. We believe they are an important consideration for any project.

To define the future state, you need to address and define a number of detailed

elements within the task. Those elements are:

Business goals and objectives

Scope of solution space

Constraints

Organizational structure and culture

Capabilities and processes

Technology and infrastructure

Policies

161

Business architecture

Internal assets

Assumptions

Potential value

The future state definition typically includes new, removed, and

modified components of the enterprise. This definition may also include

changes to organizational boundaries. Changes found in a future state

description may impact the following enterprise components:

Business processes

Functions

Lines of business

Organizational structure

Staff competencies

Knowledge and skills

Training

Facilities

Desktop tools

Organization locations

Data and information

Applications systems

Technology infrastructure

Let’s step through each of the 11 elements involved in defining an organization’s

future state relative to a specific business need. Many of these elements are the

same things you are analyzing when developing a description of the current

state of affairs relative to the business need. The business analyst will compare

the current state to the future state in order to see what actually needs to be

done.

Business Goals and Objectives Early in a project or before a project even

begins, business analysts are asked to analyze the organization’s business goals

and objectives as part of defining a particular business need and the desired

future state. This strategic information is usually located in the organization’s

strategic plan, starting with the organization’s mission, vision, and values.

Many people mistake the vision statement for the mission statement.

162

Vision The vision describes a future identity.

Mission The mission describes why that future identity will be achieved.

Values Values provide boundaries for how an organization defines its

mission in order to achieve its vision.

Figure 3.4 depicts the levels of detail and the relationships ranging from an

organization’s vision, mission, and strategic plan to the projects being done in

order to achieve those strategic goals.

FIGURE 3.4 Relating strategy and implementation

Business goals are strategic statements describing changes that the organization

seeks to establish or current conditions that the organization wants to maintain.

A single business goal may be subdivided into one or more focus areas, such as

customer satisfaction, operational excellence, or business growth.

Business goals must be decomposed into a set of more quantitative business

objectives. Business objectives state the predetermined results toward which

effort is directed, such as a strategic position to be attained or a purpose to be

achieved. Experienced business analysts make sure that their business

objectives are SMART (Specific, Measurable, Achievable, Relevant, and Time-

Bound).

Exam Spotlight

Let’s take a closer look at each of these SMART criteria for business

objectives. Make sure you are comfortable with these definitions as part of

your exam preparation.

Specific A business objective is specific if it has an observable outcome.

Specific objectives allow an organization to ascertain that particular

business objectives have actually been met.

Measurable Quantifiable business objectives have measures that are used

163

to track and measure their observable outcomes. Remember, if you can’t

measure something, it can’t be verified.

Achievable Business objectives must also be feasible. This is true relative

to their cost, complexity, implementation, and ongoing support.

Relevant All business goals and objectives must align to the organization’s

mission, vision, and values. Otherwise, there is no need to pursue them.

Time-Bound Each business objective should have a defined timeframe for

achieving that objective. Business analysts should ensure that the timeframe

is consistent with the business need.

Scope of Solution Space The business analyst must also describe the range

of solutions and the options that will be considered to achieve the desired future

state. The target is reaching a desired outcome that delivers the most value and

can be implemented to address the business need. Do not confuse the desired

outcome with a solution; they are not the same thing. Solution options to

achieve the future state will be evaluated relative to the desired outcome to

make sure they can deliver the business benefits that are expected.

Constraints Constraints limit the current state as well as the planned future

state. Constraints may not change as part of the solution. Constraints come in

many flavors, such as budget, time, technology, infrastructure, policy, resources,

team member skills, and regulations.

Organizational Structure and Culture When assessing the future state,

remember to do a cultural assessment of the organization relative to the changes

in formal and informal working relationships that may occur. Communications

channels and working relationships are influenced by the organization’s

structure and culture and should be accounted for as part of analyzing both the

current and future states of the enterprise during strategy analysis.

Capabilities and Processes Once you have a handle on the current

capabilities, it’s time to consider the new capabilities that may be needed to

meet the business need. The business analyst is responsible for modelling and

describing these new capabilities. One common way to do this is called gap

analysis: defining what it will take to eliminate or minimize the gap between the

current capabilities and the desired future state.

Technology and Infrastructure The question you must answer is, “Does the

organization have the current business and technology capabilities to meet the

business need?” You will look at specific parts of the current technology and

infrastructure that relate to the business need. Existing technology may impose

technological constraints on solution design. If you miss something, your view

of the organization’s current technical capabilities may be incorrect and

incomplete. That will require you to spend extra time doing the research to

discover what you need to know.

Policies Day-to-day decision making in an enterprise is defined by policies at

different organizational levels. These policies might need to change as part of

the desired future state. Policies also have a bad habit of constraining the

solution space for the future state, so stay alert for these possible issues and

164

roadblocks.

Business Architecture Business architecture is the design, structure, and

behavior of every aspect of the enterprise. The future state of an enterprise does

not exist in a vacuum; all these elements work together to meet (or obstruct)

business goals and objectives. This view of how things will work together in the

future helps business analysts align strategic objectives with tactical demands

and possible changes downstream.

Internal Assets Assets are tangible and intangible parts of the future state

description. The future state may require new assets or more capabilities from

existing assets.

Identify Assumptions You will have to make assumptions to define new

capabilities for the future state. Assumptions are things that are believed to be

true regarding meeting the business need. Make sure that you clearly

understand any assumptions associated with the new capabilities. Identify and

document each assumption, just in case you discover later that one or more of

them are actually false.

Potential Value There is no reason to transition to a future state if no value is

added to the enterprise as a result of the change. For the purpose of comparison,

the value should be compared to the “do nothing” option. The BABOK

Guide

defines the potential value of the future state as “the net benefit of the solution

after operating costs are accounted for.” Potential value is a key component of

the business case justifying the proposed change.

There are a number of techniques that you can use when assessing your

organization’s current capabilities relative to a new business need. You can

almost always use benchmarking and market analysis or SWOT analysis to help

you define the future state of things. Let’s take a look at those recommended

techniques now.

Recommended Technique: Benchmarking and Market Analysis

Benchmarking and market analysis studies target using new and different

methods, ideas, and tools to improve organizational performance. When

conducting such a study, the business analyst compares their organization’s

strategies, operations, and processes against the best-in-class strategies,

operations, and processes of their competitors and peers. After determining how

other companies achieve superior performance, the organization can then

propose projects to reproduce solutions that work elsewhere.

Recommended Technique: SWOT Analysis

Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis lets you

look at the organization’s current capabilities relative to meeting a new business

need. There are two dimensions to this analysis: the internal strengths and

weaknesses of the organization and the external opportunities and negative

threats that are in play. SWOT analysis is done using a matrix or a grid.

Stakeholders brainstorm and complete each quadrant of the grid and then

165

analyze the resulting data to make sure that the business need and its

environment are well understood. Solutions for meeting the business need may

then be proposed and considered.

Additional Techniques to Consider

The BABOK

Guide lists (and provides a more in-depth discussion of) some

additional techniques that may be used when defining the future state for your

project. They are summarized for you here.

Acceptance and Evaluation Criteria Identify what may make the future

state acceptable and how solutions options may be evaluated.

Balanced Scorecard This strategic planning and management tool is used to

set targets for measuring the organizational performance in the future state.

Balanced scorecards are outcome focused and provide a balanced view of the

enterprise by looking at four dimensions: learning and growth, business

process, customer, and financial.

Brainstorming Brainstorming is a creative way to collaboratively come up

with ideas for what the future state might be. Participants generate new ideas

and reduce those ideas into a smaller subset for subsequent analysis.

Business Capability Analysis The business analyst defines the future

business capabilities of the enterprise as part of the future state. Capability

performance gaps are prioritized relative to value and risk.

Business Cases A business case should capture the desired outcomes of the

change initiative and clearly define the desired future state.

Business Model Canvas This technique maps out the needed infrastructure,

target customer base, financial cost structure, and revenue streams required to

fulfill the value proposition to customers in the desired future state.

Decision Analysis Decision analysis is a formal way to examine and model

the possible consequences of different decisions being made in response to a

problem. During future state definition, it is used to compare the different

future state options and understand what the best choice might be.

Decision Modelling This technique is used to model complex decisions

regarding future state options. Decision models can use tables or trees to show

how data and knowledge are combined to make a specific decision.

Financial Analysis When defining the future state, financial analysis is used

to estimate potential financial returns to be delivered by that proposed future

state.

Functional Decomposition Functional decomposition allows the business

analyst to break down the complex systems and relationships that will make up

the desired future state into smaller, easily understood pieces and parts.

Interviews During future state definition, a business analyst speaks with key

stakeholders in order to understand their needs and objectives relative to the

future state.

166

Lessons Learned Lessons learned can assist business analysts in determining

which opportunities for improvement will be addressed as part of the future

state and how to improve upon the current state.

Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are

used to assess the performance of the future state of the enterprise. This

technique can help business analysts determine when the organization has

achieved the business objectives linked to the future state.

Mind Mapping Mind mapping is a creative way to develop future-state ideas

using a visual, nonlinear diagram that maps the relationships between ideas.

Organizational Modelling Organizational models are used to describe the

roles, responsibilities, and reporting structure that could exist in the future state

organization.

Process Modelling This graphical modelling technique describes how work

would occur in the future state.

Prototyping Prototypes model requirements for one or more future state

options and help users and other stakeholders determine the potential value and

feasibility of each option.

Scope Modelling Scope models define the boundaries of the enterprise in the

future state. Plan ahead and model the current state, too. Then it is an easy

comparison between where the enterprise is now and where the enterprise

wants to be relative to the business need.

Survey or Questionnaire Surveys or questionnaires allow a business analyst

to understand stakeholder needs and related business objectives that are part of

the future state. This elicitation technique is effective with a large, varied, or

disparate group of stakeholders over a relatively short period of time.

Vendor Assessment This technique assesses the potential value provided by

vendor solution options relative to the desired future state.

Workshops Workshops help engage key stakeholders as they collaboratively

describe the future state of the enterprise and their needs.

Let’s take a look at the outputs result from applying one or more of these

techniques to this task or defining the future state.

Defining the Future State

There are three outputs from this task: the business objectives, the future state

description, and the potential value. The three outputs are tightly intertwined.

The business objectives state the desired direction required for the business to

achieve the future state. The future state description defines the new, removed,

and modified components of the enterprise, and the potential value expected

from the future state.

Once the business objectives, future state, and the future state’s potential value

are identified, understood, and documented, they are used as inputs by several

other business analysis tasks. These tasks are listed in Table 3.5. They have a

strong solution focus, and they are integral pieces for defining the solution

167

approach and scope.

TABLE 3.5 Outputs: Define future state.

Task Output Output Destinations Source Knowledge Area

Business

objectives

Prepare for elicitation. Elicitation and Collaboration

Manage stakeholder

collaboration.

Elicitation and Collaboration

Assess risks. Strategy Analysis

Validate requirements. Requirements Analysis and

Design Definition

Analyze potential value and

recommend solution.

Requirements Analysis and

Design Definition

Measure solution performance. Solution Evaluation

Assess enterprise limitations. Solution Evaluation

Recommend actions to increase

solution value.

Solution Evaluation

Future state

description

Manage stakeholder

collaboration.

Elicitation and Collaboration

Assess risks. Strategy Analysis

Define change strategy. Strategy Analysis

Validate requirements. Requirements Analysis and

Design Definition

Define design options. Requirements Analysis and

Design Definition

Analyze potential value and

recommend solution.

Requirements Analysis and

Design Definition

Measure solution performance. Solution Evaluation

Analyze performance measures. Solution Evaluation

Assess enterprise limitations. Solution Evaluation

Potential value Prepare for elicitation. Elicitation and Collaboration

Assess risks. Strategy Analysis

Validate requirements. Requirements Analysis and

Design Definition

Analyze potential value and

recommend solution.

Requirements Analysis and

Design Definition

Analyze performance measures. Solution Evaluation

A number of stakeholders are involved with defining the future state relative to

a particular business need and to the current state of the enterprise. Business

168

analysts usually drive this work. It is a best practice to appoint a sponsor who

owns the business need and authorizes the actions to make sure that need is

met. Often this is done by the project that was triggered as a result of the

business need being identified and addressed.

Customers and suppliers may be significantly impacted when a new future state

is defined and targeted to meet a business need. Other key stakeholders who

provide information about the strengths and weaknesses of the current

capabilities include the following:

Domain SME

End user

Implementation SME

Operational support

Project manager

Regulator

Tester

You can use the current and future state descriptions to identify, prioritize, and

select the solution approach for implementing or obtaining the required

capabilities. This will be set forth as part of the change strategy and discussed

later in this chapter.

Case Study: The Boulder Barn Project

Here is an example of analyzing and documenting current and future

capabilities for acquiring property and building a new barn for an equine-

assisted learning facility in Colorado.

Overview

Equine-assisted learning is a rapidly growing field. Melisa Pearce, a lifelong

horsewoman, psychotherapist, and entrepreneur, focuses on providing

experiential horse interaction, coaching, and guidance to a wide variety of

private and business clients. Melisa works with clients and horses at her

ranch in an integrative approach consisting of ground-based horse

interaction combined with positive coaching and guidance.

Melisa’s leadership training curriculum is a unique, experiential program

where participants work with horse partners. Horses possess their own

personalities, behaviors, and attitudes and can therefore provide

participants with immediate feedback on their ability to affect actions or

change. By creating a partnering relationship with these animals to

169

complete specific tasks, participants learn about compromising, goal

setting, overcoming fears, effective communication, in-process adjustments,

effective teamwork, and how to act synergistically in order to create

mutually beneficial, outcome-based relationships. The significant learning

moments are applicable and transferable to both professional and personal

life.

Existing Situation and Desired Future State

Five years ago, Melisa and her family moved to her current location in

Boulder County, Colorado. She scaled down her property from a 50-acre

ranch to 5 acres of property with an existing home. At the new location,

Melisa built a covered arena, attached barn, and retail store space to meet

her business needs and the needs of her horses and other ranch animals.

While her current location is adequate, Melisa would like to expand. She

would like a larger barn with more arena space. Ideally, Melisa would like to

sell her current ranch and purchase property in the same general area with

approximately 35 acres of land. Most properties of this type would already

have an existing home in place. Melisa would then build the following:

Office space

Barn with attached covered arena (35 feet longer and 70 feet wider than

the current facility)

Retail space with an upstairs observation and training room

Since Melisa has designed and built several ranch facilities in the past, this

project will apply the plan-driven approach. She is very clear about the

elements and materials intended for the new property, and the solution will

be fully defined before implementation begins.

Assess Risks

During Strategy Analysis, the business analyst analyzes and manages the risks

relative to the current state, the future state, and the change strategy. According

to the BABOK

Guide, the risks are analyzed in a basic way with which most of

us are familiar. The business analyst looks at the possible consequences if the

negative risk occurs, the impact of the consequences, the actual likelihood of the

risk occurring, and the potential timeframe when the risk might occur.

Exam Spotlight

In the BABOK® Guide, risks are uncertain events that can produce negative

outcomes. The focus is on the negative (threat) aspect of risks versus the

positive (opportunity) view of risk found in many methods. On your exam,

opportunities or positive risks are captured as needs and managed

170

accordingly.

Effective business analysts understand the consequences of internal and

external forces on the enterprise when working toward a desired future state.

Assessing and being aware of risks allows the business analyst to recommend

courses of actions as well as select a change strategy that fits the situation at

hand. Business analysts manage risks on their projects at any stage of the life

cycle to minimize the impact of those risks on the value of the implemented

solution or change.

Figure 3.5 summarizes the tasks involved in assessing risks during strategy

analysis.

FIGURE 3.5 Task summary: Assess risks.

Table 3.6 summarizes the inputs to this task and also lists the particular task

that was the source of the input (if applicable). Let’s take a look at the task

inputs used to assess risks.

TABLE 3.6 Inputs: Assess risks.

Task Input Input

Type

Input Source Source Knowledge

Area

Influences

(internal and

external)

Input

Elicitation results

(confirmed)

Input Confirm

elicitation results.

Elicitation and

Collaboration

Designs Input Prioritize Requirements Analysis

171

(prioritized) requirements. and Design Definition

Requirements

(prioritized)

Input Prioritize

requirements.

Requirements Analysis

and Design Definition

Business objectives Input Define future

state.

Strategy Analysis

Potential value Input Define future

state.

Strategy Analysis

Business analysis

approach

Guidelines

and tools

Plan business

analysis approach.

Business Analysis

Planning and Monitoring

Business policies Guidelines

and tools

Change strategy Guidelines

and tools

Define change

strategy.

Strategy Analysis

Current state

description

Guidelines

and tools

Analyze current

state.

Strategy Analysis

Future state

description

Guidelines

and tools

Define future

state.

Strategy Analysis

Identified risks Guidelines

and tools

Stakeholder

engagement

approach

Guidelines

and tools

Plan stakeholder

engagement.

Business Analysis

Planning and Monitoring

Remember, inputs are either informational in nature or can be outputs

produced by other business analysis tasks. Inputs are acted on by the task

elements and techniques, producing one or more task outputs. Let’s take a look

at the task inputs used when assessing risks.

Business Objectives Business objectives describe and point to the desired

direction needed to achieve the future state. They are also used to identify and

discuss potential risks along the way as part of the risk analysis efforts.

Designs (Prioritized) Prioritized designs link to and influence the risks along

the way to solution realization. Keep an eye on the designs priorities as you

perform risk analysis activities as they directly influence how you prioritize and

address the identified risks.

Elicitation Results (Confirmed) Effective business analysts make sure that

the elicitation information contains an understanding of what the stakeholders

perceive as risks in achieving the desired future state.

Influences (Internal and External) Influences are factors from inside and

outside the enterprise that can impact achieving the future state. They can be as

simple as organizational attitudes toward a proposed change in how things are

done or tangible influences such as existing or proposed infrastructure and

technology.

Potential Value Potential value is the value to be realized when a proposed

172

future state is implemented. This definition of business value provides a

benchmark against which risks can be assessed across the project life cycle.

Requirements (Prioritized) Prioritized requirements link to and influence

the risks along the way to solution realization. Keep an eye on the requirements

priorities as you perform risk analysis activities as they directly influence how

you prioritize and address the identified risks.

There are additional inputs that may be used by business analysis tasks:

guidelines and tools. Guidelines are essentially instructions or descriptions on

why and how a business analyst will undertake a task. Tools, on the other hand,

are methods for conducting a business analysis task or shaping a task output.

Let’s take a look at the guidelines and tools that may also be used as inputs

when assessing risks:

Business Analysis Approach The business analysis approach provides the

framework for all business analysis activities. It contains the guidelines for how

business analysts will perform risks analysis on their project.

Business Policies The limits and boundaries for decision making within the

organization live here. These policies may have an impact on the risk

management activities taking place.

Change Strategy The change strategy tells us how we plan to transition from

the current state to the future state. Risks associated with this change and the

steps of the change need to be considered when analyzing risks.

Current State Description How things are currently working provides the

context within which the new work needs to be completed. Current state risks

may come into play on your project, and you should watch for them.

Future State Description Along with the change strategy and the business

requirements, this description provides business analysts with a baseline for

determining the risks associated with achieving the future state.

Identified Risks Identified risks come from the risk analysis results and can

be used as a starting point for additional risk identification and analysis

activities relative to the current and future states.

Stakeholder Engagement Approach Stakeholders are an important source

of risks for your project. Be aware of your stakeholders and get them involved

with the risk assessment efforts across the project life cycle.

To assess risks, you will cover five areas within the task relative to one or more

risks. The elements are as follows:

Unknowns

Constraints, assumptions, and dependencies

Negative impact to value

Risk tolerance

Recommendation

Let’s step through each of these elements involved in assessing risks.

173

Unknowns Let’s face it, business analysts will never know everything that

might happen as the result of a change. We will never identify all of the possible

risks, either. Remember to look at lessons learned from previous projects to see

whether history provides you with additional risks to analyze and watch out for.

Stakeholder collaboration is essential when assessing risks. Working together

helps you understand the stakeholder’s view of the current and future states

relative to risks that may be encountered.

Constraints, Assumptions, and Dependencies Constraints, assumptions,

and dependencies should be analyzed for risks. Constraints are boundary

conditions or limits that might impact an organization’s ability to select certain

solution approach options. Assumptions are factors that you believe to be true,

but you have not yet confirmed them to be true. Dependencies are logical

relationships between the pieces and parts of your project, such as risks,

requirements, or activities.

Many business analysts treat constraints and assumptions as risks in and of

themselves. To do this, restate the constraint, assumption, or dependency as an

event or condition along with the consequences that could occur.

Negative Impact to Value To analyze the initial risks related to strategy

analysis and the desired future state, a business analyst needs to determine the

probability and impact of each identified risk. This is usually done with a

common scale, such as the numbers from 1 to 5 with a 1 being low and a 5 being

high. You can rank order your list of identified risks by multiplying the

probability and the impact of each risk in the list. This gives you the magnitude

of how likely a risk is to take place and how painful a risk will be if it does occur.

Risk Tolerance One key component of risk analysis is to understand your

organization’s risk tolerance. Organizations may be risk-averse, risk-neutral, or

risk-seeking. Interestingly enough, an organization’s approach to risk may

change over time. Risk-averse organizations want to reduce risks and are willing

to receive fewer benefits in return for a more certain outcome. Risk-neutral

organizations are squarely in the middle. They typically need to see that the

expected benefits equal or outweigh the costs of the proposed solution in order

to continue on with things. Risk-seeking organizations will accept high risks if

they come with high rewards for success.

Recommendation Business analysts are expected to recommend a course of

action based upon assessing the risks relative to a change strategy and business

need. Key stakeholders need to have a clear understanding of the risks relative

to the value of the change. There are five typical categories of recommendation

that can be made. The categories range from “go for it” to “do nothing.”

Pursue benefits of the change regardless of risk.

Pursue benefits of the change while investing to reduce the risk.

Increase the benefits of the change to outweigh the risks.

Identify ways to manage and optimize opportunities.

Do not pursue the benefits of the change.

174

Exam Spotlight

When assessing feasibility of a change to the enterprise early in the project

life cycle, be sure that you address the technical, financial, and business

risks of the proposed solution.

Technical Risks Will the new technology be able to scale up to the

performance requirements of our large organization?

Financial Risks Will estimated costs be exceeded? Might potential

benefits disappear?

Business Risks Can the organization change in order to realize the

solution benefits?

There are a number of techniques that you may choose to apply when assessing

risks for your project. Consider applying the risk analysis and management

technique to ensure that you have a full range of possible risks to consider. Let’s

take a closer look at how to successfully use this technique.

Recommended Technique: Risk Analysis and Management

The risk analysis and management technique is used to identify and manage

risks. Risk analysis and management is ongoing throughout a project. This

technique is initially used when developing the business requirements and

change strategy to identify areas of uncertainty about the technical, financial,

and business feasibility of a proposed solution or solutions. This initial risk

assessment during Strategy Analysis activities is the first step of many in the

land of “things will not go as planned.” Remember, the BABOK

Guide focuses

only on risks that are negative (threat) events.

The four steps of the risk analysis and management technique are risk

identification, analysis, evaluation, and developing treatments or responses.

Let’s take a quick look at each step in more detail.

Risk Identification Risks need to be identified before they can be analyzed.

Most business analysts enter identified risks into a risk register for a “one-stop

shopping” approach to risk analysis and management. As additional

information is analyzed regarding each risk, it can also be entered into the risk

Risk Analysis To analyze the identified risks, the business analyst determines

the probability and impact of each risk. This simple determination is usually

done with a common scale, such as the numbers from 1 to 5, with a 1 being low

impact to value and a 5 being high impact to value.

Risk Evaluation An easy way to look at the risk exposure is to take the values

you specified in Risk Analysis and add up all of the individual risk levels and

impacts to determine an overall risk value. Risk analysis results can then be

compared with the potential value of the change to see whether the overall level

175

of risk is acceptable for the change.

Risk Treatments or Responses The business analyst and key stakeholders

need to determine the treatment or response strategy used to deal with

significant negative risks. Five risk response strategies are listed in the

BABOK® Guide; these strategies are summarized in Table 3.7.

TABLE 3.7 Risk treatment or response strategies

Response Description

Accept Accept that the identified negative risk may occur and choose to do

nothing about it.

Avoid Take measures to ensure the identified risk does not occur.

Increase Decide to take on more negative risk to pursue an opportunity.

Mitigate Reduce the probability and/or the impact of an identified risk

occurring.

Transfer Transfer the responsibility for dealing with a negative risk to a

third party.

Other Techniques to Consider

The BABOK

Guide lists several other techniques that can be used when

assessing risks. They are summarized for you here:

Brainstorming Brainstorming is an effective way to generate a list of

identified risks relative to the change being made from the current to the future

state. The brainstorming approach complements risk assessment activities by

enriching the list of possibilities.

Business Cases Business cases are often used to capture risks associated with

alternative change strategies prior to selecting which strategy to use to make the

change actually happen.

Decision Analysis This technique allows a business analyst to examine and

model the costs and benefits of a proposed solution and its implementation. You

can use graphical decision trees and financial valuation techniques to compare

and contrast possible outcomes.

Document Analysis Experienced business analysts analyze existing

documents for potential risks, constraints, assumptions, and dependencies.

Financial Analysis This technique focuses on the potential effects of risks on

the financial value of the solution as well as on the costs to make that change

happen.

Interviews Interviews are used to speak with stakeholders and understand

what those stakeholders think might be risks for a proposed change to meet a

business need.

Lessons Learned Lessons learned and other historical data should be used as

a source of past risks and issues that might also be risks on your project.

176

Mind Mapping This visual, nonlinear information-gathering technique helps

you identify and categorize potential risks and see the relationships that exist

between those risks.

Root-Cause Analysis Root-cause analysis is an effective way to work

backward to identify and address the underlying problem causing a risk. It uses

fishbone diagrams and “five whys” techniques.

Survey or Questionnaire Surveys and questionnaires are often used to

understand what geographically dispersed or large numbers of stakeholders

think might be risks and the various factors of those risks.

Workshops This technique allows groups of stakeholders to share their

thoughts on what might be risks and the various factors of those risks.

Exam Spotlight

Close your eyes and see how many of the techniques you can remember for

assessing risks during strategy analysis. The more details you can memorize

about each task in each knowledge area, the better. Details include inputs,

guidelines and tools, elements, techniques, and outputs.

Let’s take a look at the outputs that result from applying one or more of these

techniques to assess risks relative to a business need.

Producing Risk Analysis Results

Once the risk analysis results are complete, they are used as an input to multiple

tasks later in the project life cycle (Table 3.8). Let’s take a quick look at a list of

these tasks now.

TABLE 3.8 Output: Assess risks.

Task

Output

Output Destinations Source Knowledge Area

Risk analysis

results

Manage stakeholder

collaboration.

Elicitation and Collaboration

Define change strategy. Strategy Analysis

Analyze potential value and

recommend solution.

Requirements Analysis and

Design Definition

Analyze performance measures. Solution Evaluation

Assess solution limitations. Solution Evaluation

Assess enterprise limitations. Solution Evaluation

The business analyst is responsible for getting this work done. The

implementation SME is responsible for providing inputs to the risk analysis in

177

their area of expertise. The sponsor needs to understand the risks as part of

authorizing and funding the changes. There are a number of additional

stakeholders that should be involved with risk assessment activities, including

the following:

Domain SME

Operational support

Project manager

Regulator

Supplier

Tester

You will use the risk assessment results as a decision-making tool when you are

building the change strategy. Let’s move on and take a look at this final

knowledge area task.

Define Change Strategy

Defining the change strategy requires developing and assessing alternative

approaches to the desired change before selecting the most appropriate

approach. Developing the change strategy produces two key business analysis

deliverables: the change strategy and the solution scope. The current state and

future state definitions are critical to the success of this task as they provide

valuable context for the change that is being driven by the business need.

Basically, the change strategy is used to justify the costs of doing a project in

terms of the value the project adds to the business and the associated business

benefits. A change strategy must look at both sides of the equation, comparing

both the costs and benefits of a proposed solution. The expected business

benefits and value of the solution should be evaluated relative to achieving

business objectives and meeting the business need.

Many templates and documents are used for a change strategy. We have worked

in organizations where the business case justifying our next project contained

very much the same information as the change strategy contains here. The

template you use for your change strategy is up to you. Just be sure that the

information it contains is adequate to support a go/no-go decision about the

project that implements the proposed solution defined in the business

requirements. At a minimum, the change strategy should address the following

areas:

Context of the change

Alternative change strategies

Justification for why a change strategy is the best approach

Investment and resources required to achieve the future state

Value of the change after the solution is delivered

Key stakeholders involved in the change

178

Transition states required to achieve the future state

After the change strategy is completed and approved for a project, it is time for

the detailed requirements development and other project work activities to

begin. Many times, the project manager will use the change strategy as an input

for the project charter.

According to the BABOK

Guide, the solution scope defines “the set of

capabilities a solution must deliver in order to meet the business need.” It is

derived from the business need, the desired outcome (business benefits), and

the required capabilities. The solution scope will be impacted by the solution

approach that is selected.

Solution scope focuses on the key business stakeholders of a project. This is

where the business analyst defines a recommended solution in enough detail for

these stakeholders to understand the new business capabilities the solution will

provide. This definition includes all major features, functions, and external

interactions of the solution.

Exam Spotlight

Be sure you can distinguish between product, project, and solution scope.

Project Scope Project scope defines the work needed to deliver a product,

service, or result with the specified features and functions.

Product Scope Product scope describes the features and functions

characterizing the product, service, or result.

Solution Scope Solution scope is the set of capabilities a solution must

deliver in order to meet the business need.

Figure 3.6 summarizes the inputs, outputs, techniques, and associated tasks for

defining the change strategy and solution scope.

179

FIGURE 3.6 Task summary: Define change strategy.

Table 3.9 summarizes the inputs to this task and also lists the particular task

that was the source of the input (if applicable).

TABLE 3.9 Inputs: Define change strategy.

Task Input Input

Type

Input Source Source Knowledge

Area

Current state

description

Input Analyze current state. Strategy Analysis

Future state

description

Input Define future state. Strategy Analysis

Risk analysis

results

Input Assess risks. Strategy Analysis

Stakeholder

engagement

approach

Input Plan stakeholder

engagement.

Business Analysis

Planning and

Monitoring

Business analysis

approach

Guidelines

and tools

Plan business analysis

approach.

Business Analysis

Planning and

Monitoring

Design options Guidelines

and tools

Define design option. Requirements

Analysis and Design

180

Definition

Solution

recommendations

Guidelines

and tools

Analyze potential value

and recommend

solution.

Requirements

Analysis and Design

Definition

Let’s take a look at the task inputs used to assist the business analyst in defining

the change strategy and solution scope:

Current State Description The current state description defines the current

capabilities of the organization relative to the business need being addressed

and the desired future state to be defined. When defining the change strategy,

an assessment of internal and external influences is crucial and should be found

here.

Future State Description The future state description provides the business

analyst with a baseline and context about the desired future state.

Risk Analysis Results This input defines the identified risks and analyzes

negative exposure to value for each of those risks.

Stakeholder Engagement Approach Stakeholder communication and

collaboration needs are defined in this approach. They can assist the business

analyst in identifying change-related activities that are stakeholder related.

There are also several guidelines and tools used as inputs to this task. Let’s step

through them briefly now.

Business Analysis Approach The business analysis approach provides

guidance on how the business analyst defines the change strategy and what the

contents of that strategy might be.

Design Options There can be a number of design options that satisfy the

business need. Each option has its own challenges that need to be addressed by

the change strategy once an option is selected.

Solution Recommendations The change strategy typically offers more than

one potential solution to a business need. By identifying possible solutions, the

“best fit” solution can be selected that can be pursued to achieve the desired

future state.

When defining the change strategy, business analysts are expected to address

five essential elements when completing the task. Remember, the solution scope

and the change strategy are the two key outputs from this task. The elements are

as follows:

Defining the solution scope

Performing a gap analysis

Assessing enterprise readiness

Defining the change strategy

Looking at transition states and release planning

Let’s step through each of these elements involved in defining the change

strategy for a project:

181

Solution Scope The BABOK

Guide defines a solution as “the outcome of a

change that allows an enterprise to satisfy a need.” Solution scope describes the

boundaries of a solution, including the major features, functions, and

interactions of the proposed solution. You need to be sure to state both the in-

scope and out-of-scope solution components across the full enterprise

architecture.

Gap Analysis Gap analysis results show the difference between the current

state and the future state of the enterprise relative to a business need. Business

analysts compare the two states and look at the capability gaps between where

the enterprise is right now and where the enterprise wants to be in the future.

The change strategy creates the missing capabilities or improves upon existing

capabilities to eliminate or minimize the gap.

Enterprise Readiness Assessment This assessment looks at the

enterprise’s capacity to make a change, use the resulting change, and

operationally support the change over time. This assessment is made relative to

realizing value from the solution, which is the outcome of the change. The

assessment looks at cultural readiness and operational readiness, the timeline

for implementing the change, and the resources available to support the change

effort.

Change Strategy In a nutshell, the change strategy is a high-level plan of key

activities for transitioning the enterprise from its current state to the desired

future state. This strategy looks at multiple options for achieving the change and

recommends which of these options are actually feasible courses of action.

A preferred change strategy is selected from the feasible options and developed

in greater detail. Many times, a business case is built for the feasible options to

help with decision making. Selection criteria for choosing the preferred change

strategy include the following:

Organizational readiness

Major costs and investments

Timelines for making the change

Alignment to business objectives

Timelines for value realization

Opportunity costs

There are pros and cons to the different change strategy options that are being

considered. Opportunity costs quantify the benefits that could have been

achieved if you selected a different change strategy.

Transition States and Release Planning When planning an

implementation, try to minimize the impacts to business activities. The desired

future state may be achieved in one big jump or in several smaller hops or

transition states. Release planning determines which requirements are included

in each stage, phase, or iteration of a change. Releases may be defined based

upon budgets, time constraints, resource constraints, or the ability of the

business to absorb change.

182

There are a number of techniques that you can use to define your project’s

change strategy and solution scope. A great way to begin this task is by building

a balanced scorecard. Let’s take a look at this recommended technique in

greater detail.

Recommended Technique: Balanced Scorecard

Value creation needs to be understood, measured, and optimized in order to

create sustainable performance. A balanced scorecard measures organizational

performance by focusing on outcomes. This technique takes an organization’s

vision and strategic plan to build a framework of tangible objectives, specific

measures, and targeted outcomes. This technique can be used for short,

medium, and long-term goals. The balanced scorecard has these four

dimensions:

Learning and growth

Business process

Customer

Financial

The learning and growth dimension looks at employee training and learning,

product and service innovation, and corporate culture. In contrast, business

process dimension focuses on how well the business is operating and meeting

their customer needs. The customer dimension measures customer focus,

satisfaction, and delivery of value. The financial dimension includes

profitability, revenue growth, and economic value.

Good metrics address both precision and accuracy. Precision

focuses on the consistency of measurements and targets repeated

measurements that yield the same value. Accuracy looks at how close the

true value is to the measured value. Closer values indicate higher reliability

and less uncertainty.

Other Techniques to Consider

The BABOK

Guide lists some additional techniques that can be used when

defining the change strategy and solution scope for a project. They are

summarized for you here:

Benchmarking and Market Analysis This technique compares

organizational practices against best-in-class practices and is most often used

when business analysts and key stakeholders are deciding which change strategy

is preferred.

Brainstorming Brainstorming allows a group of stakeholders to

collaboratively generate ideas for change strategies.

183

Business Capability Analysis Business capability analysis is a way to

prioritize the capability gaps in relation to value and risk between the current

state and the desired future state of things.

Business Cases Business cases can be used to capture information about the

recommended change strategy and other potential strategies that were assessed

and considered but were not recommended.

Business Model Canvas Business analysts can use this nine-box template to

define the changes needed in the current infrastructure, customer base, and

financial structure of the organization in order to achieve the potential value of

making a change.

Decision Analysis Decision analysis techniques compare the different change

strategies in order to choose which change strategy is most appropriate in a

given situation.

Estimation Estimating techniques can be used to determine the timelines for

activities within the preferred change strategy.

Financial Analysis Financial analysis helps people understand the potential

value associated with a specific change strategy. This technique can also be used

to evaluate strategies against targets set for return on investments.

Focus Groups Focus groups bring customers or end users together to get their

input on the solution scope and change strategy.

Functional Decomposition Functional decomposition allows you to

systematically break down the solution scope components into smaller pieces

when developing the change strategy.

Interviews This technique involves talking to stakeholders, getting them to

fully describe the solution scope and change scope, as well as sharing their ideas

on the change strategy.

Lessons Learned Remember to use lessons learned so you know what went

wrong with past changes and can do things better this time.

Mind Mapping Mind mapping is a visual, nonlinear diagramming technique

for a group of key stakeholders to develop and explore ideas for change

strategies.

Organizational Modelling Use this technique to describe roles,

responsibilities, and reporting structures that are part of the solution scope and

are needed during the change.

Process Modelling Process modelling describes how work would occur in the

solution scope or during the change transitions.

Scope Modelling Scope modelling assists the business analyst in determining

what is in scope and what is out of scope for the solution and for the change that

is being made.

SWOT Analysis SWOT analysis lets you compare the costs and benefits of

implementing a potential solution or change strategy. As previously discussed,

there are two dimensions to this analysis: the internal strengths and weaknesses

184

of the organization and the external opportunities and negative impacts that are

in play. The business analyst is seeking to maximize strengths and minimize

weaknesses.

Vendor Assessment When goods or services may be purchased from a third

party as all or part of a proposed solution or change strategy, an assessment of

that vendor should be included as part of the change strategy.

Workshops Workshops are used for groups of stakeholders to collaboratively

develop change strategies with stakeholders.

Let’s take a look at the outputs that result from applying one or more of these

techniques to defining solution scope and developing a change strategy.

Building the Change Strategy

The change strategy is the approach that the organization will follow to guide a

change in the way things are being done. The solution scope is achieved through

execution of the change strategy. The solution scope describes what must be

delivered to meet a business need. This includes any effects the solution might

have on the business and technology operations and infrastructure of the

organization. Solution scope can change throughout the project, based on

changes to the business environment or project scope over time.

Once the solution scope is defined and the change strategy is selected, they are

used as inputs to numerous business analysis tasks (Table 3.10).

TABLE 3.10 Outputs: Define change strategy.

Task

Output

Output Destinations Source Knowledge Area

Change

strategy

Plan stakeholder engagement. Business Analysis Planning and

Monitoring

Prioritize requirements. Requirements Life Cycle

Management

Assess requirements changes. Requirements Life Cycle

Management

Approve requirements. Requirements Life Cycle

Management

Assess risks. Strategy Analysis

Define design options. Requirements Analysis and

Design Definition

Measure solution performance. Solution Evaluation

Analyze performance measures. Solution Evaluation

Assess solution limitations. Solution Evaluation

Assess enterprise limitations. Solution Evaluation

Solution Prioritize requirements. Requirements Life Cycle

185

scope Management

Assess requirements changes. Requirements Life Cycle

Management

Approve requirements. Requirements Life Cycle

Management

Specify and model requirements. Requirements Analysis and

Design Definition

Validate requirements. Requirements Analysis and

Design Definition

Define requirements architecture. Requirements Analysis and

Design Definition

Define design options. Requirements Analysis and

Design Definition

Analyze potential value and

recommend solution.

Requirements Analysis and

Design Definition

Measure solution performance. Solution Evaluation

Analyze performance measures. Solution Evaluation

Assess solution limitations. Solution Evaluation

Assess enterprise limitations. Solution Evaluation

Recommend actions to increase

solution value.

Solution Evaluation

The business analyst and project manager are jointly responsible for managing

change and planning activities to complete a change. The project manager owns

the project scope, which is the work necessary to deliver the solution scope.

Detailed release planning and component allocation activities must integrate

into the project plan that drives getting the change and its resulting solution

defined in more detail, designed, and deployed. The implementation SME may

also be of assistance in allocating capabilities to solution components. After the

task is complete, the sponsor will approve the solution scope.

Numerous other stakeholders may be involved in defining the change strategy

and solution scope. They include the following:

Customer

Domain SME

End user

Operational support

Regulator

Supplier

Tester

186

Business Case: Hiking Your Way

Early in her career as a management consultant, Ginger discovered that,

during business case development, not all change strategy development

efforts run smoothly. She was sent on an assignment to a major company to

help the CIO define the business requirements for a new claims processing

system. Her business requirements and business case would be presented to

the CEO for approval. Then, a very challenging (and costly) development

effort would begin.

What Ginger didn’t know was the current state of affairs within the

executive management team regarding this proposed solution. She got an

idea that things weren’t quite right when the business analysis team drew

straws for who got to interview the CEO about this proposed new system.

Ginger got the short straw and scheduled her interview for later that

afternoon.

When she walked into the CEO’s office, he was very pleasant. After offering

her a cup of tea, he told her to go ahead and ask her questions. His response

to the first question about the strategic business priorities of the

organization was right on target. However, it was when she asked her

second question that things got truly entertaining.

“How will the organization measure the success of this project?”

The CEO told Ginger not to concern herself with the success of the project

because it was never going to get off the ground. He then went on to talk

about the very limited career that the CIO, who was also the project sponsor,

would be having with this company. Before Ginger could make any reply to

this outburst, the CEO asked her to leave because the interview was over.

When she got up to walk out of his office, he motioned with his hand toward

the far corner of the room.

“Go out that way,” he said.

So she did. As she put her hand on the door handle, Ginger found herself

wondering what was on the other side of the unknown door. Shark tank?

Broom closet? Bottomless pit? She opened the door and stepped out into the

executive parking lot at the back of the building. Unfortunately, getting back

to the front door of the building required a long hike through the cactus and

scrub. When Ginger arrived at the front desk, the security guard looked at

her and her tattered stockings and smiled sweetly.

“Lucky you,” he said. “I see he threw you out of his office. You know, you’re

the first one today. But I bet you won’t be the last.”

The guard then presented her with a piece of candy.

Needless to say, the change strategy and the business case containing that

187

strategy were not approved for this particular project. For her next business

requirements assignment, Ginger decided to wear trousers on the first day—

just in case.

188

How This Applies to Your Projects

In this chapter, you stepped through defining the business requirements,

current state, future state, change strategy, and solution scope for a project and

using this data to seek the sponsor’s approval to get that project underway.

Performing business analysis usually starts up at 30,000 feet on most projects.

Working on complex projects in which the initial feasibility studies and business

case development work are a project themselves can be enjoyable. It is always

fun to figure out the scope of what needs to be done and to justify why an

organization needs to do it. Understanding and defining the big picture is an

important piece of a project’s controlled start, and every business analyst should

be able to perform this work well.

It should be no surprise that projects are successful when what is to be

accomplished is clearly stated and agreed upon. The strategy analysis tasks and

their resulting outputs set the framework for the subsequent requirements

development activities. The change strategy and solution scope are defined by

negotiation between key business and management level stakeholders. Solution

scope definition restricts the detailed requirements development downstream

and allows for informed decision making and prioritization throughout the

project life cycle.

Many different project documents can be used to define the scope of a business

problem or need and justify why an organization should do something about it.

Here is a short list of possible candidates:

Business case

Business requirements document (BRD)

Project brief

Feasibility study

Opportunity assessment

Project charter

Operational concept description (OCD)

Scope definition document (SDD)

No matter which document template you use or what name you give that

document, it should contain most, if not all, of the information that the business

analyst builds and collects as part of their Strategy Analysis tasks. This includes

the business need, the justification and rationale for proceeding with the effort,

key stakeholders involved with these business-focused efforts, any business

constraints, and an initial risk assessment.

Business Requirements Document Outline

189

Here is a business requirements document template I frequently use.

Typically, I modify it for each organization where it is being applied, based

on their preferences. It is adapted from the IEEE’s Concept of Operations

(ConOps) document that is part of their software engineering standards.

Executive Summary

1.0 Introduction and Overview

1.1 Background

1.2 Description of Current Situation

1.3 Concepts for Proposed System

2.0 Scope of Proposed Efforts

2.1 Statement of Problem or Need

2.2 Business Areas and Goals

2.3 Business Requirements

2.4 Involved Stakeholder Organizations

2.5 Constraints

3.0 Analysis and Recommendations

3.1 Justification and Rationale

3.2 Summary of Improvements

3.3 Disadvantages and Limitations

3.4 Impacts and Risks

4.0 Referenced Documents

5.0 Signature Page

Appendix: Glossary of Terms

Appendix: Acronyms

Most organizations have their own templates, examples, and specific

requirements for writing a business case, scope definition, and/or business

requirements document. Be sure to check with your project manager to see what

is commonly used or required for your projects when you are defining the big

picture. Often, document templates provide a valuable road map for what

information you will need to gather and analyze during your Strategy Analysis

work.

190

Summary

The four tasks of the Strategy Analysis knowledge area focus on defining the

business requirements for the project and justifying why that project should be

performed. The business requirements are the framework for what capabilities a

solution will deliver in order to meet a business need. The resulting business

benefits and value from implementing a particular solution will be defined, and

the means to measure them will be established. A change strategy will also be

defined to help the organization achieve and adopt the changes that are

necessary.

In the BABOK

Guide, the set of Strategy Analysis task deliverables includes the

business requirements, the business objectives, the potential value of the

change, the current state description, the future state description, the solution

scope, and the change strategy. The tasks in this knowledge area are focused on

defining and getting approval for the big picture of what capabilities and

benefits a proposed new solution will provide to the organization.

The Strategy Analysis tasks address the most strategic part of business analysis

work. Often, these tasks take place before an actual project is planned or even

approved. Many organizations assess and evaluate the feasibility and value of

possible solutions to their problems and then select the most important projects

to be done. The remaining projects get to sit on the back burner and wait for an

opportunity to be initiated and done.

Business analysts focus on the strategic priorities, business goals, and business

objectives of their organizations when working at a more strategic level early on

in the project. They have to define and understand the business need and

determine the desired outcomes the organization would like to see to meet that

need. This work requires interacting with senior management to determine

what the problem or opportunity is and what they think might be done to

correct it. The underlying competencies of effective communication and

interaction are essential for success at this early point in or before the more

detailed project work begins.

During strategy analysis, a business analyst looks at ways to go about

implementing a solution that solves the problem and meets the identified

business need. The selected solution depends a great deal on the nature of the

problem and the preferences of the organization. Some organizations might

decide to outsource services to implement a solution. Other organizations may

prefer to build their own software applications and to provide those services

themselves.

Business analysts work closely with the project manager in order to get the

solution scope definition in place. While the business analyst is focusing on

defining the solution scope, the project manager is working in tandem with

them, focused on the project scope. Remember, the project scope defines the

work needed to deliver a product, service, or result, with the specified features

and functions. By comparison, the solution scope defines the set of capabilities a

191

solution must deliver in order to meet a business need.

Risk management also kicks in as part of the Strategy Analysis tasks. The

business analyst must analyze the technical, financial, and business risks related

to the overall solution feasibility. In many organizations, a business case is the

“authorization to proceed” document. It justifies why the organization should

invest in the implementation of a solution. Once the business case is approved,

the project itself can get merrily underway.

192

Exam Essentials

Be able to list the tasks found in the Strategy Analysis knowledge

area. On your exam, you will see questions about the tasks, their associated

techniques, their more detailed elements, and the key outputs that they

produce. You should memorize the four tasks of this knowledge area and any

key outputs or techniques associated with them. The tasks are as follows:

Analyze current state.

Define future state.

Assess risks.

Define change strategy.

Be able to state the purpose of key deliverables. The key deliverables

produced by the tasks in this knowledge area are not always easy to remember

because they do not always align with the task names. Many tasks produce more

than one deliverable. Here’s the list:

Business requirements

Business objectives

Current state description

Future state description

Solution scope

Change strategy

Potential value

Be able to distinguish between project, product, and solution scope.

Project scope defines the work needed to deliver a product, service, or result

with the specified features and functions. Product scope includes the features

and functions characterizing the product, service, or result. Solution scope is the

set of capabilities a solution must deliver in order to meet the business need.

Be able to explain the techniques used to define the big picture.

Performing the Strategy Analysis tasks to ultimately build the business

requirements uses many business analysis techniques. Spend some time getting

familiar with these techniques and when they might be applied during Strategy

Analysis.

193

Key Terms

This chapter stepped through the contents of the second knowledge area from

the BABOK® Guide: Strategy Analysis. Most of this knowledge area focuses on

defining the big picture that the business analysis team will use to frame

subsequent work activities across the project life cycle.

You should understand how to apply the techniques and tasks in this knowledge

area in order to be an effective business analyst. Additionally, you will need to

know the four tasks and their associated elements and techniques from this

knowledge area in order to be successful on the CBAP

or CCBA

™

exams. The

tasks include the following:

Analyze current state.

Define future state.

Assess risks.

Define change strategy.

A number of new key words in Chapter 3 relate to defining the strategic view of

a project. Here is a list of some of the key terms that you encountered in this

chapter:

business need

business objectives

business requirements

capability-centric view

change strategy

constraints

dependencies

enterprise readiness

fishbone diagram

five whys

gap analysis

mission

organizational culture

potential value

process-centric view

project charter

project scope

risks

194

root case analysis

SMART (Specific, Measurable, Achievable, Relevant, and Time-Bound)

solution scope

SWOT analysis

transition states

values

vision

195

Review Questions

1. What governs the performance of all Strategy Analysis tasks?

A. Enterprise analysis plan

B. Business analysis approach

C. Project management plan

D. Governance approach

2. Which Strategy Analysis task produces the solution scope as an output?

A. Define future state.

B. Define change strategy.

C. Analyze current state.

D. Define solution scope.

3. Strategy Analysis tasks focus on documenting what type of requirement?

A. Stakeholder

B. Solution

C. Transition

D. Business

4. What term describes the outcome of a change that allows an enterprise to

satisfy a need?

A. Solution

B. Opportunity

C. Benefit

D. Capability

5. What defines the business problem for which the business analyst is seeking

a solution?

A. Business case

B. Business objectives

C. Business goals

D. Business need

6. Industry structure might present constraints, dependencies, or drivers on

the current state of the enterprise. This area is a source of ____________

influencers found when analyzing the current state.

A. Internal

B. Competing

196

C. External

D. Business

7. What output contains the results of the business analyst assessing the

capability gaps between existing and new capabilities of the organization?

A. Business case

B. Change strategy

C. Solution scope

D. Business requirements

8. When assessing risks during Strategy Analysis, the business analyst should

consider all of the following elements except:

A. Unknowns

B. Proximity

C. Constraints

D. Dependencies

9. What four dimensions are addressed in a balanced scorecard?

A. Learning and growth, transition states, customer, supplier

B. External business process, internal business process, customer, financial

C. Gap analysis, change strategy, solution scope, business requirements

D. Learning and growth, business process, customer, financial

10. When building a change strategy, decision analysis can be used to compare

the ____________ of implementing a proposed solution against the

____________ to be gained.

A. Benefits; costs

B. Risks; benefits

C. Costs; benefits

D. Risks; costs

11. When analyzing the current state, the business analyst looks at the scope of

decision making at different levels in the organization. What element of the

current state are they looking at?

A. Internal assets

B. Business architecture

C. Policies

D. External influencers

12. Who typically approves the change strategy and solution scope and

authorizes funding for the resulting project?

A. End user

197

B. Sponsor

C. Domain SME

D. Customer

13. Which business analysis technique allows the business analyst to leverage

existing materials to analyze the current state of the enterprise relative to a

business need?

A. Process modelling

B. Document analysis

C. State diagrams

D. SWOT analysis

14. The business analysis team has analyzed the current state and defined the

desired future state of the enterprise. What is the team’s most likely next

step?

A. Performing a gap analysis

B. Assessing risks

C. Defining the change strategy

D. Engaging stakeholders

15. What deliverable contains the preliminary analysis of solution alternatives or

options to determine how and whether each option can provide an expected

business benefit?

A. Change strategy

B. Business need

C. Strategic analysis

D. Feasibility study

16. What describes the specific end results an organization is seeking to achieve

and the measures to objectively assess if these end results have been

achieved?

A. Business case

B. Business objectives

C. Business goals

D. Business need

17. The business analyst is looking at the current state of an existing system and

trying to figure out how to improve the efficiency of that system. What level

of the enterprise is the business need being defined from?

A. From the top-down

B. From the bottom-up

C. From middle management

198

D. From external drivers

18. When defining solution scope, which stakeholder role participates in

allocating new capabilities to solution components and determining what is

required to deliver those capabilities?

A. Business analyst

B. Domain SME

C. Project manager

D. Implementation SME

19. During Strategy Analysis, which technique allows the business analyst to

break down business goals into achievable objectives and measures?

A. Root-cause analysis

B. Business rules analysis

C. Functional decomposition

D. Organization modelling

20. What has been defined when all of the Strategy Analysis knowledge area

tasks are complete?

A. Solution scope and change strategy

B. Business requirements and solution approach

C. Solution scope and solution approach

D. Business case and required capabilities

199

Chapter 4

Overarching Tasks: Requirements Life Cycle Management

CBAP

/CCBA

™

EXAM TOPICS COVERED IN THIS CHAPTER:

Tracing requirements and designs

Maintaining requirements for reuse

Prioritizing requirements

Assessing requirements changes

Approving requirements

It isn’t enough to just plan the business analysis activities and

get the work done. Managing and maintaining information about the

requirements being developed across the project life cycle is the responsibility of

the business analyst (that means you). If you can’t manage the requirements

from inception to retirement, how will you know whether those requirements

are implemented in the solution?

The overarching set of requirements life cycle management tasks is found in the

Requirements Life Cycle Management knowledge area. The tasks in this

knowledge area focus on ensuring that the right people are involved with

developing, understanding, and approving the business, stakeholder, and

solution requirements, as well as the designs. In addition, the requirements

themselves must be accessible and managed during the requirements

development work and throughout the project life cycle.

200

Requirements Life Cycle Management

The Requirements Life Cycle Management knowledge area targets managing

and sharing the project requirements and designs with the project stakeholders.

This knowledge area is also where the business analysis team deals with the

challenges of managing changing requirements and designs across the project

life cycle and ensuring that the solution implements them. Remember, for the

business analyst, requirements are focused on the need, while designs are

focused on the solution. Requirements and designs can change while they are

being developed and after they have been approved and baselined.

To focus on what is important to the business analyst across the life cycle of

their business analysis efforts, let’s consider the tasks of this knowledge area

with the framework of the BAACM™. Business analysts need to keep an eye on

their work relative to the six concepts contained in the framework: changes,

needs, solutions, stakeholders, values, and contexts. Table 4.1 describes these

responsibilities.

TABLE 4.1 The BACCM™: Requirements Life Cycle Management

Core

Concept

The Business Analyst’s Responsibilities

Change Manage and evaluate proposed changes to requirements and

designs across the life cycle.

Needs Ensure the business need is met by tracing, prioritizing, and

maintaining the requirements.

Solution Make sure the solution meets the business need by tracing

requirements and designs to solution components.

Stakeholders Work with key stakeholders to understand, agree upon, and

approve requirements and designs.

Value Extend value beyond the current initiative by maintaining

requirements for reuse.

Context Analyze the context of the existing enterprise to support tracing

and prioritizing requirements and designs.

Change is an interesting beast. Remember when your mother told you that

hindsight is always 20/20? Well, your mother was right. Business analysts are

experts at recognizing changing circumstances as the project life cycle moves

forward. They recognize that their level of knowledge about the solution and its

implementation improves over time. However, their ability to respond quickly

and easily to changes in the requirements decreases as the project’s delivery

date draws near. Managing changing requirements is an integral part of what

business analysts do. Figure 4.1 illustrates this strange and wonderful

relationship between what business analysts know about projects and how

quickly and easily they can respond to changes over time.

201

FIGURE 4.1 Responding to changing requirements

The tasks in this knowledge area consist primarily of actions taken for a

project’s business, stakeholder, or solution requirements and designs. These

tasks provide the business analysis team and the project with requirements-

related outputs that are then used in various ways downstream. The

Requirements Life Cycle Management knowledge area is addressed in Chapter 5

of the BABOK

Guide.

Business, Stakeholder, and Solution Requirements

Let’s remind ourselves what these three types of requirements are and how

they relate to one another as part of your detailed requirements

development efforts. Remember that tasks in the Requirements Life Cycle

Management knowledge area do not typically focus on the fourth type of

requirements, which are the transition requirements.

Business Requirements Business requirements are defined early in the

project, representing the high-level goals, objectives, and outcomes for the

project. Business requirements justify the reasons for making a change in

the enterprise and define how success will be measured once that change

has been implemented. Typically, these high-level, “big-picture”

requirements are defined by tasks found in the Strategy Analysis knowledge

area.

Stakeholder Requirements Stakeholder requirements are the bridge

between the business requirements and the more detailed solution

requirements to define the needs of stakeholders and how they will interact

with a solution. They are developed and defined as part of the Requirements

Analysis and Design Definition knowledge area. Like the business

requirements that preceded them, the stakeholder requirements will be

progressively elaborated into the more detailed solution requirements.

Solution Requirements Solution requirements are the most detailed

type of requirements that describe the solution characteristics needed to

meet the higher-level business and stakeholder requirements. Typically,

solution requirements are subdivided into two specific types: functional

requirements and nonfunctional requirements. Solution requirements are

developed and defined as part of the tasks found in the Requirements

Analysis and Design Definition knowledge area.

202

The Requirements Life Cycle Management knowledge area also addresses

monitoring the effects of changing project requirements across the project life

cycle. The business analysis team assesses the effectiveness of the actual

solution relative to the organization’s business goals and objectives. This

ensures that the project’s business analysis tracks its organizational alignment

and understanding, making it available for use on future projects. How is this

accomplished? Let’s take a look at the five tasks involved.

The Business Analyst’s Task List

The business analyst has five tasks to perform in the Requirements Life Cycle

Management knowledge area. We will look at each of these tasks in greater

detail later in this chapter. The task list from the BABOK

Guide includes the

following:

Managing requirements traceability

Maintaining requirements and designs for reuse

Prioritizing the requirements and designs

Assessing requirements changes

Approving and agreeing on requirements and designs

These tasks focus on making sure that the project stakeholders have a common

and consistent understanding of the requirements, designs, and solution that

the requirements are defining. The business analyst is also responsible for

managing the requirements as they change across the project life cycle. We will

step through each of these tasks in greater detail later in this chapter.

When Does Requirements Life Cycle Management Take Place?

To effectively communicate, we must realize that we are all different in the

way we perceive the world and use this understanding as a guide to our

communication with others.

—Anthony Robbins, Motivational speaker, self-help author

The tasks in the Requirements Life Cycle Management knowledge area begin as

soon as requirements development work begins for a project. They accompany

the work being done in any knowledge area that develops requirements,

including Strategy Analysis, Requirements Analysis, Design Definition, and

Solution Evaluation. Effective business analysts make sure that their

requirements-related communication activities take place across the project life

cycle.

In the Requirements Life Cycle Management knowledge area, the

life cycle is not meant to be a methodology or process for business analysis

203

work. The “life cycle” refers to the phases, states, or stages that the

requirements and designs may pass through during their development or

when they are changing in some way.

The requirements life cycle in this knowledge area works like this:

Begins with the representation of a business need as a requirement

Continues through the development of a solution

Ends when the requirements and the resulting solution are retired

Several key business analysis deliverables influence and guide managing the

requirements under development on a project. These approaches were created

as part of the Business Analysis Planning and Monitoring knowledge area. They

include the following:

Change strategy

Governance approach

Information management approach

The tasks in the Requirements Life Cycle Management knowledge area rely on

the contents of these approaches that define how you make decisions about

proposed changes, implement traceability, and store requirements and designs

information as you develop your project requirements. With that in mind, let’s

step through the first task in the Requirements Life Cycle Management

knowledge area: tracing requirements.

Exam Spotlight

Approximately 27 of your 150 CBAP® exam questions focus specifically on

Requirements Life Cycle Management. On the CCBA™ exam, expect to see

about 23 questions about this knowledge area. The questions target specific

aspects of the five tasks found in this knowledge area. Be sure you know

them well.

Trace Requirements

Requirements traceability provides the business analyst with the ability to

identify and document the lineage of each requirement and design. A

requirement’s lineage includes its relationship to other project requirements, to

work products, and to the solution components. When business analysts say

that they can trace a requirement or design, they are telling you that they can

look at that specific requirement or design and all other requirements and

designs to which it is related.

Requirements traceability begins with each project’s business needs. The

business needs are used to determine the business requirements. In turn, the

204

business requirements are decomposed into the more detailed stakeholder

requirements level. Stakeholder requirements get broken down once more into

the detailed solution requirements that transition the project team from

requirements definition to solution design and development. All of the

requirements that make up a project’s solution scope should trace back to one or

more business needs for that project.

Is It Real or Gold Plating?

Remember that all project requirements must be linked back to a business

need. Otherwise, a requirement is not necessary to meet the business need

and deliver the solution scope. Extra requirements that are not necessary to

deliver the solution scope are often referred to as gold plating.

Figure 4.2 summarizes the inputs, outputs, guidelines, tools techniques, and

associated tasks for tracing requirements on a project.

FIGURE 4.2 Task summary: Trace requirements.

Inputs either are informational in nature or can be outputs produced by other

business analysis tasks. Inputs are acted on by the task elements and

techniques, producing one or more task outputs. These are the task inputs used

when tracing requirements:

Requirements All requirements can be traced to other requirements on a

project. According to the BABOK

Guide, “other requirements” include goals,

objectives, business requirements, stakeholder requirements, solution

requirements, and transition requirements. All solution and stakeholder

requirements must be traceable to a business requirement. Requirements may

also have traceability relationships with solution components, business rules,

205

and other work products.

Designs Designs are usable representations of solutions. They can be traced to

all types of requirements, to solution components, and to other work products.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Guidelines are essentially instructions or descriptions of

why and how a business analyst will undertake a task. Tools, on the other hand,

are methods for conducting a business analysis task or shaping a task output.

These are the guidelines and tools that can also be used as inputs when tracing

requirements:

Domain Knowledge Tracing requirements leverages business knowledge and

expertise from stakeholders in the business domain being addressed. This

knowledge enables business analysts to put together the pieces of the

traceability puzzle correctly.

Information Management Approach The business analysis team’s

traceability decisions should be based on the information management

approach. This approach addresses and defines requirements traceability before

any actual requirements development has begun.

Legal/Regulatory Information Sometimes the business analyst must

incorporate legislative or regulatory rules into their project’s traceability

approach.

Requirements Management Tools/Repository The tools and storage for

requirements and requirement traceability must be in place prior to

commencing requirements development. Based upon the complexity of the

project and the degree of traceability formality, these tools can range from

simple spreadsheets to complex requirements management tools.

Table 4.2 summarizes the inputs, guidelines, and tools for this task and lists the

source of the input (if applicable).

TABLE 4.2 Inputs: Trace requirements.

Task Input Input

Type

Input Source Source

Knowledge Area

Requirements Input

Designs Input

Domain knowledge Guidelines

and tools

Information

management

approach

Guidelines

and tools

Plan business analysis

information

management.

Business Analysis

Planning and

Monitoring

Legal/regulatory

information

Guidelines

and tools

Requirements

management

tools/repository

Guidelines

and tools

206

Business analysts need to step through three essential elements to create and

manage requirements traceability for their projects. These elements are:

Deciding the level of formality

Selecting the relationships to be traced

Documenting and maintaining the traced requirements

Let’s step through each of these three elements now.

Deciding the Level of Formality The challenge for business analysts and

project teams is deciding what requirements and designs need to be traced and

what can be skipped. Traceability can be built and maintained at many levels

within a given set of project requirements. Traceability usually begins with

tracing the current requirements under development to the higher-level

requirements from which they are being derived. For example, when business

analysts build the solution requirements for a project, the first aspect of

traceability that they address is derivation from the stakeholder requirements

that preceded the solution requirements.

The business analyst needs to decide the project’s approach to traceability

before the requirements development work actually begins. It is important to

decide the level of traceability and the types of relationships to be traced ahead

of time. That allows the business analysis team to do this work concurrently

with developing the requirements.

Factors to Consider When Planning for Traceability

How do you decide whether a spreadsheet is good enough for tracking

requirements traceability? It really depends on how complicated you think

your requirements traceability will be. You should think about the following

factors as part of your decision-making process:

Number of Requirements Generally, complex projects have more

requirements, which generate a greater need for a traceability tool. In

complex systems, business analysts must strive to limit the traceability

information that is maintained to a usable and reasonable set of data. The

more requirements you have, the more relationships there tend to be

between those requirements. This may make maintaining traceability in a

spreadsheet difficult and point you toward a more sophisticated

requirements management tool that uses a database to relate the

requirements to one another.

Estimated System Lifetime The longer a system or solution will be used

within an organization, the greater the need for traceability using either a

tool or a spreadsheet. This will assist the team in evaluating the impacts of

changes to the operational solution. You also need to consider whether the

system is critical or noncritical to daily operations.

Level of Organizational Maturity Traceability tools are easier to

207

acquire and use when your requirements development and project

management processes are mature. Acquiring a new requirements

management tool at the beginning of a major requirements development

effort is bad timing. It will be difficult for the business analysis team to learn

to use the new tool and to do their requirements development work

simultaneously.

Selecting Relationships to Trace Key dependencies and relationships

between requirements should be recorded so they can be traced across the

project life cycle. Creating and maintaining this information assists the business

analyst in sequencing project work activities to design and deploy the

capabilities found in the requirements. It also assists the business analyst in

correctly allocating requirements to solution components. The following are

types of relationships to consider:

Derive. Derivation is the backward traceability of a requirement to its

higher-level parent. An example of derivation is when a solution

requirement is derived from a business or stakeholder requirement.

Depends. A dependency relationship exists between two requirements

when the requirements depend upon one another in some way. There are

two types of dependency: necessity and effort. Necessity is when it makes

sense to implement one requirement only when another requirement is also

implemented. Effort is when a requirement is easier to implement when a

related requirement is also implemented.

Satisfy. The satisfy relationship exists between a requirement and a

solution component. Essentially, the solution component satisfies the

associated requirement.

Validate. This relationship exists between a requirement and the test case

or other method that validates or proves the solution fulfills the

requirement.

Palmer Divide Vineyards: Concerns Over Elapsed Study Time

You are a team member at Palmer Divide Vineyards, currently defining the

IT requirements for a new green initiative. You have been assigned the task

of tracing the requirements in a particular requirements package. During

your review of the set forward and backward traceability matrices, you

notice the following stakeholder requirements:

SH1: Users will perform research studies.

SH2: Users will customize the contents of their research studies.

The children of these stakeholder requirements are the more detailed

solution requirements, which are traced back to their parents.

208

SH1 traces forward to one solution requirement:

S1: The system will calculate elapsed study time.

SH2 traces forward to two solution requirements:

S2: The system will allow creation of custom data queries.

S3: The system will accept customized user study data.

While you are looking at requirement S1, you find yourself wondering if the

elapsed study time will be calculated for all studies, both standard and

customized. The traceability matrix led you to this question, and you make a

note to clarify it with the involved stakeholders at your earliest opportunity.

Clarifying this concern during requirements development could save the

project team the rework costs downstream if this requirement is interpreted

incorrectly in the solution design and implementation.

Traceability Repository Traceability is usually achieved by putting the

requirements in a table, spreadsheet, or tool to manage the tracing activities.

Although traceability can be done manually using a spreadsheet, complex

projects often require a more streamlined approach. Many business analysts

prefer to use a requirements management tool or a configuration management

system to trace large numbers of requirements.

Implementing traceability for project requirements demands work from the

business analysis team, but it’s worth the effort. Traceability is used for many

things on a project. For example, traceability allows the business analyst to

thoroughly evaluate the impacts of a change request to both the requirements

and the solution components. In another example, tracing requirements back to

the business needs shows the business analyst how those objectives will be

accomplished. This also allows the business analyst to confirm that all the

business needs are included in the solution scope and the solution components.

In one last example, traceability allows the business analyst to trace the subset

of requirements that are allocated to each of the solution components.

Techniques to Consider

The BABOK

Guide lists some additional techniques that can be used when

tracing requirements. They are summarized for you here:

Business Rules Analysis This technique can be used to trace business rules

to the requirements that the business rules support. The technique also works in

a different direction, tracing business rules that support requirements.

Functional Decomposition Break down solution scope into smaller

components for requirements allocation. Requirements allocation assigns

requirements to be implemented by a specific solution component or

components. Functional decomposition is also used to trace high-level

components to lower-level components.

Process Modelling Process models visually show the future state process.

These models allow the business analyst to trace requirements to that future

209

state process.

Scope Modelling Scope models visually depict the scope and allow the

business analyst to trace requirements to the area of the scope that the

requirement supports.

Business analysts select which techniques they will apply as part of tracing

requirements. There is no need to use all of these techniques, so choose wisely.

Let’s take a look at the outputs result from applying your selected techniques to

this task.

Produce the Traced Requirements

Traced requirements have clearly defined relationships to the other

requirements and designs within the solution scope. Traceable requirements are

used by the business analyst to identify the effects on other requirements of a

requirements change or of a planned implementation.

Once the relevant stakeholders approve the requirements or designs, they are

used as inputs to another task in the Requirements Life Cycle Management

knowledge area, defining the design options. Table 4.3 summarizes these

outputs.

TABLE 4.3 Outputs: Trace requirements.

Output Output

Destinations

Destination Knowledge Area

Requirements

(traced)

Define design

options.

Requirements Analysis and Design

Definition

Designs (traced) Define design

options.

Requirements Analysis and Design

Definition

Business analysts have the primary responsibility for creating and managing

requirements traceability for their projects, particularly during requirements

development activities. The project managers are also part of this effort, as they

use traceable requirements to support the project-level change management

activities. Several business analysis stakeholders also have a need for traceable

requirements, including the following:

Customers

Domain subject matter experts (SMEs)

End users

Implementation SMEs

Operational support

Sponsor

Suppliers

Testers

210

Producing the traced requirements is an interim and necessary step in creating

the approved requirements for a project. Traced requirements are strongly

recommended as an accompaniment to the approved requirements for your

project. Let’s take a look at another aspect of producing project requirements:

maintaining requirements for reuse on future projects and initiatives.

Maintain Requirements

Requirements can and will change on your projects, even while the

requirements are being developed. Maintaining requirements focuses on the

current requirements for your project, as well as possibly reusing some of those

requirements on other projects and initiatives downstream. Requirements are

maintained so they stay current and correct across the project life cycle,

particularly after an approved change.

Some requirements developed for a particular project might also be candidates

for long-term use or reuse by the organization. The requirements that you

choose to maintain might relate to infrastructure, hardware, software, or

operational capabilities that the organization must meet on an ongoing basis

versus just for your particular project.

Requirements that can be reused on other projects must be named, defined, and

easily available to other business analysts in the organization. These

requirements are stored and managed in a requirements repository. Some

organizations save and maintain all ongoing, operational requirements to assist

support and maintenance teams in evaluating possible impacts of changes to the

deployed solutions and systems.

Figure 4.3 summarizes the inputs, outputs, techniques, and associated tasks for

maintaining requirements.

FIGURE 4.3 Task summary: Maintain requirements.

Several inputs are needed to maintain reusable requirements and designs while

211

a project is ongoing and after that project is complete. These key inputs are

produced by other business analysis tasks and include the requirements

themselves. Here is a closer look at these inputs:

Requirements Requirements that are maintained for reuse typically describe

the current state of an organization and the systems and solutions that are being

used to address a business need.

Designs Designs that are maintained for reuse also describe the current

systems and solutions that are being used. They can be maintained across their

life cycle.

Let’s also take a look at the guidelines and tools that may be used as inputs to

the maintaining requirements task:

Information Management Approach The business analyst’s approach for

managing requirements reuse is defined as part of the information management

approach during Business Analysis Planning and Monitoring activities.

Table 4.4 summarizes the inputs, guidelines, and tools used by the task and lists

their source (if applicable).

TABLE 4.4 Inputs: Maintain requirements for reuse.

Task Input Input

Type

Input Source Source Knowledge

Area

Requirements Input

Designs Input

Information

management

approach

Guidelines

and tools

Plan business analysis

information

management.

Business Analysis

Planning and

Monitoring

Business analysts need to step through three task elements to maintain and

potentially reuse requirements. These elements are as follows:

Maintain requirements.

Maintain attributes.

Reusing requirements

Let’s look at each of these elements now.

Maintain Requirements Maintained requirements and designs are correct,

up-to-date and available across the business analysis life cycle as well as the

project life cycle. The business analysis team is responsible for keeping

requirements current and correct while they are being developed and when a

change is requested and approved.

Maintain Attributes It is not enough to just keep the requirements for your

project up-to-date and available. The requirements attributes that were elicited

along with those requirements also need to be maintained. Typical attributes

collected during requirements elicitation include the requirements source,

priority, and complexity. Remember that requirements attributes may change

212

over time while the requirement itself stays the same.

Reusing Requirements Maintained and retrievable requirements can be

reused across multiple projects or initiatives. Reusable requirements are those

that the organization must meet on a continuous basis, such as contractual

obligations, quality standards, business processes, or service level agreements

(SLAs). The organization may have to prove that the ongoing, operational

requirements are met by the deployed solution.

Requirements that are met or satisfied by a deployed solution should be

maintained as long as the business stakeholders need them. This can be a great

help in getting future product enhancements and system changes done and

done well.

Exam Spotlight

Unapproved or unimplemented requirements might also be maintained for

later use on future projects or initiatives.

Techniques to Consider

The BABOK® Guide recommends several techniques that can be used as part of

maintaining reusable requirements. Here is a look at those techniques:

Business Rules Analysis Business rules that are similar across the enterprise

may be helpful in identifying requirements that are candidates for reuse on

other projects and initiatives.

Data Flow Diagram Look for information flow that is similar across the

enterprise. This consistent data may indicate requirements that are candidates

to be maintained and reused.

Data Modelling Just like data flow, data structures that are similar or

consistent across the enterprise may be pointing to requirements that are

candidates for reuse.

Document Analysis Playing detective and analyzing existing documentation

at the enterprise level may assist you in discovering requirements that may be

maintained and reused on other projects and initiatives.

Functional Decomposition When performing functional decomposition to

break something down into more detailed pieces and parts, be sure to look for

requirements associated with lower-level components of the solution that can be

reused.

Process Modelling Process modelling gives a window into the requirements

associated with the processes that might be candidates for reuse.

Use Cases and Scenarios Use cases and scenarios can help identify solution

components that can be reused by more than one solution.

213

User Stories User stories can be used to identify requirements associated with

the story being told that may be available for reuse as part of another solution.

Business analysts select which techniques they will apply as part of maintaining

requirements. Now let’s take a look at the outputs resulting from applying your

selected techniques to maintaining requirements.

Produce Maintained Requirements

Maintained and reusable requirements and designs often become part of the

organizational process assets (OPAs) and the enterprise architecture of an

organization. These requirements should be formatted and suitable for long-

term or future use by the organization. Table 4.5 summarizes the output from

this task and its destinations.

TABLE 4.5 Output: Maintain requirements.

Output Output

Destinations

Destination Knowledge

Area

Requirements

(maintained)

Designs (maintained)

As a business analyst, you have the primary responsibility for formatting and

storing maintained and reusable requirements and designs after your project is

complete. It is likely that these requirements will be used by a different business

analyst at a future date, so you should make sure that the requirements are

accessible and easily understood. Several other business analysis stakeholders

also have a need for reusable and maintained requirements, including the

following:

Domain SMEs

Implementation SMEs

Support

Regulators

Testers

Reusable and maintained requirements are not always produced on every

project. The only requirements that you should consider for this task are those

that the organization must meet on a continuous basis or those that are needed

by business stakeholders. Let’s look at another essential task in producing

project requirements: prioritizing requirements.

Prioritize Requirements

Requirements prioritization determines the relative importance of requirements

in order to gain maximum value to each other and to implement the overall

solution scope. Ranking the requirements by their importance to stakeholders is

the way most business analysts perform this task.

214

There are many ways to prioritize requirements. The requirements

prioritization scheme needs to be planned and defined for the business analysis

team prior to eliciting requirements information at any level of detail. The

priority of a specific requirement or group of requirements may alter over time

as the context and level of detailed knowledge changes.

A Must-Do Requirements Stew

Phil was asked to finish up a project that had languished in the

requirements development stage for years. The project approach was to

procure a commercial product to provide the required capabilities and

customize that product as needed. Contributing departments had gold

plated the project requirements to such an extent that there were no

commercial products that came close to meeting the defined needs of the

business. The solution scope had expanded from meeting a single unit’s

business need to addressing multiple business processes across

departments and organizations.

All efforts to focus on the set of core functionality required to meet the

original business need came to naught. Phil got the key users together and

attempted to prioritize the existing requirements set. No one would back

down from ranking their requirements at the highest priority, regardless of

the prioritization method Phil invoked. They tried forced ranking with no

success. They tried voting with even less success. They stuck dots on the

wall, they used sticky notes, they time boxed, and they budgeted. To add to

the confusion, the marketing department (a key player) consistently refused

to state any clear requirements other than needing total flexibility to react to

changes in the marketplace.

Phil discovered that sometimes the people creating the requirements are

incapable of objectively prioritizing the features they have spent time

dreaming up. He also found that his key stakeholders had difficulty

distinguishing between the core functionality and the optional features of a

solution. As Phil discovered, working on projects where the key stakeholders

have identified more requirements than can be economically implemented

is a serious challenge, indeed.

How did Phil solve this conundrum? He couldn’t solve it this time around. It

was impossible for any single software product on the market to meet this

diverse set of requirements stew. The project issues were escalated to senior

management, and eventually the project was scrapped. However, Phil

learned many lessons on prioritizing requirements and dealing with

stakeholders; he applied these successfully to future projects. Sometimes

the best business analysis lessons are the painful and unsuccessful ones.

Just try to keep those lessons to a minimum.

215

Figure 4.4 summarizes the inputs, outputs, guidelines, tools, techniques, and

associated tasks used to prioritize requirements. Remember, requirements

prioritization is a consultative and ongoing process. Your stakeholders play a

key role in prioritizing the requirements and should make the final decision on

which new solution capabilities are most important to them as well as which

capabilities are absolutely required to get the job done.

FIGURE 4.4 Task summary: Prioritize requirements.

Two inputs are used when prioritizing requirements or designs.

Requirements To prioritize requirements defining stakeholder needs and

capabilities, a business analyst needs to have those requirements available.

Requirements ready for prioritization can be in the form of text, matrices, or

diagrams.

Designs To prioritize any designs associated with the solution, business

analysts need to have those designs on hand in the form of text, prototypes, or

diagrams.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Guidelines are essentially instructions or descriptions on

why and how a business analyst will undertake a task. Tools are methods for

conducting a business analysis task or shaping a task output. Here is a look at

the guidelines and tools that can also be used as inputs when prioritizing

requirements:

216

Business Constraints Requirements priorities should align with the

regulatory statutes, contractual obligations, and business policies of the

enterprise. These constraints may drive the priority of one or more

requirements.

Change Strategy The change strategy documents costs, timelines, and value

realization goals that can factor into prioritizing requirements to meet these

planned goals and measures.

Domain Knowledge Stakeholders with specific domain knowledge contribute

a lot of value to requirements prioritization activities. Their knowledge and

experience are indispensable.

Governance Approach The governance approach, built during Business

Analysis Planning and Monitoring, defines the approach for the business analyst

to take on the project when prioritizing requirements.

Requirements Architecture The requirements architecture defines the

relationship of requirements to other requirement and work products.

Requirements Management Tools/Repository Many requirements

management tools include a data field for specifying requirements priorities.

This field prompts the business analyst to prioritize the requirement and assists

in sorting and searching the requirements for the project by priority.

Solution Scope The solution scope should be kept front and center when

prioritizing requirements in order to deliver the full solution in the end.

Table 4.6 summarizes the inputs, guidelines, and tools used by this task. It also

lists the task and knowledge area sources for each item used to prioritize

requirements.

TABLE 4.6 Inputs: Prioritize requirements.

Task Input Input

Type

Input Source Source Knowledge

Area

Requirements Input

Designs Input

Business constraints Guidelines

and tools

Change strategy Guidelines

and tools

Define change

strategy.

Strategy Analysis

Domain knowledge Guidelines

and tools

Governance approach Guidelines

and tools

Plan business

analysis

governance.

Business Analysis

Planning and

Monitoring

Requirements

architecture

Guidelines

and tools

Requirements Guidelines

217

management

tools/repository

and tools

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

When prioritizing the requirements on your projects, you should perform

several task elements, such as the following:

Defining the basis or criteria for prioritizing requirements

Considering challenges of prioritization

Address continual prioritization

Let’s look at each of these elements in greater detail.

Defining the Basis for Requirements Prioritization A number of

prioritization schemes and approaches can be used, such as prioritization based

on looking at which requirements should be implemented first in a solution. The

BABOK

Guide provides you with eight factors to consider when determining

the basis for requirements prioritization, either standalone or in combination

with one another. Table 4.7 summarizes these eight factors for prioritizing

requirements.

TABLE 4.7 Requirements prioritization factors

Prioritization

Factor

Requirements Are Prioritized to . . .

Benefit Provide the most business value and meet business goals

and objectives.

Penalty Minimize the negative consequences of not implementing

a specific requirement.

Cost Force stakeholder awareness of the implementation cost

of requirements.

Risk Spend time early on risky or difficult components to make

sure the solution can be delivered.

Dependencies Implement requirements that depend upon one another

at the same time.

Time Sensitivity Yield quick or certain successes relative to adding value to

the business.

Stability Avoid implementing unstable requirements until they are

better defined and understood.

Regulatory or

Policy Compliance

Address regulatory or policy requirements.

Considering Prioritization Challenges Facilitating a session to prioritize

requirements can be quite challenging. There is a tendency for stakeholders to

issue nonnegotiable demands relative to the importance of their requirements,

such as ranking all of their requirements as the most important requirements of

218

the bunch (whether they really are or not). The problems aren’t confined to the

stakeholders, though. It is not unusual to find the solution development team

trying to influence the prioritization results, perhaps because they have some

interesting technology they would like to implement. The facilitator must

recognize and focus on the need for trade-off decision making and compromise

in a session that takes on these characteristics.

Continual Prioritization Requirements priorities can be a moving target

over time as more information becomes available. As the requirements are

defined in greater detail, initial assigned priorities may need to be revisited and

revised. The basis for prioritization also changes over time. Initial priorities

based upon business benefits may be reprioritized based upon technical

constraints and the order of implementation or the cost of the requirements.

There are several techniques that you can choose to apply when prioritizing your

project requirements. The technique that we recommend is the prioritization

technique, which covers a range of ways to prioritize requirements. Let’s take a

look at this recommended technique in greater detail.

Recommended Technique: Prioritization

The prioritization technique is a catchall for several approaches to prioritizing

requirements. The priorities may be based on risk, value, implementation

difficulty, or other criteria. The four approaches are grouping, ranking, time

boxing/budgeting, and negotiation. The selection of approach is up to the

business analyst team and may change to fit the current situation and the needs

of the stakeholders. Business analysts may find themselves using one or more

approaches to prioritize their project requirements. Let’s step through each

approach in more detail.

Grouping This common prioritization approach classifies requirements or

business analysis information according to predefined categories, such as high,

medium, and low, or the Must, Should, Could, and Won’t categories of MoSCoW

analysis. Grouping helps you to reach a common understanding with your

stakeholders on the importance they place on the delivery of each requirement.

Requirements might move between prioritization groups as you iteratively apply

the technique and discuss your options with key stakeholders.

Ranking Ranking orders the requirements or business analysis information

from what is most important to what is least important. Ranking can be

explicitly sequenced to create a product backlog of requirements in an ordered

list. One recommendation is to rank your requirements so that 25 percent of

those requirements are Must, 25 percent of the requirements are Should, 25

percent are Could, and the remaining 25 percent are Won’t. If these percentages

don’t work for you, you can select numbers that fit your project and your set of

requirements to prioritize.

Time Boxing/Budgeting Time boxing/budgeting prioritizes requirements for

implementation based on the allocation of a fixed resource, usually either time

(time boxing) or money (budgeting). This technique is most effective when it is

framed by the defined solution scope for the project.

219

Negotiation This approach requires establishing consensus among the

involved stakeholders regarding the prioritized requirements. Conflict

management and negotiation skills can be used to encourage the group to reach

consensus.

When using any of these approaches to prioritize requirements, remember that

one or more requirements might be redefined, deleted, or added to the set. Over

time, the prioritized list of requirements might change based on new

information and insight.

Additional Techniques to Consider

The BABOK

Guide recommends using one or more of the following additional

techniques when you are prioritizing requirements for your project. They are

summarized for you here:

Backlog Management Ranked requirements are often stored in a product

backlog consisting of prioritized requirements in an ordered list. This backlog

can be used to compare requirements to be prioritized.

Business Cases The business goals and objectives found in the business case

are used to determine the importance of requirements during the prioritization

process.

Decision Analysis You can use this technique to examine and model the

consequences of different decisions before actually making a well-informed

decision. When prioritizing project requirements, business analysts can use

decision analysis to identify and assess high-value requirements.

Estimation Cost estimates are often used as the basis for requirements

prioritization. This can occur early in the prioritization process or later when

solution implementation specifics are being considered.

Financial Analysis These techniques can be used to assess the financial value

of a set of requirements and to look at how implementation timing can impact

that value.

Interviews Business analysts use interviews to understand how individual

stakeholders or small stakeholder groups want to prioritize requirements.

Item Tracking Item tracking allows for tracking of any issues raised by

stakeholders during prioritization activities.

Risk Analysis and Management Risky requirements often need to be

investigated further to determine what should be done with them. Some

organizations prefer to implement risky requirements early on to minimize the

costs of failure, while others prefer to defer risky requirements until later in the

life cycle in order to decide what to do with them.

Workshops Business analysts use workshops to understand the basis for how

larger stakeholder groups want to prioritize requirements.

Once you have selected and applied one or more techniques as part of your

requirements prioritization efforts, you are ready to continue with some of the

other analysis tasks at hand. We will discuss those tasks shortly.

220

Produce the Prioritized Requirements

Prioritized requirements and prioritized designs are requirements that have

been assigned a priority attribute indicating their relative importance to the

stakeholders and to the organization. Sometimes you will find yourself assigning

a priority value to a group of related requirements as opposed to a single,

standalone requirement. Once you have prioritized your requirements, it is time

to assess the risks inherent to those requirements. The prioritized stakeholder

and solution requirements are used as an input to the Assess Risks task in

Strategy Analysis, as summarized in Table 4.8.

TABLE 4.8 Outputs: Prioritize requirements.

Output Output

Destinations

Destination Knowledge

Area

Requirements

(prioritized)

Assess risks. Strategy Analysis

Designs (prioritized) Assess risks. Strategy Analysis

A number of stakeholders are involved with prioritizing stakeholder and

solution requirements. Remember that the primary responsibility for

prioritizing requirements is shared between the business analyst and the key

stakeholders who are involved as part of the requirements prioritization

process.

Several key business analysis stakeholders should also be involved in

prioritizing requirements. The project manager uses your prioritized

requirements during the implementation planning efforts. Other stakeholders

participating in requirements prioritization include the following:

Customer

Domain SME

End user

Implementation SME

Regulator

Sponsor

Let’s take a look at the next task found in the Requirements Life Cycle

Management knowledge area—assessing and evaluating the implications of

proposed changes to requirements and designs.

Assess Requirements Changes

One thing is certain when it comes to developing requirements—at some point

in time, those requirements are going to change. Ideally, the changes are

handled in a consistent, formal fashion by using a change request to initiate the

process of assessing and decision making. This task is performed when a

221

proposed change identifies new needs or possible solutions to those needs. The

proposed change must be assessed before action is taken to approve, deny, or

modify the request.

Business analysts view proposed requirements and design changes relative to

the solution value, the current set of requirements, and the level of risk.

Experienced business analysts should ask the following questions when

assessing a proposed change. Does the proposed change:

Align with the overall strategy?

Affect the value delivered to the business or the stakeholders?

Impact the timeline or resources required to deliver the value?

Alter any risks, opportunities, or constraints?

The answers to these questions drive the outcome of assessing the proposed

change. When assessing a proposed change, remember to use the decision-

making and change control approaches defined in the governance approach that

was created by the task Plan Business Analysis Governance as part of Business

Analysis Planning and Monitoring.

A Cat in the Hat Moment: Phase 1 and Phase 2

Phil, a business analyst, had a lot of fun with a recent project in his

organization. The sales department decided that the company was lagging

hopelessly behind other retail establishments because they forced their

customers to physically sign a paper contract when purchasing services.

“After all,” they protested, “even Walmart lets you sign on an electronic

pad.” “We must have electronic contracts!” said the business side of the

house.

And the eContract project was born.

Phil and his team started working to determine the project requirements

and define just what should, could, and must be delivered. It was an

entertaining project. Operational questions were ignored. Legal constraints

were ignored. All attempts to define eContracts in detail turned to dust.

Group-focused meeting invitations went unanswered. Private meetings

yielded conflicting and contradictory requirements.

However, at every executive management review or chance encounter in the

hallways, Phil was asked, “Why is IT late on eContracts?”

In a last-ditch effort to deliver, Phil divided the project into Phase I and

Phase II. Phase I included building the storage and retrieval backbone for

contract images along with a method to scan the backlog of all existing

paper contracts into a new database. The requirements were developed,

222

communicated, and approved with executive management, and the project

work began.

Right about the time that Phase I was developed and ready for beta testing,

Phil was told that none of the business sponsors would accept the project in

phases. They needed to get the entire thing, Phase I and Phase 2 (kind of

like Thing 1 and Thing 2 from The Cat in the Hat). On the heels of this

revelation, Phil heard in passing that another department had taken the

same challenge and had fully developed eContracts using a PDF form

methodology. Never mind that it didn’t offer any storage, retrieval, or

integration with the sales tools. It was complete, and it was ready to rock ‘n’

roll.

Of course, the next question for Phil was how to integrate this new

eContracts PDF form methodology with the existing systems? Effective

impact analysis when assessing requirements changes can truly be an art

form.

Figure 4.5 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks for assessing requirements changes on a project.

FIGURE 4.5 Task summary: Assess requirements changes.

Several key inputs are used to assess requirements changes during a project.

These inputs are produced by other business analysis tasks.

223

Proposed Change A proposed change to requirements or designs can occur at

almost any time and impact the business analysis work and deliverables

completed to date. Triggers for proposed changes include business strategy

changes, stakeholders, legal requirements, or regulatory changes.

Requirements Business analysts assess the requirements relative to a

proposed change in order to identify and quantify the impact of that change.

Designs The more solution-focused designs are also assessed relative to a

proposed change in order to identify and quantify the impact of that change and

the modifications that will be made if the change takes place.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Here is a look at the guidelines and tools that can also be

used as inputs when assessing requirements changes:

Change Strategy The change strategy describes the purpose of changes and

establishes a context and direction for the changes on a project or initiative. It

also identifies the critical components for change.

Domain Knowledge Stakeholders with specific domain knowledge contribute

a lot of value to assessing proposed requirements changes.

Governance Approach The governance approach, built during Business

Analysis Planning and Monitoring, defines the approach for the business analyst

to take on the project when making decisions and dealing with change control.

Legal/Regulatory Information Legislative rules or regulations may also

impact a proposed change on a project. They must be considered when

assessing requested changes to requirements.

Requirements Architecture The requirements architecture defines the

relationship of requirements to other requirement and work products. This

architecture should be used when assessing the impacts of proposed changes to

the requirements.

Solution Scope The solution scope should be considered when assessing

proposed changes to requirements in order to fully understand the impacts of a

proposed change.

Table 4.9 summarizes the inputs, guidelines, and tools used by the task and lists

the source of the input (if applicable).

TABLE 4.9 Inputs: Assess requirements changes.

Task Input Input

Type

Input Source Source Knowledge

Area

Proposed change Input

Requirements Input

Designs Input

Change strategy Guidelines

and tools

Define change

strategy.

Strategy Analysis

Domain Guidelines

224

knowledge and tools

Governance

approach

Guidelines

and tools

Define business

analysis governance.

Business Analysis

Planning and Monitoring

Legal/regulatory

information

Guidelines

and tools

Requirements

architecture

Guidelines

and tools

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

Business analysts step through three essential elements as they assess a

proposed change to requirements or designs. These three elements are as

follows:

Determine the change assessment formality.

Perform an impact analysis.

Provide impact resolution for the proposed change.

Here we step through each of these elements in more detail:

Determining Change Assessment Formality Methods for assessing and

deciding upon requirements changes range from the very informal to formal

requests complete with committees to consider whether the requests are

worthwhile. Determining the level of formality depends upon the information

available, the importance of the change, and the business analysis governance

approach defining change control for requirements and designs.

Predictive approaches to projects often use formal methods to assess and

determine the merits of requirement and design changes. Changes in projects

using predictive approaches to planning can cause major rework of tasks and

activities that were previously completed. In contrast, adaptive approaches to

project planning often require less change assessment formality because of their

iterative and incremental approach to getting work done.

Performing an Impact Analysis Impact analysis is done to assess or

evaluate the impacts of a proposed change to requirements or designs.

Traceability allows the business analyst to look at the impact of the change

relative to related requirements and solution components. The impacts of

changing existing requirements should be assessed across the five areas found

in Table 4.10.

TABLE 4.10 Areas of impact for changing requirements

Area What to Look For

Benefit Benefits to be gained by accepting the change

Cost Total costs to implement the change

Impact Number of customers or business processes affected

Schedule Impact to existing delivery commitments

225

Urgency Level of importance of the change

Providing Impact Resolution Business analysts follow the methods defined

in the governance approach when making decisions about proposed changes on

their projects. Based upon the approach, key stakeholders may be authorized to

approve, deny, or defer a proposed change. Typically, the results of the impact

analysis are documented and communicated to all stakeholders.

When considering the total costs of approving and implementing

a proposed change, be sure to look at the cost to make the change, the cost

of any associated rework resulting from the change, and any opportunity

costs such as other features that might be sacrificed or deferred if the

change is approved.

Techniques to Consider

The BABOK

Guide recommends that you select from a number of techniques

when assessing a proposed change to requirements or designs. Let’s step

through these techniques now, since you should make yourself familiar with all

of them.

Business Cases A business case is often used to justify a proposed change.

Business cases are particularly relevant when looking at the benefits to be

gained by accepting the proposed change to requirements or designs.

Business Rules Analysis This technique is used during impact analysis to

trace business rules to the requirements that the business rules support. The

technique also works in a different direction and can be used to trace the

business rules that support requirements.

Decision Analysis Decision analysis facilitates the change assessment process

by examining and modelling the possible consequences of different actions. This

helps the business analyst decide whether to approve, deny, or defer a proposed

change to requirements or designs.

Document Analysis Use document analysis to analyze existing documents to

help you understand the possible impacts of a proposed change to the

requirements or designs.

Estimation Estimating the cost and effort to implement a proposed change is a

necessary step in impact analysis. Estimation is an iterative process where the

act of review and revision takes place as more information is known over time.

Financial Analysis This technique estimates the financial consequences of a

proposed change to requirements or designs. Consequences include financial

viability, stability, and benefit realization.

Interface Analysis Interface analysis identifies interfaces that can be affected

by a proposed change to requirements or designs. This technique looks at

226

where, what, why, when, how, and for whom information is exchanged between

solution components or across solution boundaries.

Interviews Business analysts use interviews to talk with individuals and small

groups of stakeholders in order to understand the impact of the change on the

organization or its assets.

Item Tracking Item tracking or issue management tracks any issues or

conflicts that were discovered during impact analysis activities.

Risk Analysis and Management Risk analysis and management techniques

determine the level of risk associated with a proposed change as part of impact

analysis activities.

Workshops Workshops allow groups of stakeholders to collectively discuss

and understand the impacts of a proposed change or decide what to do about

one or more proposed changes.

Assessing Requirements Changes

A Requirements or Designs Change Assessment is the output of this task. This

assessment contains a recommendation to approve, modify, or deny a proposed

change to either area based upon the results of the impact analysis. Table 4.11

summarizes these outputs.

TABLE 4.11 Outputs: Assess requirements changes.

Output Output

Destinations

Destination Knowledge

Area

Requirements change

assessment

Designs change assessment

Business analysts have the primary responsibility for assessing requirements

and design changes as part of requirements development activities on a project.

The project manager reviews the requirements or design change assessment to

see what impact the change might have on the solution. Other stakeholders

involved in assessing requirements changes include the following:

Customer

Domain SME

End user

Operational support

Regulator

Sponsor

Tester

Assessing requirements changes and deciding what to do about them occurs

throughout the project life cycle. Let’s take a look at another aspect of producing

227

project requirements: approving the requirements.

Approve Requirements

Much of the work that you perform as part of the Requirements Life Cycle

Management knowledge area gets your project requirements organized and

structured appropriately. After they are in good shape, you can share them with

key stakeholders for their review, understanding, and approval. This final task

holds you responsible for communicating, obtaining agreement on, and getting

approval of the requirements and designs. After receiving approval, business

analysis work can proceed or actual solution construction can begin.

Requirements communication tends to be iterative and ongoing in nature. It is

usually done in parallel with most of the other business analysis tasks found in

the BABOK

Guide. Requirements communication can be formal or informal in

nature and includes conversations, notes, documents, presentations, and

discussions with your stakeholders.

Approval of requirements and designs may also be formal or informal.

Predictive approaches usually perform approvals of requirements and designs at

the end of project phases or during change control meetings. On the flip side,

adaptive approaches approve requirements when construction and

implementation of the solution meeting the requirements are ready to be done.

Figure 4.6 summarizes the inputs, outputs, techniques, and associated tasks for

effectively communicating your project requirements.

FIGURE 4.6 Task summary: Approve requirements.

Several key inputs are used when approving requirements during a project.

These inputs are produced by other business analysis tasks. Here is a closer look

228

at these inputs:

Requirements (Verified) Verified requirements provide a set of

requirements that are of sufficient quality to be used as a reliable body of work

for further specification and development.

Designs This set of designs is ready to be used for further specification and

development.

Additional inputs that can be used by business analysis tasks include guidelines

and tools. Here is a look at the guidelines and tools that can also be used as

inputs when approving requirements:

Change Strategy The strategy provides information that helps manage

stakeholder consensus regarding stakeholder needs.

Governance Approach A governance approach identifies stakeholders who

have the authority and responsibility to approve business analysis information,

the approval process, and their alignment to organizational policies.

Legal/Regulatory Information This information describes the legislative

rules or regulations that must be followed and may impact the approval process.

Requirements Management Tools/Repository A tool such as this

documents requirements approvals.

Solution Scope Business analysts assess scope when approving requirements

to accurately assess alignment and completeness.

Table 4.12 summarizes the inputs, guidelines, and tools to the business analysis

task of approving requirements and lists the source of the input (if applicable).

TABLE 4.12 Inputs: Approve requirements.

Task Input Input

Type

Input Source Source Knowledge

Area

Requirements

(verified)

Input Verify requirements. Requirements

Analysis and Design

Definition

Designs Input

Change strategy Guidelines

and tools

Define change

strategy.

Strategy Analysis

Governance approach Guidelines

and tools

Plan business

analysis governance

approach.

Business Analysis

Planning and

Monitoring

Legal/regulatory

information

Guidelines

and tools

Requirements

management

tools/repository

Guidelines

and tools

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

229

You need to perform the elements that are part of this task in order to

communicate and gain approval of the project requirements by key

stakeholders. The four elements are as follows:

Understand stakeholder roles.

Address conflict and issue management.

Gain consensus.

Track and communicate approval.

Let’s step through each of these elements now:

Understand Stakeholder Roles The approval process for proposed changes

to requirements or designs is defined in the business analysis governance

approach. Stakeholder roles and authority levels in this process must be defined

and understood. It is essential to know who has the decision-making and sign-

off authority. Look for influential stakeholders that should be consulted or

informed about the changes, as well. These influencers can help with

communicating and gaining consensus about the changes that are proposed.

Address Conflict and Issue Management Maintaining stakeholder

support for a change to requirements or designs can be challenging. The

BABOK

Guide recommends seeking consensus for the change among

stakeholders prior to requesting that they approve and sign-off on the change.

The business analysis governance approach built during Business Analysis

Planning and Monitoring defines how to make decisions about changes and

resolve any conflicts that arise.

Gain Consensus Approval requires a business analyst to review requirements

changes with accountable stakeholders and request that they agree to and

approve that change. Often, this process requires facilitation of the approval

process, addressing questions and providing additional information as needed.

Approving a change confirms that stakeholders believe the change creates

sufficient value for the organization.

Track and Communicate Approval Formal requirements communication

follows the contents of the business analysis governance approach when it

comes to dealing with proposed changes. Informal communication takes place

whenever it is needed. Business analysts record the change approval decisions,

often using requirements management tools.

Stakeholders should be able to see what requirements and design changes are

approved and in the queue for implementation. Many projects require an audit

history of changes to requirements. Be sure to document what was changed, the

business analyst who made the change, the reason for the change, and when the

change was made.

Exam Spotlight

230

According to the BABOK® Guide, conflict resolution and issue management

occurs frequently during the change approval process. This occurs when the

business analyst reviews requirements and designs and aims to secure a

sign-off on proposed changes.

Techniques to Consider

The BABOK

Guide recommends five techniques to use when approving

requirements with your stakeholders. Here is a summary of each technique:

Acceptance and Evaluation Criteria Stakeholders and decision-makers

define acceptance and evaluation criteria in order to make decisions regarding

proposed requirements and designs changes.

Decision Analysis Decision analysis allows you to examine and model the

consequences of different decisions before making a well-informed decision.

When resolving issues and evaluating proposed changes, business analysts use

decision analysis to resolve issues and gain agreement.

Item Tracking Item tracking allows tracking of any issues raised by

stakeholders during the agreement and approval activities.

Reviews Reviews are used to evaluate requirements and designs relative to a

proposed change.

Workshops Requirements workshops are structured meetings where a

selected group of stakeholders works together to define or refine a set of project

requirements. During a requirements workshop, specific requirements may be

presented to make everyone familiar with the existing solution scope and the

current requirements.

Once you have applied one or more of the recommended techniques and gained

approval of your requirements, those requirements are now approved

requirements. Remember that communicating requirements ensures that the

stakeholders understand what they have been told.

Approving Requirements with Your Stakeholders

Remember that proposed changes to requirements and designs are not just

communicated from the business analyst to the stakeholders. They must be

received, understood, and acknowledged by those stakeholders in order for

effective requirements communication to have taken place. Table 4.13 shows

this output trail.

TABLE 4.13 Outputs: Approve requirements.

Output Output

Destinations

Destination Knowledge

Area

Requirements

(approved)

Designs (approved)

231

The business analyst has the primary responsibility for ensuring that proposed

changes to requirements and designs are analyzed, communicated, and

approved during the requirements development activities on a project. In

tandem, the project manager identifies and manages the risks associated with

the approved changes. Additional stakeholders involved with approving

requirements include the following:

Customers

Domain SMEs

End users

Operational support

Regulators

Sponsor

Testers

Remember that all business analysis stakeholders may have a role in this task

and could be involved with requirements approval activities across the project

life cycle. At a minimum, they may be a sender or a receiver of the

communicated requirements information.

232

How This Applies to Your Projects

In this chapter, you stepped through tasks that help you to manage changing

requirements across the requirements life cycle. One of the biggest challenges

that you encounter on your projects is managing changing requirements.

Sometimes it takes no more than five minutes after requirements sign-off to

start hearing the inevitable changes creeping back into what was just approved.

This can be caused by a number of factors.

Increased level of interaction and information sharing both within and

between systems

Lack of requirements traceability yielding poor understanding of

requirements dependencies

Changes in business plans and objectives that create a high-level focus shift

and impact your existing requirements

Changes in technology, law, policies, regulations, or directives

Boundary conditions and constraints that move, causing your requirements

to change as well

Customers and users who change their minds about what they need

Developers who add their own special twists, creating undocumented

features that come back to haunt us

Configuration management (CM) is the key to managing changing

requirements. Effective issue and change management is possible only if it is

supported by CM. Configuration management is a technical and administrative

activity focusing on creating, maintaining, and controlling change to the

solution and its components (a configuration) throughout that solution’s life

cycle.

All organizations should have a configuration management strategy for their

projects. The strategy can be developed on a project-by-project basis or be

applied to all projects that the organization undertakes. The configuration

management strategy identifies how, and by whom, the project’s products will

be controlled and protected. It answers these questions:

How and where will the project’s products be stored?

What storage and retrieval security will be put in place?

How will the products and the various versions and variants of these

products be identified?

How will changes to products be controlled?

Where does responsibility for configuration management lie?

A configuration management strategy is typically derived from a number of

information sources, including any corporate configuration management,

quality management, or information management systems and strategies.

233

Typically, the strategy is based on either the user’s or the supplier’s quality

management systems and is targeted to support meeting the customer’s quality

expectations. The specific needs of the solution and the environment where it is

being developed also plays a part in this strategy, as does the project

management team structure with its identified configuration management roles

and responsibilities.

To control and protect your solution and its assets, use a configuration

management strategy focusing on the solution and the solution components of

your project. This is the best way to provide a framework ensuring that your

solution deliverables are identified, tracked, and protected. The five generic

steps are illustrated in Figure 4.7: Plan, Identify, Control, Account, Verify. Let’s

take a quick look at each step.

FIGURE 4.7 A framework for configuration management

Plan Configuration management planning defines how you will address

storage, retrieval, security, version control, and change control for the solution

deliverables. The timing for these activities should also be defined.

Identify Identification encompasses specifying and identifying all components

of the final product. This is where you would create unique identifiers and

records for each solution component.

Control Configuration control invokes the ability to approve and baseline

deliverables. Changes to approved products can be made only by following the

formal change procedure for the solution.

Account Status accounting is the recording and reporting of all current and

historical data concerning each deliverable or configuration.

Verify The project’s configuration management system should provide you

with the ability to audit actual deliverables against information recorded about

those deliverables in the system, such as current status.

234

Summary

The five tasks of the Requirements Life Cycle Management knowledge area

guide the business analyst in effectively managing requirements changes and

communicating requirements to stakeholders across the project life cycle. One

of the primary roles of the business analyst is developing and managing

requirements across the project life cycle. Effective communication skills are an

underlying competency enabling the business analyst to do this work. Successful

projects start with defining and agreeing to what is needed. Without the ability

to make these requirements understood, you will find it difficult to perform your

job well.

The BABOK

Guide recommends that business analysts plan for managing

changing requirements and designs before the real project work gets started.

This information can be found in the business analysis governance plan, which

was built as part of the Business Analysis Planning and Monitoring knowledge

area. The same holds true for effectively communicating about changing project

requirements to the stakeholders. This information was also planned for and is

located in the governance approach.

Most of the deliverables produced in the Requirements Life Cycle Management

knowledge area focus on adding details to the stakeholder, solution, and

transition requirements as specific actions are taken by the business analysis

team.

235

Exam Essentials

Be able to list the tasks found in the Requirements Life Cycle

Management knowledge area. On your exam, you will see questions about

the tasks, their associated techniques, their more detailed elements, and the key

outputs they produce. You should memorize the five tasks of this knowledge

area and any key outputs or techniques associated with them. The tasks are as

follows:

Trace requirements.

Maintain requirements.

Prioritize requirements.

Assess requirements changes.

Approve requirements.

Be able to discuss how requirements are transformed by the tasks in

this knowledge area. The key deliverables produced by the tasks in this

knowledge area focus on actions being taken to communicate project

requirements to your stakeholders and manage any changes to those

requirements. Luckily, the task name directly gives away the state of the

requirements after the task is successfully performed. Here’s a quick summary:

Approve requirements yields the approved requirements.

Trace requirements yields the traced requirements.

Maintain requirements yields the maintained and reusable requirements.

Prioritize requirements yields the prioritized requirements.

Be able to explain the difference between adaptive and predictive

approaches when assessing proposed changes. Adaptive approaches

may require less formality in assessing proposed changes. By their iterative and

incremental nature, adaptive approaches minimize the impact of changes. This

continuous evolution approach to implementation may reduce the need for

formal impact assessment. In contrast, predictive approaches may require a

formal assessment of proposed changes. Changes can generate a serious rework

of tasks, activities, and deliverables that were previously complete.

Be able to list and describe the five areas for assessing the impact of

a proposed change to requirements. Five areas should be considered when

considering changes or additions to existing requirements:

Benefit

Cost

Impact

Schedule

Urgency

236

Be familiar with the factors that influence requirements

prioritization. Numerous factors may influence how requirements are

prioritized on a project. Typical factors include the following:

Benefit

Penalty

Cost

Risk

Dependencies

Time sensitivity

Stability

Regulatory or policy compliance

Be able to list and describe the five common traceability

relationships between requirements. These relationships may be tracked

and recorded during and after requirements development:

Derive

Depends/Necessity

Depends/Effort

Satisfy

Validate

237

Key Terms

This chapter stepped through the contents of the third knowledge area from the

BABOK® Guide: Requirements Life Cycle Management. Most of this knowledge

area focuses on effectively managing changes and communicating about

requirements during the requirements development phase of a project.

You should understand how to apply the techniques and tasks in this knowledge

area in order to be an effective business analyst. Additionally, you will need to

know the five tasks and their associated elements and techniques from this

knowledge area in order to be successful on the CBAP

or CCBA

™

exams. The

tasks include the following:

Trace requirements.

Maintain requirements.

Prioritize requirements.

Assess requirements changes.

Approve requirements.

Several new key words in Chapter 4 relate to managing changes and

communicating requirements on a project. Here is a list of some of the key

terms that you encountered in this chapter:

dependency

derivation

grouping, ranking, time boxing/budgeting, and negotiation

impact analysis

maintained requirements

product backlog

requirement’s lineage

requirements traceability

reusable requirements

reuse

satisfy

238

Review Questions

1. Which Requirements Life Cycle Management task seeks approval and sign-

off on requirements or designs?

A. Obtain requirements sign-off.

B. Communicate requirements.

C. Approve requirements.

D. Assess requirements changes.

2. Which document determines how the business analyst obtains approval of

business analysis information with their stakeholders?

A. Business analysis approach

B. Project management plan

C. Change strategy

D. Governance approach

3. What stakeholder is responsible and accountable for the project scope?

A. Project sponsor

B. Business analyst

C. Project manager

D. Process owner

4. The BACCM™ states that the business analyst is responsible for extending

value beyond the current initiative they are working on. This is done by:

A. Ensuring the solution meets the business need

B. Analyzing content of the current enterprise

C. Maintaining requirements and designs for reuse

D. Managing and evaluating proposed changes

5. Which of the following business analysis work products must be traceable to

a business requirement?

A. Solution and stakeholder requirements

B. Other requirements and designs

C. Solution components and scope

D. Business rules and objectives

6. Three business analysis deliverables are inputs to several Requirements Life

Cycle Management tasks. They are used to influence and guide the business

analyst in managing requirements. Which of the following deliverables is not

one of the three inputs?

239

A. Governance approach

B. Information management approach

C. Change strategy

D. Business analysis approach

7. You are defining the traceability approach for your requirements. You want

to make sure that the business analysis team traces the relationship between

functional requirements and the solution components that implement those

requirements. This is an example of which traceability relationship?

A. Satisfy

B. Derive

C. Validate

D. Depends

8. You are a business analyst tasked with ensuring that stakeholders with

approval authority agree about the requirements that the solution should

meet. You are most likely performing tasks from which knowledge area?

A. Business Analysis Planning and Monitoring

B. Strategy Analysis

C. Requirements Life Cycle Management

D. Solution Evaluation

9. Which of the following techniques can be applied when tracing

requirements?

A. Data flow diagrams

B. Use cases and scenarios

C. Functional decomposition

D. Decision analysis

10. What states of requirements outputs are contained in the Requirements Life

Cycle Management knowledge area tasks?

A. Analyzed, allocated, traced, and confirmed

B. Traced, maintained, prioritized, and approved

C. Stated, analyzed, unconfirmed, and verified

D. Approved, analyzed, prioritized, and traced

11. What is another name for an organized peer-level review of a requirements

document?

A. Business rules analysis

B. Brainstorming session

C. Focus group

240

D. Requirements workshop

12. Requirements that are intended for reuse reflect what view of the

organization?

A. Enterprise level

B. Current state

C. Ongoing operations

D. Future state

13. When prioritizing requirements, which prioritization factor takes into

account the likelihood that a requirement will change?

A. Penalty

B. Benefit

C. Stability

D. Dependency

14. Which guideline or tool is used during requirements prioritization to

understand the relationship with other requirements and work products?

A. Business constraints

B. Solution scope

C. Governance approach

D. Requirements architecture

15. The business analyst receives input from a stakeholder regarding the

impacts of technical dependencies on a specific stakeholder requirement.

Which stakeholder is most likely to be providing this input?

A. Domain SME

B. Implementation SME

C. Project manager

D. Operational support

16. When defining your approach to requirements traceability on your project,

what levels will you choose from when deciding how to trace the

requirements?

A. Business, stakeholder, or solution

B. Capability, conditions, or constraints

C. Individual, model, or feature

D. Requirements, components, or artifacts

17. The requirements life cycle begins with the representation of a business need

as a requirement. When does the requirements life cycle end?

A. When a solution representing the requirements is retired

241

B. After the solution representing the requirements is developed

C. Once the solution representing the requirements is implemented

D. When the operational solution meets the business need

18. You are a business analyst assessing a proposed change to a set of

requirements. Your project is being developed in an adaptive fashion with

iterative and incremental implementation techniques. How might you

handle your impact analysis?

A. Impact analysis must be informal.

B. Impact analysis must be formal.

C. Impact analysis may be informal.

D. Impact analysis may be formal.

19. What is the basis for requirements life cycle management during a project,

ensuring that proposed requirements support business needs?

A. Business case

B. Business need

C. Solution scope

D. Desired outcome

20. All of the following are elements of the approve requirements task except:

A. Capabilities and processes

B. Understand stakeholder roles

C. Track and communicate approval

D. Conflict and issue management

242

Chapter 5

Controlled Middle: Elicitation and Collaboration

CBAP®/CCBA™ EXAM TOPICS COVERED IN THIS CHAPTER:

Prepare for elicitation.

Conduct elicitation activity.

Confirm elicitation results.

Communicate business analysis information.

Manage stakeholder collaboration.

Business analysts elicit the necessary information to develop

their business, stakeholder, solution, and transition requirements for their

projects. The five tasks in the Elicitation and Collaboration knowledge area

guide you in gathering and understanding what the project stakeholders need

from a new solution. Remember that effective elicitation is not just asking

questions. It is a human-based activity in which you determine the right sources

for your requirements and decide how to gather the right information from

those sources. Elicitation is very much like a scientific investigation. You will

find yourself actively engaged in research, reading, talking, and observing what

is going on in the organization as it relates to your project requirements.

Elicitation includes organizing and evaluating the results to make sure you have

well-organized information, the right level of knowledge, and a good handle on

the scope and status of your elicitation efforts.

243

Requirements Elicitation

The Elicitation knowledge area focuses on gathering the right information to

develop project requirements. The requirements for your project are the

foundation for a solution that will be designed and deployed by the project and

its efforts. Elicitation is defined as “drawing forth or receiving of information

from stakeholders or other sources.” Collaboration is defined as “the act of two

or more people working together towards a common goal.”

Requirements elicitation can be very challenging. When working with your

stakeholders to define requirements, you are often faced with stakeholders who

express those requirements in their own terms. You must learn to speak the

stakeholders’ language in order to understand the capabilities that are being

described. Stakeholders don’t always tell you everything that you need to know,

at least not the first time around. Elicitation techniques must be selected to

gather as much relevant information as quickly as possible.

Requirements elicitation is performed for all types of requirements found in the

BABOK

Guide: business, stakeholder, solution, and transition. Elicitation is

performed for your project’s high-level business requirements as well as your

more-detailed solution requirements. The tasks in the Elicitation and

Collaboration knowledge area are performed in parallel with other requirements

development tasks from the following knowledge areas:

Strategy Analysis (business requirements)

Requirements Analysis and Design Definition (stakeholder and solution

requirements)

Solution Evaluation (transition requirements)

Strategy Analysis, Requirements Analysis and Design Definition,

and Solution Evaluation

Be sure you know which of the three knowledge areas are involved directly

with requirements development work and how they relate to the elicitation

efforts that we discuss in this chapter.

Strategy Analysis Strategy Analysis focuses on identifying the business

needs that drive a project and defining a feasible solution scope that can be

implemented by the business. This knowledge area includes developing the

business requirements for a project that define the high-level goals,

objectives, and needs of the organization, and the high-level business

functionality needed in the resulting solution.

Requirements Analysis and Design Definition Requirements

Analysis and Design Definition steps you progressively through elaborating

244

and prioritizing the stakeholder and solution requirements for a project.

Stakeholder requirements define the needs of stakeholders and how they

will interact with a solution. They act as a bridge between high-level

business requirements and more-detailed solution requirements. In turn,

the solution requirements describe the solution characteristics that are

needed to meet the higher-level business and stakeholder requirements.

Solution Evaluation Solution Evaluation assesses and validates the

proposed, in progress, and implemented solutions before, during, and after

the project life cycle. This is also where the project’s transition requirements

are defined. Transition requirements define the solution capabilities

required to transition from the current to a future state. They are no longer

needed once the transition is complete.

The Elicitation and Collaboration knowledge area also addresses monitoring

and reporting on the performance of the elicitation activities throughout the

project. The business analysis team is responsible for assessing the effectiveness

of the techniques being used to elicit requirements. The Elicitation and

Collaboration knowledge area is addressed in Chapter 4 of the BABOK

Guide.

To focus on what is important to business analysts across the life cycle of their

business analysis efforts, let’s consider the tasks of this knowledge area with the

framework of the BACCM™. Business analysts need to keep an eye on their

work relative to the six concepts contained in the framework: changes, needs,

solutions, stakeholders, values, and contexts. Table 5.1 lists these

responsibilities.

TABLE 5.1 The BACCM™: Elicitation and Collaboration

Core

Concept

The Business Analyst’s Responsibilities

Change Use a variety of elicitation techniques to fully identify the

characteristics of the change and any stakeholder concerns about

the change.

Needs Elicit, confirm, and communicate needs and supporting business

analysis information over time.

Solution Elicit, confirm, and communicate necessary or desired

characteristics of proposed solutions.

Stakeholders Manage collaboration with stakeholders participating in the

business analysis work.

Value Collaborate with stakeholders to assess the relative value of

elicitation information in order to confirm and communicate that

value.

Context Apply various elicitation techniques to identify business analysis

information about the context that may affect the change.

You must learn to judge when you have elicited and acquired enough

requirements information to start documenting and analyzing what you have

245

learned. Experienced business analysts find themselves moving between

requirements elicitation, requirements analysis, and requirements

documentation activities many times on their projects. This is very much like

the wand on a metronome, moving left to right to left again in order to keep the

beat for the music being played.

The Business Analyst’s Task List

You have five tasks to perform in the Elicitation knowledge area. We will cover

each one of these tasks in detail later in this chapter. The task list from the

BABOK

Guide includes the following:

Preparing for requirements elicitation

Conducting the elicitation activity

Confirming the elicitation results

Communicating business analysis information

Managing stakeholder collaboration

These tasks focus on obtaining the right information from the right sources in

order to develop the right requirements for your project. Remember, effective

requirements elicitation in your projects is multifaceted and requires the

following:

The right sources

The right information

The right technique

Clear organization

Evaluation and understanding

Accurate reporting

If requirements elicitation is done correctly, the dividends that get paid

downstream in the project life cycle can be tremendous. It is like a series of

interlocking puzzle pieces. The correct project requirements lead to an

appropriate solution design. When the solution design is implemented and

deployed, the requirements are still framing the work effort, keeping the team

on track to meet the project stakeholder’s needs and expectations.

When Does Elicitation Take Place?

I have noticed that even people who claim everything is predetermined and

that we can do nothing to change it, look before they cross the road.

—Stephen Hawking

The tasks in the Elicitation and Collaboration knowledge area begin early in the

project life cycle and typically peak during the more detailed requirements

development phase of the project. Requirements can be elicited at any point in

246

the project life cycle. Typically, you elicit information for the first time early in

the project life cycle. You will also find yourself eliciting information to clarify

things you have missed or misinterpreted along the way. Changing

requirements also trigger additional elicitation efforts later in the project life

cycle.

Don’t underestimate the importance of the work that gets done by these five

tasks on your projects. Without the right requirements information from the

right people, your project will probably not succeed. Let’s step through the first

task in the Elicitation and Collaboration knowledge area: preparing for a

particular elicitation effort or activity.

Exam Spotlight

Approximately 12 percent (18 questions) of the 150 question-CBAP® exam

questions focus specifically on Elicitation and Collaboration. On the CCBA™

exam, 20% (30 questions) focus on this knowledge area. The exam

questions target specific and detailed aspects of the five tasks found in this

knowledge area.

Prepare for Elicitation

The first task in the Elicitation and Collaboration knowledge area is where you

prepare a detailed schedule of your elicitation activities. Your elicitation

activities can include interviewing an individual face-to-face, creating a survey

to send out to a thousand worldwide end users, or facilitating a group workshop

of 15 people. Your preparation work should include the following:

Defining the desired outcome for the elicitation activity

Determining the work product or products to be produced

Deciding the techniques to be used to produce the results

Establishing the elicitation logistics

Identifying supporting materials that are needed

Planning to foster collaboration during the elicitation activity

This preparation step ensures that the necessary stakeholder resources are

organized and scheduled in advance. This step also allows you to get all of your

ducks in a row—from meeting room logistics to required materials to attendance

and attention from the right people. Figure 5.1 summarizes the inputs,

guidelines and tools, outputs, techniques, and associated tasks used to prepare

for requirements elicitation.

247

FIGURE 5.1 Task summary: Prepare for elicitation.

Several key inputs are needed to adequately prepare to elicit requirements

information on your project. These key inputs are produced by a number of

other business analysis tasks, and they include the needs and the stakeholder

engagement approach. Let’s take a look at each of these task inputs in greater

detail:

Needs The business needs define the problem or opportunity being faced by

the business. This information is used to determine the information to be

elicited when developing business requirements early in the project life cycle.

Elicitation is also used to discover and flesh out these needs early in your

project.

Stakeholder Engagement Approach Planning and preparing for elicitation

requires an understanding of how your stakeholders communicate and

collaborate. The stakeholder engagement approach is a good place to start when

you are ready to elicit business analysis information.

There are additional inputs that can be used during business analysis tasks:

guidelines and tools. Guidelines are essentially instructions or descriptions on

why and how a business analyst will undertake a task. Tools, on the other hand,

are methods for conducting business analysis tasks or shaping a task output.

Let’s take a look at the guidelines and tools that can also be used as inputs when

preparing for elicitation:

Business Analysis Approach The business analysis approach is a “one-stop

shop” for the general strategy used to guide business analysis work on your

project. The approach contains stakeholder information, any business analysis

methodologies to be used, a high-level schedule, and the level of detail you will

248

be looking for in your resulting requirements and designs.

Business Objectives Requirements elicitation efforts focus on defining

business capabilities to achieve a desired, future state. The direction these

capabilities need to take is found in the business objectives.

Existing Business Analysis Information Existing information should not

be overlooked during your requirements elicitation efforts. This information

ranges from existing project documentation to requirements development

methods you can use to understand the business.

Potential Value Be sure you understand and can articulate the value to be

realized when the proposed future state is implemented.

Table 5.2 summarizes the inputs, guidelines, and tools for this task and lists the

source of each input (if applicable).

TABLE 5.2 Inputs: Prepare for elicitation.

Task Input Input

Type

Input Source Source Knowledge

Area

Needs Input

Stakeholder

engagement

approach

Input Plan stakeholder

engagement.

Business Analysis

Planning and

Monitoring

Business analysis

approach

Guidelines

and tools

Plan business

analysis approach.

Business Analysis

Planning and

Monitoring

Business objectives Guidelines

and tools

Define future

state.

Strategy Analysis

Existing business

analysis information

Guidelines

and tools

Potential value Guidelines

and tools

Define future

state.

Strategy Analysis

When preparing to elicit requirements information across the project life cycle,

the business analyst should perform several elements, including the following:

Understanding the scope of elicitation

Selecting the elicitation techniques

Planning the logistics of the elicitation

Securing any supporting materials

Preparing the stakeholders

Let’s step through each of these five elements now:

Understanding Elicitation Scope Successful business analysts don’t have

time to waste eliciting information about topics that are outside of the scope of

their defined effort. That said, it is important to understand the scope of the

249

future solution as well as focus on the exact boundaries of the information you

plan to elicit in a particular elicitation activity.

Selecting Elicitation Techniques Typically, multiple techniques are used to

elicit business analysis information. Business analysts are responsible for

choosing the right techniques and applying those techniques correctly. When

selecting elicitation techniques, look for techniques you have used in similar

situations, techniques that are suited to the current situation, and the tasks

necessary to use each selected technique properly.

Planning Elicitation Logistics Be sure to plan the logistics of your elicitation

session ahead of time. In addition to creating an agenda for the session, the

BABOK

Guide recommends that you identify the goals for the activity and

provide a list of participants and their roles. Participants will also want to know

the session location, the session schedule, and the tools and techniques that will

be used.

Securing Supporting Materials Business analysts are responsible for

identifying and procuring supporting materials needed for an elicitation activity.

Required information may include specific people and what they know, or

documented data about existing systems. There may be other elicitation results

or analysis models from different facets of your project that are also needed.

Preparing Stakeholders Stakeholder understanding and buy-in is essential

to successful elicitation. Many times, stakeholders are asked to review

supporting materials prior to the elicitation activity. It is helpful to make sure

your stakeholders understand the techniques you are using and the outcome the

group is seeking.

Exam Spotlight

There are ways to add value when preparing for requirements elicitation on

your projects. You should take the time to agree with the involved

stakeholders about how you will provide them with feedback, verify the

information, and then request their sign-off as you agree on the elicitation

results. You should also make certain that you establish the ground rules up

front for dealing with individuals and groups during the scheduled

elicitation activities.

There are several techniques that you can choose to apply when preparing to

elicit project requirements. One technique that we recommend is

brainstorming, a creative, structured way to get everyone’s brain contributing

ideas as you plan what needs to take place and who needs to be involved. Let’s

take a look at this recommended technique in greater detail.

Recommended Technique: Brainstorming

Brainstorming fosters creative thinking about the capabilities of a new solution

250

across all levels of detail. Brainstorming enables out-of-the-box thinking in a

nonjudgmental environment. Out-of-the-box thinking is also called lateral

thinking.

Using brainstorming as an elicitation technique produces numerous new ideas

from the people involved. If you haven’t used brainstorming as part of your

requirements elicitation efforts, you should try it. You can draw on the

experience and creativity of the participants in your brainstorming session,

yielding a plethora of interesting and relevant results that require further

analysis.

A productive brainstorming session has two parts: idea generation and idea

reduction. Idea generation is the creative part where people share their ideas

with one another, no matter how off the wall those ideas might be. Idea

reduction is where the group takes the generated ideas and cleans them up a bit

to make the information useful for the situation at hand.

Preparing for a brainstorming session involves defining the session itself,

including the particular area of interest for the session and the amount of time

that will be spent by the participants. A longer brainstorming session is needed

for larger groups of people. The ideal brainstorming session contains six to eight

people.

Other logistics need to be determined prior to the session start. The session’s

facilitator and participants need to be selected. Expectations for the session

should also be defined, focusing on the area of interest. The evaluation and

rating criteria for the idea reduction step should also be set and agreed to in

advance.

Over the years, we have found that the success of a brainstorming

session depends on the willingness of the participants to actually participate

and contribute. It is essential that ideas not be debated during idea

generation in order to maximize contributions from the group. Personal

feelings and organizational politics need to be set aside during the session in

order to achieve the best results.

Once the ideas are generated and recorded, they need to be analyzed and

reduced to something useful. Wrapping up is where the idea reduction part of a

brainstorming session takes place. The group discusses and evaluates ideas

using the evaluation and rating criteria that were previously defined and agreed

upon by the group as part of the meeting. Combining some ideas, deleting some

ideas, and eliminating any duplicate ideas will build a condensed list. The

resulting list will then be distributed to the appropriate parties for review.

Additional Techniques to Consider

There are many additional techniques to choose from when you find yourself

251

preparing to elicit business analysis information on your projects. Let’s step

through each of them here.

Data Mining This technique helps you to identify information or patterns from

existing data that require further investigation during your planned elicitation

activity.

Document Analysis Use document analysis to analyze existing documents

and supporting materials that might be helpful as part of the requirements

elicitation process.

Estimation Estimating the cost and effort to elicit business analysis

information gives you a good idea of just what needs to be done and what

getting the work done will take.

Interviews Business analysts use interviews as part of elicitation preparation

so they can identify concerns about the planned elicitation and seek authority to

proceed when necessary.

Mind Mapping Mind mapping is a visual, nonlinear, collaborative way to

discover the sources of business analysis information that you need and which

elicitation techniques might be most effective in a given situation.

Risk Analysis and Management Risk analysis and management techniques

determine the level of risk associated with eliciting business analysis

information. Elicitation plans may be designed or changed to eliminate or

minimize significant risks.

Stakeholder List, Map, or Personas This stakeholder data is used to

determine who should be consulted during elicitation preparation and who

should be involved with the actual solicitation activity.

Once you have selected and applied one or more techniques as part of your

preparation efforts, you are ready to plan the elicitation activity itself. We will

discuss that next.

Produce the Elicitation Activity Plan

The elicitation activity plan defines both the logistics and scope of a specific

elicitation activity. The logistics for the elicitation activity include the scheduled

resources and the supporting materials. The scheduled resources are exactly

what they sound like—the people, facilities, and equipment that you need for

requirements elicitation. The resource schedule should include the resource

name or names, the location of the elicitation activity, and anything else that

might be needed.

Supporting materials are anything that you need in order to perform the

elicitation activity. These materials could be required for a particular elicitation

technique, such as having a whiteboard available for a requirements workshop.

252

Palmer Divide Vineyards Elicitation Worksheet

The IT staff at the vineyard has a long history of projects that don’t go

according to plan. Almost every effort is over budget and behind schedule.

The team has been assessing their current project practices in order to

achieve more successful results. Taylor, the head of IT, has decided that this

has gone on for long enough. She is determined to put project management

processes in place that enable better project outcomes and less rework.

One area of weakness is the team’s approach to requirements development.

In the past, senior management has been reluctant to allot much time for

defining what needs to be done. They ask, “When will you guys be doing the

real work and producing something useful?”

For the research study project, Taylor and the team have defined a simple

requirements development process that they plan to follow. Senior

management has agreed to allot them the extra time to define requirements

before the design and coding efforts begin.

One step in Taylor’s process is requirements elicitation. She believes that

gathering the right information from the right folks makes all the difference.

Even though the vineyard is a small company, there are many opinions on

what needs to be done and what is most important. Taylor hopes to harness

that information and target defining high-quality requirements for this and

every subsequent project.

Taylor and the team have decided to plan their elicitation efforts thoroughly.

They are using an information-gathering worksheet to document the

questions they want to ask and the methods they want to use to gather that

information. The team plans to ask the same question more than once and

to organize the results by question for further analysis and decision making.

Taylor is correct in assuming that this will be the first step in a more robust,

well-planned requirements elicitation effort at Palmer Divide Vineyards.

Business analysts often like to use a worksheet to plan their elicitation efforts

and get a handle on the questions they will be asking. Table 5.3 provides an

example of a requirements elicitation worksheet populated for a round of

solution requirements elicitation at Palmer Divide Vineyards. You can use

questions and apply techniques, as shown here, or add additional information to

your worksheet based on your organization and the nature of your project.

TABLE 5.3 Palmer Divide Vineyards elicitation worksheet

Palmer Divide Vineyards Green Project

Objective: Get stated solution requirements from stakeholders about the

research study capabilities of the new system.

Approach: We will interview people individually and then follow up with a

requirements workshop to discuss the results of this elicitation session.

Elicitation Questions Whom to Ask Technique(s) to

Apply

253

1. What current research

study activities do you

currently perform?

Hector (marketing

director) Sawyer (vineyard

manager) Dan

(winemaker, SME) Ginger

(product manager) Taylor

(IT manager)

Interviews (individual)

Requirements workshop

(entire group) Document

analysis of existing

capabilities Observation

2. What are your job

responsibilities?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements workshop

(entire group)

3. What are the most

important activities the

new research study

capabilities should

address?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements workshop

(entire group)

4. What is the

prioritization of your

research study needs?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements Workshop

(entire group)

5. If you could change

two or three things

about your existing

research study activities,

what would you change?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements workshop

(entire group)

6. What better, new, or

different information do

you need to perform

research studies for the

vineyard?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements workshop

(entire group)

7. What system

functionality do you

use? Not use?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements Workshop

(entire group)

8. What capabilities do

you think the new

solution should provide

for others? Why?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements workshop

(entire group)

9. What activities will

you perform using the

new solution?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements workshop

(entire group)

10. From your point of

view, what are the key

new requirements for

the research study

aspects of the solution?

Why?

Hector, Sawyer, Dan,

Ginger, Taylor

Interviews (individual)

Requirements workshop

(entire group)

An elicitation worksheet helps you define your elicitation activity objectives and

254

allows you to prepare your questions ahead of time and review them. By

thinking through your questions and documenting them in this way, you are

also setting the basis for organizing your elicitation results.

Once you have completed your elicitation preparation, it is time to go get the

information that you need from your stakeholders. Table 5.4 shows the outputs

from your elicitation preparation activities that you will use to get the work

done.

TABLE 5.4 Output: Prepare for elicitation.

Output Output Destinations Destination Knowledge

Area

Elicitation activity

plan

Conduct elicitation. Elicitation and Collaboration

Confirm elicitation

results.

Elicitation and Collaboration

As a business analyst, you are responsible for adequate requirements elicitation

preparation. On large projects, this responsibility often falls to the collective

members of the business analysis team, who will be simultaneously eliciting

requirements information from different stakeholders. Be sure to coordinate

who is doing what, when, and make sure you plan to sit down and accumulate

what everyone has learned. Any business analysis stakeholder can be involved in

requirements elicitation. The project manager, domain SMEs, and the project

sponsor may also be involved in the elicitation prep work.

Now, let’s take a look at the next step in effective requirements elicitation—

successfully conducting the elicitation activity.

Conduct Elicitation

There are a number of ways to elicit requirements for your projects. The most

common elicitation technique is a face-to-face meeting with one or more of your

project stakeholders to gather information regarding their needs. However,

elicited information doesn’t have to come directly from people. It can also come

to you indirectly, based on your research and review of existing documents and

other data.

Exam Spotlight

The BABOK® Guide lists three common types of elicitation: collaborative,

research, and experiments. Make sure you can recognize each type of

elicitation for the exam.

Collaborative elicitation involves direct interaction with stakeholders

and relies on their experiences, expertise, and judgment.

Research involves systematically discovering and studying information

255

from materials or sources not directly known by stakeholders involved in

the change, such as analyzing historical data trends.

Experiments involve identifying information that could not be known

without some kind of controlled test, using observational studies, proofs

of concept, and prototypes.

Stakeholders may collaborate during elicitation by participating in the actual

elicitation activity or by researching, studying, and providing feedback on

documents, systems, models, and interfaces related to the activity and its

results.

Figure 5.2 summarizes the inputs, outputs, techniques, and associated tasks

used to conduct requirements elicitation.

FIGURE 5.2 Task summary: Conduct elicitation activity.

Several key inputs, guidelines, and tools are needed when eliciting requirements

information. The primary input to this task is the planning you did in the

previous task when preparing for elicitation.

Elicitation Activity Plan The elicitation activity plan defines both the

logistics and scope of a specific elicitation activity. The logistics for the

elicitation activity include the scheduled resources and the supporting

materials. This plan was created by the Prepare for Elicitation task in the

Elicitation and Collaboration knowledge area that we just covered in the

previous section.

There are additional inputs that may be used by business analysis tasks:

guidelines and tools. Let’s take a look at the guidelines and tools that may also

256

be used as inputs when conducting elicitation:

Business Analysis Approach The business analysis approach is a “one-stop

shop” for the general strategy used to guide business analysis work on your

project. The approach contains stakeholder information, any business analysis

methodologies to be used, a high-level schedule, and the level of detail you will

be looking for in your resulting requirements and designs.

Existing Business Analysis Information Existing information should not

be overlooked during your requirements elicitation efforts. This information

ranges from existing project documentation to requirements development

methods you can use to understanding the business.

Stakeholder Engagement Approach This approach provides the business

analyst with stakeholder preferences for collaboration and communication that

may be helpful when eliciting information.

Supporting Materials These materials are used to prepare the business

analysis team and the stakeholders prior to an elicitation activity and may be

reviewed prior to the event. Supporting materials also include information,

tools, or equipment used as part of the elicitation itself.

Table 5.5 summarizes the inputs, guidelines and tools to this elicitation task and

lists the source of each input (if applicable).

TABLE 5.5 Inputs: Conduct elicitation.

Task Input Input

Type

Input Source Source Knowledge

Area

Elicitation activity

plan

Input Prepare for

elicitation.

Elicitation and

Collaboration

Business analysis

approach

Guidelines

and tools

Plan business

analysis approach.

Business Analysis

Planning and

Monitoring

Existing business

analysis information

Guidelines

and tools

Stakeholder

engagement

approach

Guidelines

and tools

Plan stakeholder

engagement.

Business Analysis

Planning and

Monitoring

Supporting materials Guidelines

and tools

There are several elements that you should perform when eliciting project

requirements information across the project life cycle, including the following:

Guiding the elicitation activity

Capturing elicitation outcomes

Let’s look at each element in greater detail:

Guide Elicitation Activity Experienced business analysts follow their

elicitation plan to navigate the actual elicitation activity. This approach keeps

257

things on track by focusing on gathering business analysis information at the

required level of detail. Remember that things can change once elicitation is

underway; being flexible and adaptable relative to your elicitation plan is also an

essential skill. Keep an eye out for when you have gathered enough information.

Capture Elicitation Outcomes Eliciting requirements is an iterative and

incremental activity. Elicitation outcomes are captured and integrated into the

planned outcomes and what the business analysis team already knows.

Recording business analysis information during elicitation is essential for later

reference, integration, and use.

The BABOK

Guide contains numerous elicitation techniques that you should

be able to use as needed. Each technique is an excellent way to elicit

requirements. The technique you choose should be the best fit for the situation

that you find yourself in. For instance, scheduling telephone interviews with 100

individual users is not time effective. Building a survey/questionnaire to send to

them combined with a requirements workshop for a selected subset of senior or

key users may be a better approach to gathering information.

There are several techniques that you may choose to apply when prioritizing

your project requirements. Two techniques that we recommend for eliciting

requirements are focus groups and prototypes. Let’s take a look at these

recommended techniques in greater detail.

Recommended Technique: Focus Groups

Focus groups provide you with an interactive group environment to elicit ideas

and attitudes from selected stakeholders about a product, service, or

opportunity. The work done in a focus group may be similar to a brainstorming

session, but a focus group is a more structured event. Focus groups are a form of

qualitative research in which your participants are prequalified to address a set

of questions about a particular topic.

Getting Things in Focus

Ginger was assigned the task of eliciting business requirements for the

senior management team of an overseas bank. She enjoyed her trip across

the ocean and really looked forward to facilitating several focus group

sessions that targeted the definition of and the agreement to the business

requirements for developing a new IT system. Ginger believed this was

going to be an interesting and rewarding consulting assignment. She was

right.

The initial focus group session kicked off mid-morning on Tuesday. Ginger,

in her role as moderator, arrived early to make sure the room was arranged

correctly and that all required materials were available to share with the

258

attendees. She made certain that the room was arranged in the traditional

U-shape that many facilitators prefer. This arrangement would allow Ginger

to facilitate effectively by walking the inside of the tables to make points,

clarify issues, and minimize any conflicts.

This particular group was a heterogeneous set of vice presidents from the

numerous operating units at the bank. The discussion guide for this session

focused on the high-level business drivers justifying the project and the big-

picture capabilities that would be required. Everyone arrived pretty much

on time, dressed for success. The coffee was poured into lovely ceramic

mugs with the bank logo on them, breakfast treats were selected,

introductions were made, and the focus group was off and running.

About an hour into the session, it became apparent to Ginger (and everyone

else in the room) that two of the vice presidents had conflicting opinions

about the definition of the new system capabilities. They were sitting right

across the tables from one another. Voices were rising, and the conflict

began to escalate. Ever the well-trained facilitator, Ginger walked briskly

down the tables in order to physically stand between them and shut down

their conflict.

Just as Ginger stepped between them, one of the angry vice presidents

threw his coffee cup across the table right at the other fellow. Alas, that

coffee cup never got to the other fellow—it hit Ginger in the face. The room

went very still as the cup fell to the floor. Ginger knelt down, picked up the

cup, and stood back up.

“Well,” she said, “Let’s get on with things, shall we?”

She then moved on to the next topic in her discussion guide.

Funny thing, there were no more conflicts in that particular focus group.

Even funnier, there were no conflicts in the sessions that followed. The

business requirements for the project were defined and agreed upon, and

the project was off and running. After she got back home, Ginger found

herself wondering if it was her strong facilitation skills that made those

focus groups go so very well or if it was her black eye that got everyone’s

undivided attention during the rest of the week.

Focus group preparation requires you to select and recruit the right participants

for the session. The BABOK

Guide recommends a focus group size of 6 to 12

attendees. A moderator and a recorder for the session should also be assigned

ahead of time. It is essential that your focus group be guided by a trained

moderator. In many organizations, the trained moderator is the business

analyst. The moderator creates a discussion guide defining the goals and

objectives of the session and five or six questions to be discussed. The focus

group location and any necessary technical services also need to be set up in

advance.

The focus group should be conducted in a one-to-two-hour session. The

moderator is responsible for guiding the discussion using the discussion guide

as a road map. The recorder is responsible for capturing the group’s comments.

259

It is not advisable for the moderator to be the recorder—it is quite difficult to

facilitate a focus group and take notes at the same time. An alternative is to

make audio and/or video recordings of the focus group.

Focus groups may contain homogeneous or heterogeneous

participants. Homogeneous participants all have similar characteristics;

heterogeneous participants have diverse backgrounds. For example, a

homogeneous focus group may consist of key end users who deal with the

order entry aspect of the business, discussing the order entry capabilities for

a new solution. A heterogeneous focus group would be one with a cross

section of end users from all aspects of the business being present to discuss

those very same order entry capabilities from multiple perspectives.

After the session is complete, the moderator is responsible for analyzing and

documenting the session results. A key output is group themes and perspectives.

This captures agreements, as well as disagreements, in the areas being

discussed. The moderator produces the report and sends that report to key

stakeholders, business analysts, or marketing staff.

Recommended Technique: Prototyping

Prototyping is a great way to add detail to your solution interface requirements

and integrate those requirements with the other requirements defining the new

solution. Essentially, a prototype is an initial or preliminary version of a solution

or system.

Prototypes are extremely valuable for identifying, describing, and validating

your solution needs during requirements development. There is tremendous

value in allowing early user interaction and feedback with a new solution. For

software projects, mocked-up screens or report layouts allow users to interact

with and comment on the solution.

Two categories of prototypes are defined in the BABOK

Guide: throw-away

prototypes and evolutionary or functional prototypes. Let’s take a closer look

at each category:

Throw-Away Throw-away prototypes are built to uncover and identify

solution requirements using simple tools. These tools can be paper based or

computer based. A throw-away prototype is intended to be discarded after the

final system is complete. These prototypes don’t have anything much under the

covers that would be of operational use. Throw-away prototypes are used to

gather requirements information.

Evolutionary or Functional Evolutionary prototypes are built to be the basis

for the new fully functioning system. To use them in this way, the prototypes

must be built using a specialized prototyping tool or language. They ultimately

become the working software application that is part of the solution.

260

Evolutionary prototypes are also called functional prototypes.

Exam Spotlight

There are two significant decisions for you to make when using prototyping

as a requirements elicitation vehicle:

Do you use a throw-away prototype (discard after system developed) or

an evolutionary/functional prototype (becomes all or part of the

system)?

Do you use a vertical perspective (narrow detailed area) versus a

horizontal point of view (broad brush of all capabilities at a very high

level)?

To prepare for prototyping, you must clearly identify the functionality that will

be modelled and select your prototyping approach. Then, build the prototype in

an iterative fashion, adding details as appropriate. It is important to make sure

that the elements of the prototype can be traced back to the solution

requirements, such as processes, data rules, and business rules. Prototypes are

intended for end users, so make sure the prototype actually meets their needs

for the new solution.

Throw-Away Does Not Mean Keep

Phil, the business analyst, frequently uses throw-away prototypes for his

user-facing software systems. He believes (and rightfully so) that

prototyping the user interface is a great way to get input before spending

enormous amounts of time and effort in actual system development and

implementation. As Phil is fond of saying to his team, end users sure seem

to know what they don’t like when they see it. By using a throw-away

prototype or storefront, Phil is frequently able to get a handle on the user’s

interaction with the new system and discover their likes and dislikes.

While working on developing a software system for a large

telecommunications firm, Phil determined that prototyping was the best

approach to use for elicitation. The development team built a storefront

prototype of an online store and then scheduled meetings with users of the

eventual system and those who received the outputs from the proposed new

application.

Phil’s experience was interesting to say the least. The users spent hours

making suggestions on layout, color, and error messages. They concentrated

on the human interface pieces of the system. They didn’t say a word to Phil

261

or to the team about the functionality behind the user screens. The higher-

level managers didn’t say too much about the storefront’s functionality

either. They took one look at the screens and beamed, “Nice work, you

finished the application ahead of schedule!”

As Phil and his team learned, it is easy to get burned in your throw-away

prototyping efforts. Remember to make sure that the folks interacting with

the prototype are consistently made aware that this particular prototype is

just a shell, not the actual process or system. That way, they won’t be

surprised to learn that the throw-away prototype will be discarded (hence

the name throw-away), and the system will be designed and developed

using enhanced requirements based on the prototyping efforts. Keep

reminding everyone that throw-away prototypes typically don’t have much

substance hidden under the mocked-up user interface covers.

There are many forms of prototypes in use today. Table 5.6 describes each form

for you.

TABLE 5.6 Forms of prototypes

Form Description

Proof or Principle

or Concept

Validates the design of a system without modelling

appearance, materials, or process flow

Form Study Explores basic size, look, and feel of a product without

creating actual functionality

Usability Addresses how the end user interacts with the system

without including any properties

Visual Shows the visual aspects of the solution without modelling

complete functionality

Functional Tests software functionality, system qualities, and

workflow in a working model

Your goal when building a prototype is developing an end-to-end understanding

with your end users (and for yourself) of how the solution or part of a solution

actually works.

Other Techniques to Consider

The BABOK

Guide lists some additional techniques that may be used when

conducting elicitation. They are summarized for you here:

Benchmarking and Market Analysis Benchmarking studies are a source of

business analysis information, comparing an aspect of the solution with an

external baseline. Market analysis is a mechanism for determining what

external customers want and what your competition provides.

Brainstorming This technique is used during elicitation to generate many

ideas from a stakeholder group in a short period of time. The resulting ideas can

then be organized and prioritized relative to the targeted elicitation activity

262

outcome and what is currently known.

Business Rules Analysis When eliciting business analysis information,

business analysts must discover and factor in how decisions are made in the

organization and the rules governing organization operations.

Collaborative Games Collaborative games, such as product boxes, affinity

maps, and fishbowls, help groups of stakeholders develop a better

understanding of a problem or stimulate creative solutions to a problem.

Concept Modelling Concept models identify key terms and ideas of

importance, and the relationships between the two.

Data Mining Data mining is an analytical way to identify relevant information

and patterns from data. This technique examines and summarizes large

amounts of data from different perspectives.

Data Modelling Data modelling defines entity relationships during elicitation

activities using a diagram and textual descriptions of the pieces and parts.

Document Analysis Document analysis allows the business analyst to review

documented information about existing systems, contracts, policies, procedures,

standards, and regulations.

Interface Analysis This technique focuses on understanding the interaction

between two entities, such as systems, organizations, or individual roles.

Interviews Interviews involve asking questions of stakeholders to uncover

needs, identify problems, or discover opportunities during the requirements

elicitation process.

Mind Mapping Mind mapping is a visual, nonlinear collaborative way of

generating, organizing, and prioritizing many ideas from a group of

stakeholders.

Observation Watching people do their work is an excellent way to gain insight

about how the work is actually done.

Process Analysis Process analysis focuses on understanding the current

processes and identifying opportunities to improve those processes as part of an

elicitation activity.

Process Modelling Process modelling is a way to understand and think about

improving processes with stakeholders during elicitation activities.

Survey or Questionnaire Surveys and questionnaires allow the business

analyst to elicit business analysis information about customers, products, work

practices, and attitudes in a structured way from a group of stakeholders.

Workshops Workshops are a collaborative and facilitated way to elicit

information about customers, products, work practices, and attitudes from a

stakeholder group.

Exam Spotlight

263

A great many questions for the Elicitation knowledge area will focus on the

details of how you apply the elicitation techniques. Make sure you are very

familiar with the details of these techniques.

Think of each recommended elicitation technique as a three-step process:

prepare, conduct, and wrap-up. Figure 5.3 illustrates the sequence of the steps

for you. First, you prepare to use the technique you have chosen for eliciting

requirements. The preparation activities will be driven by the technique you

have selected. Then, you conduct the elicitation activity and use the selected

technique in the appropriate way. After the elicitation activity is done, you then

are responsible for wrapping things up by reviewing, reporting, and, as needed,

further investigating what you have learned.

FIGURE 5.3 Applying the elicitation techniques

Now let’s get back to the task at hand: conducting the elicitation activity. Once

you have conducted that activity, you are ready to produce the elicitation results

that document what your stakeholders have told you. We will discuss that task

output next.

Produce the Elicitation Results

The elicitation results are just what the name says: the informally documented

results of your requirements elicitation efforts. These might be your informal

notes, scribbles, and pictures representing what you have been told. Your

informal elicitation results are then used as input to the confirm elicitation

results task. Table 5.7 summarizes this transaction.

TABLE 5.7 Output: Conduct elicitation activity.

Output Output

Destinations

Destination Knowledge

Area

Elicitation results

(unconfirmed)

Confirm elicitation

results.

Elicitation and

Collaboration

As the project business analyst, you have the primary responsibility for

informally documenting your elicited project requirements information. The

format that you select depends on the information you are documenting. You

may use text, graphical models, or a combination of the two. The technique or

techniques you selected to elicit requirements may also play a role in how the

elicitation results are informally collected. Other business analysis stakeholders

might be involved with providing the business analyst with the requirements

information that they are seeking.

Let’s take a look at the next step in effective requirements elicitation—

confirming your elicitation results.

264

Confirm Elicitation Results

The third task in the Elicitation and Collaboration knowledge area is confirming

the results of your elicitation activities. Elicited business analysis information is

checked for accuracy and consistency. Any identified errors, omissions,

conflicts, or ambiguity are resolved prior to using the elicited information.

Often, we find that additional elicitation and stakeholder collaboration is

required to resolve these discrepancies. This important step ensures that you

clearly understand the stakeholder intentions and any related issues that might

impact your requirements and your project. You must make sure that you

involve all stakeholders who participated in the elicitation event in this

confirmation step.

According to the BABOK

Guide, confirming elicitation results is a less rigorous

and less formal review than what takes place during analysis.

Figure 5.4 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used to confirm the elicitation results.

FIGURE 5.4 Task summary: Confirm elicitation results.

One key input is required to confirm the elicitation results—the elicitation

results themselves. Additional guidelines and tools can also be used. Let’s take a

look at this key input in more detail:

Elicitation Results Elicitation results are the stated and unconfirmed

requirements that represent the business analyst’s documented understanding

of the stakeholder’s intentions. They were obtained using one or more elicitation

techniques. This information has yet to be reviewed with the involved

stakeholders to make sure everything is correct and complete. This information

may also include risks, assumptions, and constraints to be confirmed and

addressed by the business analyst.

Table 5.8 summarizes the inputs, guidelines, and tools used by this task.

TABLE 5.8 Inputs: Confirm elicitation results.

Task Input Input Type Input Source Source

265

Knowledge Area

Elicitation results

(unconfirmed)

Input Conduct

elicitation.

Elicitation and

Collaboration

Elicitation activity plan Guidelines

and tools

Prepare for

elicitation.

Elicitation and

Collaboration

Existing business analysis

information

Guidelines

and tools

Guidelines and tools are additional inputs that can also be used by business

analysis tasks. Let’s take a closer look at the guidelines and tools that can also be

used as inputs when confirming the elicitation results:

Elicitation Activity Plan Elicitation activity plans are created as part of

preparing for elicitation. They provide the business analyst with guidance

regarding techniques to be applied, questions to be asked, and the general scope

of a particular elicitation effort.

Existing Business Analysis Information Existing business analysis

information should not be overlooked during your requirements elicitation

efforts. This information ranges from existing project documentation to

previously elicited information and requirements to requirements development

methods you can use.

When confirming requirements information, the business analyst performs two

elements of this task, which are as follows:

Comparing elicitation results against source information

Comparing elicitation results against other elicitation results

Let’s step through each of these elements now:

Comparing Elicitation Results Against Source Information Elicitation

results can come from a number of sources, including existing documents and

your project stakeholders. Many times, business analysts schedule follow-up

meetings to review elicitation information for correctness and completion

against one or more of these sources. Key stakeholders may also be asked to

review and confirm elicitation results independently.

Comparing Elicitation Results Against Other Elicitation Results

Consistency is an attribute of well-formed and accurate requirements. To

achieve consistent elicitation results that become confirmed requirements,

business analysts often compare the results against the results of other

elicitation activities. Differences are then collaboratively discussed and resolved

with the stakeholders and the team. Comparisons can also be made to historical

data or existing specifications or models.

Techniques to Consider

The BABOK

Guide recommends one or more techniques when confirming

elicitation results with stakeholders. Let’s take a look at them now in greater

detail:

266

Document Analysis Use document analysis to confirm elicitation results

against existing documents, source information, and other elicitation results.

Interviews Interviews are used to confirm business analysis information with

stakeholders at any level of detail. This technique is particularly helpful when

you are combining and integrating what you have learned to build the

confirmed requirements.

Reviews Formal and informal reviews are a way to confirm elicitation results

with stakeholders, either individually or in groups.

Workshops Workshops are another collaborative way to confirm elicited

information. Walking through elicitation results in a more structured fashion

with stakeholders allows for their feedback and correction.

Producing the Confirmed Elicitation Results

Think of the unconfirmed elicitation results as raw stakeholder information;

your stakeholders tell you what they think is needed. Stakeholder concerns are

any stakeholder issues that arise from your elicitation activities. They can be

many things, such as risks, assumptions, and constraints that accompany the

requirements information you are gathering. Once these concerns are captured

and documented, they will need to be addressed by the business analysis team.

Any stakeholder can be involved with confirming elicitation results, as needed.

Domain SMEs often bring their knowledge and experience to the table relative

to specific business analysis information that has been elicited relative to a

specific change.

Table 5.9 summarizes the full set of tasks using the confirmed elicitation results.

TABLE 5.9 Output: Confirm elicitation results.

Output Output

Destinations

Destination Knowledge

Area

Elicitation results

(confirmed)

Analyze current

state.

Strategy Analysis

Assess risks. Strategy Analysis

Now let’s take a look at the next step in effective requirements elicitation—

effectively communicating business analysis information.

Communicate Business Analysis Information

Much of the work that you perform as part of the Elicitation and Collaboration

knowledge area gets your project requirements information elicited, organized,

and structured appropriately. After the business analysis information is in good

shape, don’t forget to share that information with key stakeholders for their

review, understanding, and approval. This task holds you responsible for

effectively communicating requirements to ensure stakeholder understanding.

Communicating business analysis information tends to be bidirectional,

267

iterative, and ongoing in nature. It is usually done in parallel with most of the

other business analysis tasks found in the BABOK

Guide. Communication can

be formal or informal in nature and includes conversations, notes, documents,

presentations, and discussions with your stakeholders.

Figure 5.5 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks for effectively communicating business analysis information on

your projects.

FIGURE 5.5 Task summary: Communicate business analysis information.

Several key inputs are used when communicating business analysis information

during a project. These inputs are usually produced by activities performed by

other business analysis tasks. Let’s take a closer look at these inputs:

Business Analysis Information The business analyst is responsible for

determining which business analysis information needs to be communicated to

and understood by the stakeholders. Information can be packaged and

communicated to stakeholders at any point in the requirements development

process.

Stakeholder Engagement Approach The stakeholder engagement

approach defines how to communicate about business analysis activities,

elicited information, and deliverables with your stakeholders. Your focus is on

the requirements development tasks and the resulting deliverables.

There are additional inputs that may be used by business analysis tasks:

guidelines and tools. Guidelines are descriptions of why and how a business

analyst will undertake a task. Tools are methods for conducting a business

analysis task or shaping a task output. Let’s take a look at the guidelines and

tools that may also be used as inputs when communicating elicitation

information:

Business Analysis Approach The business analysis approach is a “one-stop

shop” for the general strategy used to guide business analysis work on your

project. The approach contains stakeholder information, any business analysis

methodologies to be used, a high-level schedule, and the level of detail you will

be looking for in your resulting requirements and designs.

268

Information Management Approach This approach determines how

business analysis information will be stored, packaged, and communicated to

your stakeholders.

Table 5.10 summarizes the inputs to the business analysis task of

communicating requirements and lists the source of the input (if applicable).

TABLE 5.10 Inputs: Communicate business analysis information.

Task Input Input

Type

Input Source Source Knowledge

Area

Business analysis

information

Input

Stakeholder

engagement

approach

Input Plan stakeholder

engagement.

Business Analysis

Planning and

Monitoring

Business analysis

approach

Guidelines

and tools

Plan business analysis

approach.

Business Analysis

Planning and

Monitoring

Information

management

approach

Guidelines

and tools

Plan business analysis

information

management.

Business Analysis

Planning and

Monitoring

You need to perform two elements that are part of this task in order to

effectively communicate business analysis information to stakeholders and

make sure they understand that information. The two elements are:

Determine the objectives and format of communication.

Communicate the business analysis package.

Let’s step through each of these elements now:

Determine Objectives and Format of Communication Formal

communication of business analysis information is done using business

analysis information packages. These packages are used to communicate

requirements, designs, quality, solution design inputs, and formal reviews and

approvals. Informal communication takes place whenever it is needed.

Business analysts develop packages to effectively share information with

stakeholders about planned changes. It is essential to analyze the audience for

the business analysis information package and make sure they can understand

the information that is being shared. Packages can be stored in online or offline

repositories.

Exam Spotlight

According to the BABOK

Guide, business analysis information packages

are used for many reasons, including the following:

269

Communicating requirements and designs information to stakeholders

Assessing early quality and planning

Evaluating possible alternatives

Reviewing and approving proposed changes

Providing inputs to solution design

Conforming to contractual and regulatory obligations

Maintaining requirements and designs for reuse

Business analysis information packages can be formal documents, informal

documents, or presentations. They should fit both the audience and the

situation. Business analysts are expected to have good presentation skills. These

skills include creating the presentations, as well as delivering them to the

stakeholders.

Formal documents are usually based upon a template used by the organization

and may include text, matrices, or diagrams. Formal documents are saved and

typically become part of the long-term information record for the project.

Informal documents are used during a change but are not part of the formal

organizational process.

Communicate Business Analysis Package Business analysts are expected

to provide stakeholders with details about the change so the stakeholders can

understand the information. Communicating this information allows

stakeholders to review the package, ask questions, and raise any issues

pertaining to what they have read.

Common ways to communicate business analysis information packages include

group collaboration, individual collaboration, and email or other nonverbal

methods. Group collaboration allows for immediate discussion and feedback

from a group of stakeholders regarding the package contents. Individual

collaboration is a one-on-one review of the package between the business

analysts and a single stakeholder. Nonverbal methods such as email are used

when the information is clear and few questions or explanations are expected.

Techniques to Consider

The BABOK

Guide recommends three techniques for communicating

requirements with stakeholders: interviews, reviews, and workshops. Let’s

summarize each of these techniques.

Interviews Interviews are typically used when communicating the contents of

a business analysis information package to a single stakeholder in a one-on-one

setting. This facilitates individual understanding of the information.

Reviews Reviews allow a group of stakeholders to understand the contents of a

business analysis information package and provide feedback on the contents.

Reviews are also used when approvals for a change are being sought.

Workshops Requirements workshops are structured meetings where a group

270

of stakeholders works together to provide feedback and approval of a business

analysis information package. This technique is typically used during group

collaboration.

Once you have applied one or more of the recommended techniques to

communicate your business analysis information, you can say that the business

analysis information has been communicated. Remember that communicating

business analysis information ensures that the stakeholders understand what

they have been told. Let’s review the concept of communicating business

analysis information one more time.

Communicating Business Analysis Information to Your Stakeholders

Once you have decided how to approach formally or informally documenting

business analysis information, you are ready to communicate the information to

your stakeholders. Remember that the communicated business analysis

information is not just transmitted from the business analyst to the

stakeholders. It must be received, understood, and acknowledged by those

stakeholders in order for effective business analysis information communication

to have taken place. There is no standardized output trail.

The business analyst has the primary responsibility for communicating business

analysis information during requirements development activities on a project.

However, all business analysis stakeholders may have a role in this task and

could be involved with business analysis information communication activities

across the project life cycle. Typical stakeholder roles involved with this activity

include end user, customer, domain SME, implementation SME, and tester.

They may be a sender or a receiver of the communicated information.

Now let’s take a look at the next step in effective requirements elicitation and

collaboration—effectively managing stakeholder collaboration.

Manage Stakeholder Collaboration

Confirming the elicitation results is not enough. Effective business analysts

foster a spirit of collaboration and teamwork with their stakeholders across the

project life cycle. Business analysis work does not take place in a vacuum.

Business analysis efforts require significant collaboration as work products are

defined, documented, reviewed, revised, and approved. Business analysts

should strive to minimize risk and maximize positive reactions by keeping the

right people “in the loop” relative to business analysis information and work

activities.

Managing stakeholder collaboration is an ongoing task for the business analyst.

As work moves forward, stakeholders are identified, their roles are confirmed,

and they receive communications at the right time about the correct topics. New

stakeholders can be identified at any point in time and must be incorporated

into the collaborative work environment the business analyst has created.

Stakeholders can also wear many hats on a project, taking on multiple roles as

the project progresses.

271

According to the BABOK

Guide, business analysts should strive

to actively manage relationships with stakeholders who:

Provide services to the business analyst.

Depend on services provided by the business analyst.

Participate in the execution of business analysis tasks.

It is essential to maintain good working relationships with the key stakeholders

on your project. Poor relationships can result in low-quality information from

stakeholders and a general resistance to the changes that are taking place.

Disengaged stakeholders may not support or may actively oppose the business

analysis activities that are taking place.

Figure 5.6 summarizes the inputs, guidelines and tools, outputs, techniques,

and associated tasks used to prepare for this task.

FIGURE 5.6 Task summary: Manage stakeholder collaboration.

Several key inputs are needed to adequately prepare business analysts to

perform this task. Let’s take a look at each of these task inputs in greater detail:

Stakeholder Engagement Approach This approach defines and describes

the types of engagement expected from the stakeholders and suggests ways to

manage and deal with those stakeholders.

Business Analysis Performance Assessment This assessment focuses on

how effectively business analysis tasks are being performed. The tasks being

assessed include those tasks targeting stakeholder engagement.

There are additional inputs that may be used by business analysis tasks:

272

guidelines and tools. Let’s take a closer look at the guidelines and tools that may

also be used as inputs when managing stakeholder collaboration:

Business Analysis Approach The business analysis approach is a “one-stop

shop” for the general strategy used to guide business analysis work on your

project. The approach contains stakeholder information and the level of

involvement and collaboration expected from the stakeholders during business

analysis activities.

Business Objectives Business objectives define the direction to take in order

to achieve the desired future state. These objectives are frequently used to focus

your stakeholders on a common goal for the desired changes and the resulting

solution.

Future State Description The future state description defines where the

initiative is heading and what will result when the changes have been

implemented. This description is also used to focus stakeholders on a common

goal as they work together to achieve that future state.

Recommended Actions Recommended actions suggest what should be done

to improve the value of a solution. They are part of the common goal the

business analyst can use to keep stakeholders working together and heading in

the same direction.

Risk Analysis Results Some risks identified for your project will be

stakeholder-related risks. You will need to address these risks to maintain

communication and collaboration with stakeholders across the project life cycle.

Table 5.11 summarizes the inputs, guidelines, and tools for this task and lists the

source of each input (if applicable).

TABLE 5.11 Inputs: Manage stakeholder collaboration.

Task Input Input

Type

Input Source Source

Knowledge Area

Stakeholder

engagement

approach

Input Plan stakeholder

engagement.

Business Analysis

Planning and

Monitoring

Business analysis

performance

assessment

Input Identify business

analysis performance

improvements.

Business Analysis

Planning and

Monitoring

Business analysis

approach

Guidelines

and tools

Plan business analysis

approach.

Business Analysis

Planning and

Monitoring

Business objectives Guidelines

and tools

Define future state. Strategy Analysis

Future state

description

Guidelines

and tools

Define future state. Strategy Analysis

Recommended

actions

Guidelines

and tools

Recommend actions to

increase solution value.

Solution Evaluation

273

Risk analysis

results

Guidelines

and tools

Assess risks. Strategy Analysis

When managing stakeholder collaboration across the project life cycle, the

business analyst performs several elements, including the following:

Gaining agreement on commitments

Monitoring stakeholder engagement

Collaborating

Let’s step through each of these three elements now:

Gaining Agreement on Commitments Business analysis activities typically

require time and resource commitments from the stakeholders. These

expectations are key parts of completing the business analysis work in a timely

fashion. The terms and conditions of time and resource commitments should be

discussed and negotiated as early as possible to avoid or minimize conflicts.

Remember to use your negotiation, communication, and conflict resolution

skills when managing stakeholder collaboration.

Monitoring Stakeholder Engagement Monitoring participation and

performance of stakeholders doing business analysis work is another important

task for the business analyst. The right stakeholders need to participate on the

right things in order for the work to be done correctly. Keeping stakeholders

engaged and interested in the business analysis work is also essential.

A number or risks come into play when stakeholders are involved in business

analysis work. Stakeholders can be diverted to other work activities that are not

part of your efforts. They can also provide low-quality business analysis

information that impacts your requirements and designs. Confirmation and

approval of elicitation results and other business analysis deliverables must be

completed in a timely fashion.

Collaborating Business analysts should encourage free flow of information,

ideas, and innovations when working with stakeholders. Common sense tells us

that stakeholders who feel that they are part of the team are typically more

engaged with the work that is being done. Collaboration requires regular,

frequent, bidirectional communication between the business analysis team and

the stakeholders. This stakeholder “care and feeding” is an important part of the

business analyst’s job.

There are several techniques that you may choose to apply when managing

stakeholder collab- oration. One technique that we recommend is collaborative

games, an engaging way to get your stakeholders to work as a team. Let’s take a

look at this recommended technique in greater detail.

Recommended Technique: Collaborative Games

Collaborative games stimulate teamwork and collaboration by putting

participants in an environment where they elicit information and build a joint

understanding of a problem or solution. These games are designed to facilitate

collaboration between the participants while focusing them on a specific

274

objective. Participants share their knowledge on a particular topic, identify

assumptions, and explore the knowledge together in creative ways. People with

different points of view learn how to work together and develop a shared model

of what is needed.

A neutral facilitator usually manages the event and enforces the rules of the

game across all participants. Most collaborative games involve a strong visual or

tactile element, such as using sticky notes, whiteboards, or drawing pictures.

Games typically have these three steps:

1. The first step is an opening step to get participants involved and aware of the

rules of the game. They may also start generating ideas during this step.

2. The exploration step is where participants engage and look for connections

between their ideas, test the ideas, and experiment with new ideas.

3. The closing step has everyone assessing the ideas and working out which

ideas are the most useful relative to the objective of the game.

At the end of the game, the facilitator debriefs the activity. Participants then

review the results and decide what needs to happen next as a result of what was

learned in the session.

The BABOK

Guide lists three specific examples of collaborative

games. They include the following:

Product Box Participants construct a box for a product as if it was

being sold in a retail store. This helps everyone identify the actual

features of the product included on the label.

Affinity Map Participants write down features on sticky notes, put

them on the wall, and then group them together as groups of similar

features. This is a good way to identify related or similar features.

Fishbowl Participants divide into two groups. One group speaks about

a topic while the other group listens and documents their observations.

This is a way to identify hidden assumptions or perspectives.

Additional Techniques to Consider

There are many other techniques to choose from when you find yourself

managing and encouraging stakeholder collaboration on your projects. Let’s

step through each of them here:

Lessons Learned Lessons learned provide a great way to understand

stakeholder engagement and satisfaction as part of your project team. They also

offer the opportunity to improve working relationships by making changes in

the way things are done.

Risk Analysis and Management Risk analysis and management is used to

275

identify and manage stakeholder-related risks, such as participation,

involvement, or engagement.

Stakeholder List, Map, or Personas This technique provides the business

analyst with a list of the stakeholders who are available to participate in

business analysis work.

Once you have selected and applied one or more techniques as part of your

efforts, you are ready to get your stakeholders engaged with your project efforts.

We will discuss that next.

Achieving Stakeholder Engagement

The BABOK

Guide defines stakeholder engagement as “willingness from

stakeholders to engage in business analysis activities and interact with the

business analyst when necessary.” All types of stakeholders may be involved

with the business analysis activities on a project at some point in time.

Managing these stakeholder resources effectively and keeping them engaged

with the work falls on the business analyst’s shoulders. This task output is fairly

subjective. You will be tasked with getting the stakeholders to “play pretty” and

be a part of things. All stakeholders on your project may collaborate with the

business analyst, project team members, and one another while dealing with a

proposed change.

Now let’s wrap up our review of the Elicitation and Collaboration knowledge

area.

276

How This Applies to Your Projects

In this chapter, you stepped through tasks guiding you in eliciting information

for your project’s business, stakeholder, solution, and transition requirements.

Remember that requirements elicitation work is iterative and incremental in

nature. One of the biggest challenges that you will encounter in your projects is

making sure that you ask the stakeholders all of the right questions. After all,

the goal is to get the right information so you can develop correct and complete

requirements defining what capabilities the new solution has to offer. Engaging

and collaborating with your stakeholders is another essential component of a

successful project.

Many types of questions are used in gathering business analysis information.

Using all types of questions as part of your elicitation activities allows you to

organize and discover what the stakeholders need and want within the scope of

the proposed solution. Remember, skilled requirements analysts are experts at

asking questions, especially when they don’t know the answers. These are the

types of questions a skilled business analyst should be proficient with:

Research questions

Detailed questions

Directive questions

Meta questions

Open-ended questions

Closed-ended questions

We’ll take a quick look at each of these question types, but first let’s see how one

seasoned business analyst uses them in interviews.

What Is the Real Problem?

Asking different types of elicitation questions with a plan in mind really

helps us find out what the stakeholders need from our project. Design your

elicitation questionnaire like a funnel, with the top of the funnel

representing high-level, scoping questions. As you progress down the funnel

toward the ground, your questions become more and more detailed based

on what you have learned. At the bottom of the funnel, ask very specific and

detailed questions about what your stakeholders do and what they need

from your project.

The shipping team at Palmer Divide Vineyards expressed concern about the

reliability of current inventory data at the winery. Recently, several cases of

277

a particular wine were sold to a distributor when they were not currently in

stock. Taylor, the IT director, sat down with Bob, the shipping team lead, to

figure out what was going on.

Taylor started her information gathering at the top of the funnel with a

research question.

“What is the problem that we need to address?”

Bob responded, “Well, we have a serious issue with inventory.”

Taylor used a meta question to clarify the response.

“What makes you say that there is an inventory issue?” she asked.

Bob replied, “This organization has no idea of how many items we have in

the warehouse at any given time.”

Taylor used a detailed question to ask for more information.

“Is the issue with keeping track of incoming quantities of wine, outgoing

quantities of wine, or both?”

Bob responded, “I think it is both, but I believe that we should focus on

keeping track of incoming quantity and our current stock of each wine first.”

Taylor dug deeper for more details to provide direction for subsequent

elicitation interviews and involvement with this pending effort.

“Who should keep track of incoming quantity? What should they keep track

of? How often should they keep track of it? Where should they do it?”

Bob pointed to Warren, the warehouse manager, as the person having

primary responsibility for the current wine inventory. From a data

perspective, Bob listed the item number, item quantity, and weekly

shipments as the key data values currently being tracked. He explained that

the vineyard has a simple, spreadsheet-driven inventory system that might

require an update or replacement.

Taylor made good use of the funnel approach in her first round of elicitation

questions. She asked a high-level research question about the inventory

problem and then focused the conversation using a meta question to narrow

the discussion. She then asked several detailed questions about the current

situation. Taylor was not in a situation to use directive questions to seek

agreement or consensus during this elicitation interview. Remember, you

can mix your research, meta, detailed, and directive questions with open-

and close-ended questions to collect the right information from your

stakeholders.

Research Questions These are general questions inviting your stakeholders

to provide you with information about their concerns, interests, and needs

relative to the solution scope. Research questions allow a skilled business

analyst to assess the stakeholder needs. People are comfortable answering

research questions when the questions are not limited or specific and the

answers are not controlled in any way. An example of a research question might

278

be “What constitutes success for this project?”

Detailed Questions Detailed questions focus on gathering specific

information within the predefined solution scope. These questions are typically

the step after research questions and help the business analyst focus on more

specific information that is needed. To be thorough, detailed questions should

be framed around the five Ws: who, what, where, when, and why. As your

questions become more specific, it is important to discourage one-word

answers, such as yes and no. This can often be achieved in the phrasing of each

question. An example of a detailed question is, “Who provides you with this

information?”

Directive Questions Directive questions are used primarily by business

analysts in group settings where there are contradictions in what the business

analyst has been told. Directive questions direct the other parties to an area

where agreement needs to be reached and sometimes away from an area that is

contentious. For project requirements information, these questions can be used

to get consensus on specific features and functionality and to encourage

stakeholder decision making. One example of a directive question might be,

“What is the relative priority of this key feature?”

Meta Questions Meta questions are powerful tools. They allow you to clarify

and enhance what has just been said. Basically, meta questions are questions

about questions. This communications strategy allows the business analyst to

promote open communication in a nonthreatening way. Meta questions clarify

and summarize what the business analyst has been told. They are an active

listening technique that proves that the business analyst really listened to what a

particular stakeholder said during requirements elicitation. An example of a

meta question is, “Do you mind if I ask you about . . . ?”

Both research and detailed questions can be open-ended or closed-ended

questions. Be sure you can distinguish between the two types of questions, as

this is a topic that could appear on your certification exam.

Using a good blend of question types at all levels of detail allows you to elicit

more complete and correct requirements information for your projects. Saving

your questions and reusing them is another best practice that you should apply

on all of your projects. Once you have well-written, general questions, it is easy

to use them on another project. Building requirements elicitation

questionnaires or surveys based on your proven questions often raises the

quality and quantity of business analysis information received. It also saves you

from reinventing the wheel.

279

Summary

The five tasks in the Elicitation and Collaboration knowledge area guide a

business analyst in effectively gathering and organizing requirements

information at any level of detail. It is difficult to develop complete and correct

requirements for your project if you do not elicit complete and correct business

analysis information from your stakeholders. Remember, elicitation is not just

asking questions.

Effective communication and collaboration skills are underlying competencies

enabling a business analyst to do this work. Successful projects start with

defining and agreeing to what is needed. Without the ability to elicit high-

quality requirements information, business analysts will find it difficult to

perform their jobs well.

Your elicitation results must be documented, confirmed, and used in

subsequent requirements development activities, such as analysis and

specification. The stated, confirmed requirements and any stakeholder concerns

are the building blocks from which the real requirements for your projects will

be derived.

280

Exam Essentials

Be able to list the tasks found in the Elicitation and Collaboration

knowledge area. You will see questions about the tasks, their associated

techniques, their more detailed elements, and the key outputs that they produce

on your exam. You should memorize the five tasks of this knowledge area and

the key outputs associated with them. The tasks are:

Prepare for elicitation.

Conduct elicitation.

Confirm elicitation results.

Communicate business analysis information.

Manage stakeholder collaboration.

Be able to list, describe, and apply the elicitation techniques.

Understanding and applying the elicitation techniques will be a key focus for

your Elicitation and Collaboration knowledge area exam questions. Be sure that

you can list and describe how to use the elicitation techniques found in the

knowledge area. Here’s the list:

Benchmarking and market analysis

Brainstorming

Business rules analysis

Collaborative games

Concept modelling

Data mining

Data modelling

Document analysis

Estimation

Focus groups

Interface analysis

Interviews

Lessons learned

Mind mapping

Observation

Process analysis

Process modelling

Prototyping

281

Reviews

Risk analysis and management

Stakeholder list, map, or personas

Survey or questionnaire

Workshops

Be able to explain the different types of elicitation prototypes and

when they might be used. Functional scope prototypes are either horizontal

or vertical; horizontal prototypes pre- sent a shallow, wide view of the

functionality, while vertical prototypes highlight a deep, narrow slice of the

functionality. Software Development Life Cycle (SDLC) prototypes can be

throw-away or evolutionary. Throw-away prototypes allow you to quickly

uncover and clarify interface requirements and then discard the prototype when

the system is done. Evolutionary or functional prototypes extend your initial

requirements into the fully functional system.

Be able to distinguish between structured and unstructured

elicitation interviews. Structured interviews are driven by a predefined set of

questions. Unstructured interviews are more of an informal, open-ended

conversation.

Be able to compare passive and active observation. In passive (invisible)

observation, you observe work being performed, but you do not ask questions

during that work. You record what you see, write down any questions that arise,

and stay out of the way. Once the work is finished, you can ask questions about

what you just witnessed. In contrast, active (visible) observation allows you to

observe and to talk with the user at the same time as the work is being

performed. You can ask questions, even if they interrupt what the user is doing.

282

Key Terms

This chapter stepped through the contents of the fourth knowledge area from

the BABOK

Guide: Elicitation and Collaboration. Most of this knowledge area

focuses on gathering the business analysis information you need to define the

solution capabilities being built by your project.

You should understand how to apply the techniques and tasks in this knowledge

area in order to be an effective business analyst. Additionally, you will need to

know the five tasks and their associated elements and techniques from this

knowledge area in order to be successful on the CBAP

or CCBA™ exams. The

tasks include the following:

Prepare for elicitation.

Conduct elicitation.

Confirm elicitation results.

Communicate business analysis information.

Manage stakeholder collaboration.

Chapter 5 introduced a number of new key words related to eliciting business

analysis information on a project. Here is a list of some of the key terms that you

encountered in this chapter:

brainstorming

business analysis information packages

collaboration

elicitation

elicitation results

elicitation worksheet

evolutionary or functional prototypes

focus groups

idea generation

idea reduction

interviews

prototypes

prototyping

requirements analysis

requirements documentation

requirements elicitation

283

reviews

scheduled resources

stakeholder engagement

supporting materials

throw-away prototypes

workshops

284

Review Questions

1. All of the following tasks are performed during elicitation except:

A. Select elicitation techniques.

B. Confirm elicitation results.

C. Prepare for elicitation.

D. Conduct elicitation.

2. You are reviewing documents for the current system in order to confirm the

existing requirements. Document analysis is an effective technique for doing

this work as long as the documents being reviewed are

A. Not current and invalid

B. Not current but valid

C. Current but not valid

D. Both current and valid

3. What is the proper sequence for conducting any type of elicitation

technique?

A. Reduce, reuse, and recycle.

B. Prepare, conduct, and wrap up.

C. Prepare, analyze, and reduce.

D. Generate, reduce, and assess.

4. During an active observation session, the business analyst watches the user

carefully, asks them probing questions, and:

A. Acts as an apprentice

B. Reviews the findings

C. Takes detailed notes

D. Studies the process

5. What prototype allows you to learn about user interface needs and then to

evolve the requirements into a fully functioning system?

A. Throw-away

B. Usability

C. Evolutionary

D. Visual

6. Who may participate in requirements elicitation activities?

A. Any stakeholder

285

B. Stakeholder list

C. Subject matter experts

D. Project team

7. “Does the existing functionality currently meet your needs?” is an example of

what type of structured interview question?

A. Closed-ended

B. Open-ended

C. Research

D. Meta question

8. Stakeholder ____________ is defined as the willingness of stakeholders to

actively work and interact with the business analysis team.

A. Collaboration

B. Engagement

C. Willingness

D. Involvement

9. What elicitation technique might best assist you in understanding the

existing processes that are being used in an online order entry system?

A. Brainstorming

B. Observation

C. Focus group

D. Prototyping

10. When preparing for observation, you plan to ask questions while the work is

being done. You are preparing to do ____________ observation.

A. Active

B. Passive

C. Invisible

D. Proactive

11. The Elicitation and Collaboration knowledge area focuses on eliciting

business, stakeholder, solution, and ____________ requirements.

A. Implementation

B. Functional

C. Transition

D. Nonfunctional

12. You are working with a group trying to build a diverse list of possible

approaches as to how the team might solve a specific business problem.

What technique should the group consider applying?

286

A. Observation

B. JAD session

C. Focus group

D. Brainstorming

13. You have just discovered that the business process expert, who was

responsible for the existing system currently being upgraded, is no longer

employed by the company. Which elicitation technique might you apply in

this situation?

A. Document analysis

B. Reverse engineering

C. Interface analysis

D. Elicitation workshop

14. You are planning a focus group to elicit requirements for a new online order-

entry system, addressing a wide variety of end users interacting with the

system in different ways. What type of users should you include in your focus

group?

A. Miscellaneous

B. Heterogeneous

C. Homogeneous

D. Collaborative

15. What are the three types of interfaces typically looked at during interface

analysis?

A. People, process, and project

B. User, application, and device

C. Input, output, and process

D. User, system, and software

16. The requirements elicitation technique that uncovers and visualizes the

interface requirements before an application is designed or developed is

called:

A. Prototyping

B. Interface analysis

C. Observation

D. Reverse engineering

17. What technique provides an effective method for eliciting requirements

information from many people in a short period of time?

A. Workshop

B. Interview

287

C. Survey

D. Review

18. Eliciting requirements using a brainstorming session enables the

participants to exercise ____________ thinking.

A. Creative

B. Parallel

C. Focused

D. Critical

19. You and the project sponsor are informally discussing what the business

expects from a proposed new system. You came into the discussion with no

prepared questions. What type of elicitation interview are you conducting?

A. Structured

B. Functional

C. Unstructured

D. Discussion

20. All of the following are games that may be used to encourage stakeholders to

develop a joint view of a problem or potential solution except:

A. Affinity map

B. Product box

C. Business rules

D. Fishbowl

288

Chapter 6

Controlled Middle: Requirements Analysis and Design

Definition

CBAP

/CCBA

™

EXAM TOPICS COVERED IN THIS CHAPTER:

Specify and model requirements and designs.

Verify requirements.

Validate requirements.

Define requirements architecture.

Define design options.

Analyze potential value and recommend solution.

Requirements analysis takes elicited information and makes

sense of it. The tasks found in the Requirements Analysis and Design Definition

knowledge area focus on analyzing the business analysis information from your

elicitation efforts and building the real stakeholder or solution requirements for

your project. The real requirements define the derived needs of your

stakeholders after your structured and collaborative requirements analysis and

design efforts are complete.

Deriving and refining requirements for a project is repetitive and systematic in

nature. Experienced business analysts find themselves moving between

requirements elicitation, requirements analysis, and requirements

documentation or specification activities many times throughout their projects.

There can be a significant difference between the business analysis information

elicited from stakeholders and the real requirements that define the resulting

solution.

289

Requirements Analysis and Design Definition

The Requirements Analysis and Design Definition knowledge area focuses on

analyzing what your stakeholders have told you and defining which capabilities

need to be part of the resulting solution. According to the BABOK

Guide, the

Requirements Analysis and Design Definition knowledge area is where you

develop your stakeholder and solution requirements for your project. Business

requirements are developed by tasks in the Strategy Analysis knowledge area,

and transition requirements are built by the Solution Evaluation tasks.

Exam Spotlight

Stakeholder requirements describe the capabilities of the solution that will

meet the stakeholder needs. Solution requirements are more detailed

requirements, describing the behavior of the solution components so that

those components can actually be created later in the project life cycle. Be

sure you know the difference.behavior sometimes and behaviour other

times. "? amznid=12506>

The tasks in this knowledge area take the elicited business analysis information

and make sense of it. The information reflects what the stakeholders have told

you about what they need. The business analysis information becomes analyzed

requirements after it is acted upon by the tasks in this knowledge area.

Analyzed requirements are defined as requirements that have been specified

and modelled.

This requirements development-focused knowledge area generates several key

business analysis deliverables. They include the following:

Specified and modelled stakeholder and solution requirements

Verified stakeholder and solution requirements

Validated stakeholder and solution requirements

Requirements architecture

Design options

Solution recommendation

We will cover each deliverable in more detail later in the chapter.

To focus on what is important to the business analyst across the life cycle of

their business analysis efforts, let’s consider the tasks of this knowledge area

with the framework of the BACCM™. The business analyst needs to keep an eye

on their work relative to the six concepts contained in the framework: change,

need, solution, stakeholder, value, and context. Table 6.1 lists these

responsibilities.

290

TABLE 6.1 The BACCM™: Requirements Analysis and Design Definition

Core

Concept

The Business Analyst’s Responsibilities

Change Transform the elicitation results into requirements and designs

defining the proposed change.

Need Analyze needs and recommend a solution that meets those needs.

Solution Define solution options and recommend the option addressing

the need that has the most value to the business.

Stakeholder Tailor requirements and designs so the stakeholders can both

understand and use them.

Value Analyze the potential value of the solution options in order to

confirm and communicate that value.

Context Model and describe the context for the proposed change in an

understandable and usable format.

Requirements analysis and design work is multifaceted and applies a wide range

of techniques for categorizing project requirements and making good decisions

about their priorities, their structure, and their quality.

Exam Spotlight

The tasks in the Requirements Analysis and Design Definition knowledge

area apply to the stakeholder and solution requirements for your project.

The Requirements Analysis and Design Definition knowledge area also

addresses monitoring and reporting on the performance of the analysis

activities throughout the project. The business analysis team is responsible

for assessing the effectiveness of the techniques being used to analyze and

specify the stakeholder and solution requirements for their project. The

Requirements Analysis and Design Definition knowledge area is addressed

in Chapter 7 of the BABOK

Guide.

The Business Analyst’s Task List

A business analyst has six tasks to perform in the Requirements Analysis and

Design Definition knowledge area. We will look at each one of these tasks in

detail later in this chapter. The task list from the BABOK

Guide includes the

following:

Specifying and modelling requirements

Verifying requirements

Validating requirements

Defining the requirements architecture

291

Defining design options

Analyzing potential value and recommending a solution

These tasks focus on making sure that the stakeholder and solution

requirements for your projects are thoroughly analyzed and documented for

you, your team, and your stakeholders. The goal is to use the capabilities defined

in these requirements as the basis for designing and constructing the solution.

When Does Requirements Analysis and Design Definition Take Place?

What you and I need is the right word—fat or thin, brisk or lazy. The right

word. In the right place. For the right reason.

Willard R. Espy, editor

The tasks in the Requirements Analysis and Design Definition knowledge area

begin by developing the project’s stakeholder requirements and continue until

the more detailed solution requirements are completed. Typically, defining the

stakeholder and solution requirements on your projects takes place in the

controlled middle of the project life cycle as part of the project’s requirements

development or definition phase.

The controlled middle of a project is where the actual work gets done—one stage

or phase at a time. Business analysis tasks typically include those from the

Elicitation and Collaboration, Requirements Analysis and Design Definition,

and Solution Evaluation knowledge areas, with a little Requirements Life Cycle

Management thrown in for good measure.

Exam Spotlight

Approximately 45 of your 150 CBAP® exam questions will focus on the

Requirements Analysis and Design Definition knowledge area. On the

CCBA™ exam, expect to see approximately 48 questions about this

knowledge area. The exam questions target specific and detailed aspects of

the tasks, tools, and techniques that are found there.

Let’s step through the first task in the Requirements Analysis and Design

Definition knowledge area: specifying and modelling your requirements.

Specify and Model Requirements

The first task in the Requirements Analysis and Design Definition knowledge

area is specifying and modelling the stakeholder and solution requirements for

your project. The business analyst analyzes the elicitation results and creates

representations of those results. For most projects, this work is not done all at

once. The higher-level stakeholder requirements are typically defined and

decomposed into the more detailed solution requirements. Your requirements

architecture drives how you accomplish this by defining the combination of text,

292

charts, diagrams, and models that you will use.

Formal textual or graphical models must follow the rules for their model type.

Typically, modelling rules are set either by your organization, by your selected

modelling tool vendor, or by a set of standards and guidelines for the particular

type of modelling technique that you have selected. That means you are

expected to consistently use the correct notation and meaning for every element

in your model. Formal models are powerful tools as long as your stakeholder

audience understands the language they are speaking. Informal models have no

formal definition, connecting elements in ways that have meaning for you and

for your stakeholder audience.

Figure 6.1 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used to specify and model your requirements.

FIGURE 6.1 Task summary: Specify and model the requirements.

One key input is needed to specify and model the stakeholder and solution

requirements for your project: the business analysis information that was

elicited from your stakeholders and the requirements structure defining how the

stakeholder and solution requirements will be organized. Let’s take a look at this

input in greater detail:

Elicitation Results (Any State) Modelling begins when there are elicitation

results available. The elicitation results that are used can be either confirmed or

unconfirmed. Modelling and elicitation can be sequential, iterative, or

293

concurrent activities. Modelling often leads to the need for additional elicitation

results to clarify or expand upon what is known at a particular point in time.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Guidelines are essentially instructions or descriptions on

why and how a business analyst will undertake a task. Tools, on the other hand,

are methods for conducting business analysis task or shaping a task output.

Let’s take a look at the guidelines and tools that can also be used as inputs when

specifying and modelling requirements:

Modelling Notations/Standards Many business analysts use standard

templates and syntax to precisely and consistently specify requirements.

Modelling Tools There are many modelling tools available to draw and store

matrices and diagrams that represent requirements. These tools may or may not

be part of a requirements life cycle management tool.

Requirements Architecture The business analyst uses the requirements and

their interrelationships to make sure the requirements and designs are complete

and consistent.

Requirements Life Cycle Management Tools These software-based

products are frequently used to record, organize, store, and share requirements

and designs.

Solution Scope Solution scope is the set of capabilities a solution must deliver

to meet the business need. The boundaries of the solution scope are also the

boundaries for the resulting requirements and designs that are being specified

and modelled.

Table 6.2 summarizes the inputs, guidelines, and tools to this task and lists the

task and knowledge area sources for each input used to specify requirements.

TABLE 6.2 Inputs, Guidelines, and Tools: Specify and model requirements.

Task Input Input

Type

Input Source Source Knowledge

Area

Elicitation results (any

state)

Input Conduct

elicitation.

Elicitation and

Collaboration

Confirm

elicitation results.

Elicitation and

Collaboration

Modelling notations/

standards

Guidelines

and tools

Modelling tools Guidelines

and tools

Requirements

architecture

Guidelines

and tools

Define

requirements

architecture.

Requirements Analysis

and Design Definition

Requirements life

cycle management

tools

Guidelines

and tools

294

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

You should apply several elements when specifying and modelling the

stakeholder or solution requirements on your projects, such as the following:

Model requirements.

Analyze requirements.

Represent requirements and attributes.

Implement appropriate levels of abstraction.

Let’s look at each of these elements in greater detail. Working with each of these

elements to the appropriate degree is a skill found in experienced business

analysts. You must decide what to model, how to effectively model it, and how

much detail is necessary in your models.

Model requirements Models are a simplified representation or diagram of

something real. They can be textual, graphical, or a combination of both. The

phrase “a picture is worth a thousand words” is certainly true when it comes to

analyzing and documenting your requirements. Many analysts find using

models—formal or informal—to be helpful during their requirements elicitation

efforts, as well as during requirements analysis.

The most common matrix type of model seen in requirements is a two-

dimensional table or spreadsheet. Requirements attributes and data dictionaries

lend themselves to being developed in a table format. A table can be much more

effective than a bunch of sentences when you are trying to show simple

relationships between pieces of your requirements information, such as

requirements priorities or traceability relationships.

According to the BABOK

Guide, there are five categories of models. Table 6.3

summarizes each category of model and suggests techniques that might be used

for each type.

TABLE 6.3 Categories of models

Category Description Techniques

People and

Roles

Represent organizations, people, and their

relationships to the enterprise and the solution

Organizational

modelling

Scope modelling

Roles and

permissions

matrix

Stakeholder list,

map, or

personas

Rationale Represent the rationale or the “why” of a change Decision

modelling

Scope modelling

Business model

295

canvas

Root-cause

analysis

Business rules

analysis

Activity

flow

Represent a sequence of actions, or events as an

activity flow

Process

modelling

Use cases and

scenarios

User stories

Capability Represent capabilities, features, or functions of

the solution

Business

capability

analysis

Functional

decomposition

Prototyping

Data and

information

Represent the exchange of information within a

solution and the characteristics of that

information

Data dictionary

Data flow

diagram

Data modelling

Glossary

State modelling

Interface

analysis

You will also find yourself using textual requirements to describe your solution

capabilities, conditions, and constraints. Good technical writing skills are

essential. Writing text requirements is not an exercise in creative writing. You

want your text requirements to be written in simple sentences that are clear,

concise, and complete.

Analyze requirements. Requirements analysis requires you to decompose

the elicited business analysis information into components. According to the

BABOK

Guide, a component is “a uniquely identifiable element of a larger

whole that fulfills a clear function.” Basically, you will break down what you

know about the solution into organized pieces and parts and to the right level of

detail. Be sure to look for things that are changing to meet the business need as

well as things that need to stay the same. Watch out for missing information and

beware adding in components that are not needed to attain the solution scope.

Represent requirements and attributes. Most business analysts use the

Requirements Classification Schema from the BABOK

Guide to classify their

requirements: business, stakeholder, solution, and transition. Solution

requirements can be either functional or nonfunctional. These categories are

generic enough to fit any business need.

Make sure you capture the requirements attributes associated with each of the

requirements that you specify and model. The attributes that you need to

capture for each type of requirement are defined for you in the requirements

296

management plan that you produced as part of the Business Analysis Planning

and Monitoring knowledge area.

Exam Spotlight

The BABOK

Guide makes an important distinction between requirements

and designs for this task. When the focus of the specifying and modelling

activities is on understanding the business need, the resulting outputs are

referred to as requirements. When the focus of the specifying and modelling

activities is on the solution, the resulting outputs are referred to as designs.

Implement the appropriate levels of abstraction. When the different

types of requirements found in the BABOK

Guide (business, stakeholder,

solution, and transition) are discussed, the names are provided for the different

levels of abstraction or detail found in those requirements. For example,

business requirements are high level and focus on the big picture of what an

organization requires in order to address a business need. Solution

requirements are far more detailed, providing a basis to design and develop the

capabilities needed in a new solution and its components. It is important for you

to understand the levels of abstraction in your project requirements and factor

them into your requirements elicitation and analysis activities across the project

life cycle.

There are several techniques that you may choose to apply when specifying and

modelling stakeholder and solution requirements and designs. Let’s take a look

at a number of these modelling techniques in greater detail.

Recommended Technique: Business Rules Analysis

Business rules analysis allows you to define the business policies and rules that

govern business decisions and operations in your organization. Business policies

are directives that support business goals. Business rules, by contrast, are

actionable and testable directives that support the business policies. Complex

business rules are often represented using a decision tree or table.

Business rules require you to create or to use a defined glossary of terms and an

understanding of the relationships between them. There are two types of

business rules:

Definitional business rules

Behavioral business rules

Behavioral business rules guide the actions of people who work in your

organization and are typically enforced by organizational policies. Definitional

business rules structure and categorize the knowledge and information found in

your organization. When analyzing, stating, and managing business rules, you

should do the following:

297

State the business rules using the appropriate terminology.

Keep the business rules independent of their implementation.

Document business rules separately from how they are enforced.

State business rules at the atomic level using a declarative format.

Separate business rules from the processes that the rules support or

constrain.

Maintain the business rules in a way that allows for changes as business

policies change.

To effectively perform business rules analysis, you need to have a data

dictionary and glossary for your specific project or your organization.

Recommended Technique: Data Flow Diagrams

Data flow diagrams (DFDs) model how information flows within a system.

DFDs portray the transformation of data by looking at the following:

External entities that are sources or destinations for data

Data processes that transform the data in some way

Data stores that collect the data for some period of time

Data flows moving data between external entities, processes, and data stores

DFDs help you understand the range of data found within a solution or solution

component. They are created after a context diagram has been built that shows

you the high-level view of the solution and its associated data flow. However,

DFDs do not show you who performs the work nor do they show you any

alternative paths through the process.

Palmer Divide Vineyards: Selecting a Data Flow Diagram Notation

You are currently modelling the new functionality associated with

requesting and performing research studies at Palmer Divide Vineyards.

You choose to use data flow to model the basic capabilities that will be found

in the solution.

SH1: Users will perform research studies.

S1: The system will calculate elapsed study time.

SH2: Users will customize the contents of their research studies.

S2: The system will allow creation of custom data queries.

S3: The user will analyze the customer query results.

You draw two models using both the Gane-Sarson and Yourdon notations

298

just for comparison’s sake (Figure 6.2). You decide to show the models to

the project team to see whether they have a preference between them.

FIGURE 6.2 Gane-Sarson and Yourdon models for Palmer Divide

Because your project is software-development intensive, you and the team

decide to use the Gane-Sarson notation for the data models. Everyone has

seen models like this before, and they are most comfortable with that

notation. You know that either notation would work to model the data flow

for customizing research studies at Palmer Divide vineyards but think it best

to go with the one that people find easiest to understand.

DFDs can be created using a number of notations, including Yourdon or Gane-

Sarson. Stakeholders and users usually find either notation style easy to

understand and to follow. Table 6.4 compares the features found in these two

common DFD notations based on the descriptions in the BABOK

Guide.

TABLE 6.4 The two common data flow diagram notations

Elements Yourdon Gane-Sarson

External

entities

Labeled rectangle Labeled rectangle

Data

stores

Label for the data store name

between two parallel lines

Labeled rectangle with the right

side open or a labeled rectangle

with a square containing the data

store name

Data

process

Labeled circle with a “verb-

object” structure naming the

process

Labeled rectangle with curved

corners with a “verb-object”

structure naming the process

Data flow Single or forked line with an

arrow along with a noun-

phrase descriptor of the data

being moved

Single or forked line with an arrow

along with a noun-phrase

descriptor of the data being moved

During requirements analysis, you will create additional diagrams, entity-

relationship diagrams (ERDs), to represent the user’s view of the solution and

its capabilities in terms of entities, attributes, and relationships. Often you will

refine these models during the design phase of the project, particularly if you are

defining capabilities of a software application. During design, the ERDs are

299

refined, and the physical data model that becomes the basis for a relational

database is ultimately created.

Recommended Technique: Data Modelling

Data models visually represent the people, places, things, and concepts that are

important to the business. The two most common types of data models are the

ERD and the class diagram. ERDs are often used for projects where a relational

database is part of the solution, while class diagrams are a better fit for object-

oriented software development efforts.

Logical data models look at the concepts, attributes, and relationships for the

information relevant to the organization in detail or at a high level. Physical

data models describe how data is stored and managed by a software application

that is part of the solution scope. Conceptual data models represent how the

business perceives its information—both the words used to describe the

information and the relationships within the information.

In data models, concepts are something significant to the organization about

which the organization needs data. Attributes are used to define specific pieces

of information associated with a concept, such as its name, acceptable values,

and a description. Relationships are significant business associations between

concepts.

Palmer Divide Vineyards: Data Flow Diagrams or Data Models?

You are still in the early stages of modelling the new functionality associated

with requesting and performing research studies at Palmer Divide

Vineyards. You and the project team choose to use data flow diagrams with

Gane-Sarson notation to model the basic capabilities that will be found in

the solution. However, one of the technical team members has proposed an

alternative to this modelling technique. She believes that using data models

would be a better way to describe the people, places, and things involved

with this new functionality.

The two of you sit down and look at the requirements you were using for

selecting a modelling technique.

SH1: Users will perform research studies.

S1: The system will calculate elapsed study time.

SH2: Users will customize the contents of their research studies.

S2: The system will allow creation of custom data queries.

S3: The user will analyze the customer query results.

You consider the advantages and disadvantages of using either entity-

300

relationship diagrams (ERDs) or class diagrams as ways to effectively model

the solution requirements. The two of you create two simple models using

both approaches to help you evaluate the models and see if they fit your

project, as shown in Figure 6.3.

FIGURE 6.3 ERDs and class diagrams for Palmer Divide

Because your project is a traditional software development effort—

workflow-intensive, as opposed to information-intensive—you both agree

that neither one of these techniques fits your project as well as the simpler

data models. Although the models created using ERDs could become the

basis of a relational database for the vineyard’s technical data, you decide to

pass on these models during requirements analysis. You both agree, though,

that ERDs might be useful to the technical team once the project enters its

design phase.

In addition to defining the information and its relationships, data models also

describe the context, use, and validity of their business information using

metadata, or data about data. Metadata tells a business analyst when and why

information in a system is being changed in some way. Table 6.5 summarizes

and distinguishes (as defined by the BABOK

Guide) between the two types of

data models commonly used by business analysts.

TABLE 6.5 Two types of data model

Elements Entity-Relationship

Diagram

Class Diagrams

Concept Uniquely identified entity in a

rectangle with the unique

identifier shown under the

entity name

Uniquely identified class in a

rectangle or square with an

optional stereotype above it in

brackets defining additional

properties

Attributes Listed below the unique Listed in a box below the name

301

identifier for the entity in the

rectangle

with operations listed below

the attributes

Relationships Indicated by a line which is

annotated to show cardinality,

such as any number from zero

to many, zero to one, only one,

or any number from one to

many

Indicated by a line which is

annotated to show

multiplicity, such as zero to

many, exactly any number

from x to y, or any number

from one to many

Data models are strong vehicles for transitioning through the planning, analysis,

design, and implementation of projects. They are subject to rigorous rules for

correctness and completeness that typically result in more accurate final

products. In some cases, your stakeholders can find detailed data models

difficult to understand, so you must be prepared to build them to the

appropriate level of detail and be able to explain them thoroughly to your

audience when required. According to the BABOK

Guide, performing data

modelling is one of the required techniques in the fundamental knowledge base

of an effective business analyst.

Recommended Technique: Nonfunctional Requirements Analysis

Nonfunctional requirements define the overall qualities or attributes of the

resulting solution or solution components. Basically, they constrain how the

solution requirements are to be met by the solution itself. Nonfunctional

requirements state the qualities of behavior or quality attributes that your

stakeholders want. Nonfunctional requirements augment the description of

solution functionality by stating the solution’s characteristics in various

dimensions that are important to the users or the developers.

You should consider using a checklist for eliciting and developing your

nonfunctional requirements. It is easiest to capture the functional and

nonfunctional requirements at the same time. Checklists can help you organize

your nonfunctional requirements by category and make sure you are not

missing anything. The BABOK

Guide recommends using a set of 15 categories

as buckets for your nonfunctional requirements. Table 6.6 summarizes each

category for you.

TABLE 6.6 Categories of nonfunctional requirements

Category Description

Availability Evaluates solution operability and accessibility when it is

required for use

Certification Defines constraints on the solution that are needed to meet

standards or industry conventions

Compatibility Most solutions today need to operate effectively and either

coexist or interact with other solutions in the same

environment.

Compliance Regulatory, financial, or legal constraints on the solution

302

Extensibility Evaluates the ability of a solution to incorporate new

functionality

Functionality Measures the extent to which your stakeholders can recognize

whether or not a solution meets their needs

Localization Defines requirements for local laws, languages, currencies,

cultures, and spelling

Maintainability Focuses on how easy it will be to change one solution

component without affecting other components. You also need

to consider component reuse, ease of diagnosing problems,

and the ability to implement changes without causing

unexpected failures.

Performance

efficiency

Looks at the time it takes to perform activities and the

resource utilization levels for the solution

Portability You need to determine whether your solution can be migrated

to, installed in, and uninstalled from different environments

when needed.

Reliability Focuses on the solution’s availability when the stakeholders

need it. You should also look at the solution’s ability to recover

from errors or failures.

Scalability Looks at the degree with which a solution can grow or evolve

to handle more work

Security Looks at the solution’s ability to store information and protect

it from unauthorized use. Authentication of solution users and

audit reporting is also considered.

Service level

agreements

Formal agreements for solution performance between the user

organization and the provider of the solution

Usability Evaluates the ease of learning to use the new solution, its

capabilities, and how usable the solution actually is

Once you have captured your nonfunctional requirements, you will need to

document them. Nonfunctional requirements are typically documented

alongside the functional solution requirements that they constrain. That makes

sense because the functional and nonfunctional requirements are both subsets

of your solution requirements. It’s a good idea to document the nonfunctional

requirements that define your global constraints in their own section of your

requirements document because they impact all of your solution requirements

in some way.

Recommended Technique: Process Modelling

Process models organize your requirements using a hierarchy of processes and

subprocesses, and they address those processes from start to finish. Use them to

document the steps your stakeholders take to get their work done. Process

models are easy to understand and to work with. Think of graphically depicting

a series of steps to place an online order on a whiteboard with arrows between

303

them to show the sequence of events. That flowchart is a simple process map.

According to the BABOK

Guide, process models are visual representations of

the sequential flow and control logic of a set of related activities. Process models

may consist of manual steps performed by the stakeholders, automated steps

taken by a software system, or some combination of the two. Process models

may be developed at a high level to get a general understanding of what is going

on, or they may be very detailed steps that your stakeholders take to perform

their work.

Palmer Divide Vineyards: Are Process Models Even Better?

Your users were not pleased with the Gane-Sarson data model you

presented to show the information flow associated with the research study

project at the vineyard. They have asked you to model something more from

the user’s point of view. Several end users chimed in that they would like

models that show who needs to do what and in what order it needs to be

done. You agree to look at some other modelling techniques that may be

more workflow focused.

Once again, you review the requirements you were using for selecting a

modelling technique.

SH1: Users will perform research studies.

S1: The system will calculate elapsed study time.

SH2: Users will customize the contents of their research studies.

S2: The system will allow creation of custom data queries.

S3: The user will analyze the customer query results.

You think to yourself that perhaps a simple flow chart noting the user at

each step might just do the trick. You create one for this small set of

requirements (Figure 6.4) and ask the users what they think of this

approach. The response is an overwhelming yes, and the final decision is

that simple workflow models are the way to go on this project.

304

FIGURE 6.4 Workflow mode for Palmer Divide

Numerous notations can be used in your process models. The two most

common notations are flowcharts and activity diagrams. Table 6.7 summarizes

the key elements found in your process models.

TABLE 6.7 Process model notation elements

Element Description

Activity Individual steps or pieces of work being performed to execute a

business process

Decision

point

Forks where workflow takes different directions or merges back

together based on a decision being made

Directional

flow

Indicates direction of the sequence of activities, typically drawn as

top to bottom or left to right

Events External factors such as actions taken or messages received that

create, interrupt, or terminate a process

Link A connection to other process maps

Role Represents a type of person or a group found in the organization

Recommended Technique: Sequence Diagrams

Sequence diagrams can be thought of as if they were tracking the information

flow between two people having a conversation. They show how the information

gets passed back and forth between the two people. Sequence diagrams are

commonly used during object-oriented analysis to show how classes and objects

interact during a scenario. You can also use them to show how the user interface

components or software components interact in your solution.

In a nutshell, sequence diagrams shows stimuli flowing between objects. The

stimulus is a message, and the arrival of the stimulus at the object is called an

event. Each object name is in a rectangle with a single vertical line drawn

beneath it called a lifeline. Messages are depicted starting at the top of the

lifeline and moving down that lifeline over time.

There are two ways to send messages between objects: asynchronous and

305

synchronous. Synchronous flow transfers a message to the receiving object and

waits for a response or return message before it can do anything else.

Asynchronous flow allows the sender to continue with its own processing after

sending the message to the receiver.

Recommended Technique: Use Cases and Scenarios

Scenarios and use cases offer you a way to model how your stakeholders interact

with the solution capabilities in order to get their jobs done. The stakeholder

roles are called actors. Scenarios and use cases show how actors interact with

the solution to accomplish one or more of their goals or in response to a

particular event. They are excellent ways to model the solution scope and the

behavior and goals of the actors interacting with that solution.

Palmer Divide Vineyards: Addressing Our Visual Learners

William, one of the vineyard’s co-owners, prefers to review and approve

high-level requirements by walking through graphical models containing as

little text as possible. Because William is responsible for providing funding

for the research study project, it is important that you meet his needs in

your upcoming review meetings with senior management.

On past projects, you have successfully used high-level use-case diagrams to

facilitate discussion of functionality and which stakeholders interact with

that functionality. Even though many IT project teams only build use case

diagrams when they are developing an object-oriented system, you know

that a use case diagram can be employed effectively in your more traditional

development project. The summary diagram will help you explain the high-

level use cases or processes, the key stakeholder roles (actors), and the

interactions between them (associations). If you discover an actor with no

association to any of the use cases in your model, it might be that they are

not a direct user of your system. If you have a use case with no actors

associated with it, you will question the inclusion of those capabilities in

your new system or discover who should interact with that particular

capability.

For what you hope is the last time, you take a look at the requirements you

were using for selecting a modelling technique.

SH1: Users will perform research studies.

S1: The system will calculate elapsed study time.

SH2: Users will customize the contents of their research studies.

S2: The system will allow creation of custom data queries.

S3: The user will analyze the customer query results.

306

You build a summary-level use-case diagram as part of your modelling

efforts to prepare for the upcoming meeting. The diagram models the new

functionality associated with requesting and performing research studies at

Palmer Divide Vineyards, as shown in Figure 6.5.

FIGURE 6.5 Summary-level use-case diagram for Palmer Divide

Scenarios and use cases are very much related. Scenarios are a series of steps

performed by a stakeholder in order to document one way in which that person

could use a solution capability to achieve a goal. Use cases consist of a set of

scenarios describing all ways that stakeholder might achieve (or fail to achieve)

a particular goal. Table 6.8 summarizes the key elements found in scenarios and

use cases.

TABLE 6.8 Use case and scenario elements

Element Description

Name Unique name for each scenario or use case within the project,

usually a “verb-noun” phrase such as Process Order

Goal Brief description of a successful outcome of the use case from

the perspective of the primary actor

Actor(s) Unique name representing the role of each external person,

system, or event that interacts with the solution through a use

case

Preconditions Any fact that the solution can assume to be true when the use

case begins

Trigger An event that initiates the flow of events for a use case

Flow of

events

Description of what the actor and the solution do during the

execution of the scenario, usually consisting of a primary flow

and alternate flows

Post-

conditions or

guarantees

Any fact that must be true when the use case is complete

307

Recommended Technique: State Modelling

State modelling shows a sequence of states that an object, entity, or concept

goes through during its lifetime. These models also define the events that cause

a transition between these states. The functionality and behavior of a particular

object will be different based on its current state. For example, a mainframe

computer system in batch-processing mode may be unable to process real-time

queries from a user during the time it is in that state.

State models are also called state machine diagrams. A state represents a

unique condition that an object can be in or a status that the object may have.

All states for an object are mutually exclusive, which means that an object can

be in only one state at a time. All state machines have an initial state and any

number of intermediate or end states. Transitions define the behaviors that

move an object from one state to another state. They are often triggered by

completed activities or events.

Here is a simple state machine for requirements development activities using

the BABOK

Guide. The transitions for the requirements that are under

development are the knowledge area tasks that change the state of those

requirements as you work on them. For example during requirements analysis,

the analyzed solution requirements (those that have been specified and

modelled) go through a quality check using the verify requirements task. When

the requirements emerge from this task, they have changed to a new state and

become the verified solution requirements; are omitted or deferred to a later

release; were determined to be out of scope, unnecessary, or unworkable; or

marked as failed as a solution requirement for some other reason.

Recommended Technique: User Stories

User stories are commonly used for change-driven requirements development.

They briefly describe the functionality your solution provides to its users. You

should define acceptance and evaluation criteria for each user story so you can

prove that its functionality has been met by the solution. Business analysts write

user stories from the user’s point of view. User stories contain the following:

The actor or stakeholder benefiting from the user story

A high-level description of the functionality in the story

The business benefits that the story delivers

User stories create customer ownership of requirements by having actual users

write stories about what the solution needs to accomplish for them. You can use

these stories to support your iterative, incremental development environments.

They allow you to define key features of the solution that can be implemented by

the project team in one to three weeks. (Remember, user stories for Agile

projects are for small bites of projects, typically time bound, and short in

duration.)

Additional Techniques to Consider

308

The BABOK

Guide recommends using one or more of the following additional

techniques when you are specifying and modelling the requirements for your

project. They are summarized for you here:

Acceptance and Evaluation Criteria Acceptance criteria define the

requirements that must be met for a solution to be acceptable to stakeholders.

Evaluation criteria are the measures used to assess those requirements.

Business Capability Analysis This technique is used to describe what an

enterprise or part of an enterprise is able to do. These business capabilities

represent features or functions of the enterprise.

Business Model Canvas This diagnostic planning tool can be used to

describe the rationale for requirements relative to the current state of the

business.

Concept Modelling Concept models are used to define terms and

relationships that are relevant to proposed change and the enterprise where the

change is taking place.

Data Dictionary Data dictionaries are technical in nature and are used to

define data elements, their meanings, and their allowable values. Building a

data dictionary for your project might be a necessary step in your requirements

specification and modelling activities.

Decision Modelling Decision models represent decisions and the elements of

decision making that are required in a particular model.

Functional Decomposition Functional decomposition allows you to

systematically break down the solution scope components into smaller pieces

and more detailed requirements based on similar or related functionalities or

features.

Glossary Glossaries allow you to document key business terms along with their

definitions. Much of the information that goes into the glossary will be a result

of your business, stakeholder, solution, and transition requirements

development efforts.

Interface Analysis Interface analysis establishes a basis for interoperability

by recognizing inputs, outputs, and key data elements that enable your solution

and its components to interact with everything else that is already out there.

Organizational Modelling Most of us have seen an organization chart

showing the hierarchy. This is an example of an organizational model. The

model defines the purpose and structure of an organization or an organizational

unit.

Prototyping Prototyping is a great way to add additional details to your

solution interface requirements and integrate those requirements with the other

requirements defining the new solution. Essentially a prototype is an initial or

preliminary version of a solution or system.

Roles and Permissions Matrix This matrix separates and models the user

duties and external interfaces associated with a specific solution.

Root Cause Analysis This technique is used to model the root causes of a

309

problem or need as part of the rationale for a change or a new solution.

Scope Modelling Scope models visually show stakeholders the boundary of

the solution scope. During requirements analysis, the business analyst can place

capabilities either inside or outside of this scope.

Stakeholder List, Map, or Personas Identifying stakeholders and their

roles is a key part of analyzing and specifying requirements. Use the stakeholder

list, map, or personas technique to help you do a thorough job with identifying

your stakeholders and their characteristics.

Once you have selected and applied one or more techniques as part of your

requirements specification and modelling efforts, you are ready to continue with

other requirements analysis tasks. We will discuss those tasks right after we

review the output of our current task, the specified and modelled requirements

for the project.

Create the Specified and Modelled Requirements

Specified and modelled requirements are used as an input to several solution-

related tasks. Remember the definition for analyzed requirements: the modelled

and specified stakeholder and solution requirements for your project. Table 6.9

summarizes the destination tasks utilizing your analyzed requirements.

TABLE 6.9 Output: Specify and model requirements.

Output Output

Destinations

Destination Knowledge

Area

Requirements (specified

and modelled)

Verify

requirements.

Requirements Analysis and

Design Definition

Validate

requirements.

Requirements Analysis and

Design Definition

Exam Spotlight

Remember, the business requirements are analyzed and created by tasks in

the Strategy Analysis knowledge area, and the transition requirements are

analyzed and created by tasks in the Solution Evaluation knowledge area.

Your stakeholder and solution requirements are created by specifying and

modelling requirements in the Requirements Analysis and Design

Definition knowledge area.

You are responsible for specifying and modelling the stakeholder and solution

requirements on your project. You will have to decide whether this work is to be

done alone or as a team effort. If you perform this task alone, you will specify

and model the requirements, create the requirements package, and then

communicate those requirements with the stakeholders for their review and/or

310

approval. You can also choose to involve the stakeholders in this task so that the

requirements package contents and the requirements themselves are not a

surprise to anyone.

Now let’s take a look at the next task in the Requirements Analysis and Design

Definition knowledge area—verifying requirements.

Verify Requirements

Requirements verification is a quality check of the analyzed requirements. This

task involves making sure your requirements are correct and complete and that

they meet the quality standards defined for them. Requirements verification can

be thought of as an internal check by the business analysis team and the

involved stakeholders to make sure the requirements are ready to be seen out in

public. Out-in-public requirements are ready for formal review and approval so

they can be used as the basis for subsequent project work, such as design and

implementation.

Figure 6.6 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used to verify requirements.

FIGURE 6.6 Task summary: Verify the requirements.

To verify the requirements, you need to have those requirements in hand. These

requirements can be of many types and in many states, as long as they are not

the stated requirements you elicited from your stakeholders.

The single, key input needed to verify the requirements for your project is the

specified and modelled requirements. Let’s take a look at this input in greater

detail:

Specified and Modelled Requirements Specified and modelled

requirements and/or designs are produced in the form of text, matrices, and/or

diagrams. They take the business analysis information from the stakeholders

and make sense of what was said.

311

There are additional inputs that may be used by business analysis tasks:

guidelines and tools. Let’s take a look at the tool that may also be used as an

input when specifying and modelling requirements:

Requirements Life Cycle Management Tools These software-based

products are frequently used to record, organize, store, and share requirements

and designs.

Table 6.10 summarizes the inputs, guidelines, and tools for this task and lists

the task and knowledge area sources for each input used to verify requirements.

TABLE 6.10 Inputs, Guidelines, and Tools: Verify requirements.

Task Input Input

Type

Input Source Source Knowledge

Area

Requirements

(specified and

modelled)

Input Specify and

model

requirements.

Requirements Analysis

and Design Definition

Requirements life

cycle management

tools

Guidelines

and tools

Any type of requirement can be verified, including business, stakeholder,

solution, or transition requirements. Because verification is a quality check of

the analyzed requirements, the requirements cannot be the stated requirements

or the business analysis information resulting from your elicitation efforts. They

must have been analyzed, specified, and modelled.

Well-written requirements aren’t a random event—they are planned and

thoroughly reviewed and revised to meet most, if not all, of the characteristics

listed in the BABOK

Guide. The elements you focus on during requirements

verification include a set of characteristics for well-written requirements and the

work activities to make sure these characteristics are properly applied. There are

three elements that are part of this task. They include the following:

Characteristics of requirements and designs quality

Verification activities

Checklists

Let’s review these three elements used to verify requirements in more detail:

Characteristics of Requirements and Designs Quality The BABOK®

Guide provides you with the nine characteristics of well-written, high-quality

requirements. Think of this as your well-written requirements quality checklist

and make frequent use of it during your requirements development efforts.

Atomic Atomic requirements are a set of requirements organized as cohesive

sets of information rather than random chunks of information. They are self-

contained and can be understood independently of other requirements or

designs.

Complete Your goal is to produce a complete set of requirements defining what

312

is needed for a solution or a solution component. Your requirements should

specify everything that is needed at the appropriate level of detail. While

building your requirements document, ask yourself if you have missed anything.

If you see unresolved issues or incomplete documentation, then fix it.

Concise Concise requirements do not contain any extra information or content.

There is no “gold plating,” which is extra functionality that is not required to

achieve the solution scope or meet the business need.

Consistent Consistent requirements do not contradict or conflict with one

another. If they do, they should be revised or removed. Consistency should also

be applied to the level of detail in your requirements document structure. All

requirements at a specific numbering level in your document should be written

at the same level of detail. Checking for consistency often requires a manual

review and analysis of the complete set of requirements.

Feasible Feasibility of requirements relates to implementation. The existing

infrastructure, budget, timeline, and resources of the organization should be

adequate to implement your requirements as defined. If not, your requirements

will need to be revised to include any additional capabilities that are needed to

implement them.

Prioritized Verified requirements should be ranked, grouped, or negotiated

relative to their importance and value versus all other requirements.

Requirements prioritization involves the stakeholder as well as the business

analysis team.

Testable Can you ensure that a requirement is met by your resulting solution?

If not, that requirement should be removed or revised because all requirements

must be measurable and provable in some way. Testing proves that what is

needed is indeed present in the solution. That means that each requirement in

your document must be provable as a single, standalone statement or within a

specific functional scenario. Numerous techniques exist for ensuring that

requirements are met (Table 6.11).

TABLE 6.11 Techniques for ensuring requirements are met

Technique Description

Analysis Performs analysis of the system characteristics to prove it

works

Demonstration Involves running the full system in the normal mode of

operation

Execution Uses another system or testing equipment to simulate your

data

Inspection Looks at (inspects) characteristics of the system or its output

Prior

qualification

Recognizes that a component has already been tested and is

being used unmodified

Unambiguous Can your requirements be interpreted in more than one way? If

so, they are ambiguous. Well-written requirements have only one meaning.

313

People should not be able to read your requirements and come up with multiple

meanings. When terms have multiple meanings, consider defining those terms

in your glossary.

Choose the Right Word

Here is an example of why choosing the right word is not always as easy as

you might think. Let’s take a simple word: bug. Susan’s mother says that a

bug is an insect of some sort. Terri’s nephew says that a bug is something he

needs to fix in his software code. A military customer says a bug is a secret

listening device that shouldn’t be there. Funny thing is that they are all

correct.

Here’s why. In the dictionary, a bug is commonly defined in one of two

ways: any small insect or a concealed microphone. However, in the software

world, a bug is the name given to an error in software application code.

Synonyms for the word bug include germ, virus, and wiretap.

Watch your word choices. Words can mean many different things when they

are used in your requirements document. If you need to, document the word

and your selected meaning in your glossary to make sure everyone uses that

word the way you intended.

Understandable Requirements need to be understood by the key stakeholders

as well as by the members of the project team. Requirements should be written

using common terms that are understood by everyone.

Verification Activities You will find yourself verifying requirements many

times during the project life cycle. When you are doing this task, remember to

look at all of the specified requirements and designs, including text, tables, and

graphical models. Verification activities include checking for the following:

Compliance with organizational standards

Correct use of modelling notations

Completeness within each model

Inconsistencies between models

Understandable terminology and correct use of terms

Checklists Checklists are an excellent quality control technique to apply to

your requirements documentation. Checklists ensure that important items are

included in the final requirements deliverables for your project, such as the nine

characteristics of well-written requirements previously discussed. Checklists

may also contain process steps to guide you through the requirements

verification activities that should be done on your project.

314

There are several techniques that you can choose to apply when verifying your

requirements. Let’s take a closer look at these techniques.

Techniques to Consider

The BABOK

Guide recommends using one or more of the following techniques

when you are verifying project requirements:

Acceptance and Evaluation Criteria As part of requirements verification,

you must determine the quality criteria against which you will evaluate your

requirements. This gives the folks verifying your requirements the metrics to

use in their evaluation of them.

Item Tracking Item tracking is one component of issue management. This

technique allows a business analyst to maintain focus on business-analysis-

related problems and issues across the project life cycle. Any problems

identified during requirements verification may be tracked using this technique.

Metrics and Key Performance Indicators (KPIs) Metrics are quantifiable

indicators used to measure progress. KPIs are specific numerical measurements

that represent the degree of progress toward something. Both are used to

identify and evaluate the quality of requirements and/or designs.

Reviews Reviews are frequently used to inspect requirements documentation

and identify requirements that are not of acceptable quality. A review is a

meeting with a tour guide. Your destination is the verified requirements, and

your meeting agenda will walk you through the possibilities in order for the

group to evaluate and revise the requirements.

Once you have selected and applied one or more techniques as part of your

verification efforts, you are ready to continue with the other requirements

analysis tasks in this knowledge area. We will discuss those tasks later in the

chapter. First, let’s take a look at the verified requirements produced by this

task.

Produce the Verified Requirements

Verified requirements are well-written requirements that can be used in other

project work, such as technical design. Verified requirements must be of

reasonable quality so that the team can use them and not worry about having to

redo things later. Verified requirements are used as input to several business

analysis tasks, including validating requirements and communicating verified

requirements with your stakeholders for their review or approval. Table 6.12

summarizes these destination tasks and their knowledge areas.

TABLE 6.12 Output: Verify requirements.

Output Output

Destinations

Destination Knowledge Area

Requirements

(verified)

Approve

requirements.

Requirements Life Cycle

Management

315

You are responsible for making sure that the quality criteria for your

requirements have been met. Any business analysis stakeholder may assist you

with this task, including your domain and technical experts.

Now, let’s look at the next task found in the Requirements Analysis and Design

Definition knowledge area—validating the requirements.

Validate Requirements

Validating requirements ensures that your requirements align to the business

requirements and the business objectives for your project. By definition, valid

requirements contribute directly or indirectly to the project’s business case.

Requirements validation is ongoing across the project life cycle; it ensures that

each level of detail you add to your requirements aligns with the big picture.

Figure 6.7 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used to validate requirements.

FIGURE 6.7 Task summary: Validate the requirements.

The inputs to validating requirements include the specified and modelled

requirements that you are validating. Let’s look at this task input in greater

detail:

Requirements (Specified and Modelled) Specified and modelled

requirements and/or designs are produced in the form of text, matrices, and/or

diagrams. They take the business analysis information from the stakeholders

and make sense of what was said. Validation activities may be done on any type

of requirements or designs. Sometimes, validation activities begin before

verification activities are complete.

316

There are additional inputs that may be used by business analysis tasks:

guidelines and tools. Let’s take a look at the guidelines and tools that may also

be used as inputs when validating requirements:

Business Objectives Business analysts use the defined business objectives to

make sure that the requirements are validated and actually will deliver the

business benefits.

Future State Description Validation is incomplete unless the business

analyst can prove that the requirements will achieve the desired future state as

part of the defined solution scope.

Potential Value The potential value is used as a benchmark for assessing the

value that will be delivered to the business by the requirements after they are

implemented.

Solution Scope Experienced business analysts make certain that the

requirements providing benefits to the business are within the boundaries of the

solution scope.

Refresher: Defining Business Requirements, Needs, Goals, and

Objectives

Business Requirements The defined problem, opportunity, or need

based upon the current state of the business

Business Need A problem or opportunity that an organization is facing

within the framework of the organization’s business goals and objectives

Business Goal A future state that an organization is seeking to establish

and maintain

Business Objective An objective and measurable result that indicates a

business goal has been achieved

Table 6.13 summarizes the inputs, guidelines, and tools for this task; it also lists

the task and knowledge area sources for each input used to validate

requirements.

TABLE 6.13 Inputs, guidelines, and tools: Validate requirements.

Task Input Input

Type

Input Source Source Knowledge

Area

Requirements

(specified and

modelled)

Input Specify and

model

requirements.

Requirements Analysis

and Design Definition

Business objectives Guidelines

and tools

Define future

state.

Strategy Analysis

Future state Guidelines Define future Strategy Analysis

317

description and tools state.

Potential value Guidelines

and tools

Define future

state.

Strategy Analysis

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

You need to keep a number of elements in your line of sight as you validate your

requirements. They include the following:

Identifying any assumptions

Defining measurable evaluation criteria

Evaluating your alignment with the solution scope

Let’s review each of these elements in more detail. Each of these elements deals

with a detailed area of the project’s desired future state, focusing on making

sure that the defined business benefits of the project are achievable, and

showing proof that those business benefits have been achieved.

Identify Assumptions Within a project’s business case, you might have

documented assumptions about realizing the business benefits. Any

assumptions about a specific business benefit should be documented and linked

to the requirements that deliver those benefits. This might introduce additional

risk into the premises contained in the business case, since it is possible that the

assumptions might not be true in the end.

Define Measurable Evaluation Criteria One item of interest found in your

business case is the business benefit that the project will provide to the

organization once the project is complete and the solution is up-and-running.

Business benefits can be measured only if you define the measurement criteria

and how you will evaluate whether you have achieved them. If you are lucky,

they were defined in the business case. If not, you will need to define them now

during requirements validation.

Evaluate Business Case Alignment Beware of requirements that are

beloved by your stakeholders yet add little or no business value to the

organization. The best rule to follow is that requirements that do not align with

the solution scope result in either a revised business case or their removal from

the solution scope. Watch out for the opportunity cost of implementing such

requirements. Sometimes it is best to remove requirements that don’t align with

the solution scope versus investing the time and money to make them work.

Your time and money might be better spent elsewhere. Every opportunity (or

requirement) has an associated cost.

There are several techniques that you can choose to apply when validating your

project requirements. Let’s take a look at those techniques right now.

Techniques to Consider

The BABOK

Guide recommends using one or more of the following techniques

when you are validating your project’s stakeholder, solution, or transition

318

requirements relative to the project’s business requirements and solution scope.

Acceptance and Evaluation Criteria Acceptance criteria are the quality

metrics that must be met by a requirement, a solution component, or the

solution itself in order to be accepted by the project stakeholders. Evaluation

criteria are used to measure how successful a deployed or operational solution is

in providing business benefits.

Document Analysis Document analysis is used during requirements

validation activities to identify previously documented business needs.

Financial Analysis This technique allows the business analyst to define and

confirm the expected financial benefits associated with the validated

requirements.

Item Tracking Item tracking makes sure that any problems or issues related

to validation are managed and resolved as part of the issue management

process.

Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are

used to select and define performance measures for your requirements, solution

components, or solutions.

Reviews This technique is used frequently by business analysts seeking

agreement from their stakeholders that the requirements meet their needs and

can be considered validated.

Risk Analysis and Management Risks are generated when you make

assumptions about your requirements, such as achieving the potential business

benefits or building a solution that adds value to the organization. Risk analysis

might result from the need to evaluate those assumptions and the associated

potential risks.

Let’s move on and take a look at the validated stakeholder, solution, or

transition requirements that are produced by this task.

Produce the Validated Requirements

Validated requirements are stakeholder, solution, or transition requirements

that are aligned with the business goals and objectives found in your project’s

business requirements or business case. These requirements benefit the

organization and will provide value when they are implemented by the resulting

solution. Remember that validated requirements fall within the framework of

your defined solution scope.

Validated requirements are used as an input to two business analysis tasks,

including measuring solution performance as part of the Solution Evaluation

knowledge area. Table 6.14 summarizes these destination tasks and their

knowledge areas.

TABLE 6.14 Output: Validate requirements.

Output Output

Destinations

Destination Knowledge Area

319

Requirements

(validated)

Define design options. Requirements Analysis and

Design Definition

Measure solution

performance.

Solution Evaluation

All business analysis stakeholders are impacted by or involved in requirements

validation activities during your project. As the business analyst, you are

ultimately responsible for ensuring that the solution scope and requirements

align with the business requirements and deliver value to the organization.

Now let’s take a look at the next task in the Requirements Analysis and Design

Definition knowledge area—defining the requirements architecture.

Define Requirements Architecture

Project requirements should not be a jumble of information. Your requirements

need to be structured and organized into a cohesive set of information that is

complete, comprehensive, consistent, and understandable to your stakeholders.

You are responsible for deciding how to structure your individual requirements,

group those requirements, and show the relationships between them.

A good requirements architecture targets consistency, repeatability, and a high

level of requirements quality. The requirements should collectively support each

other and produce a useful outcome for the stakeholders.

The Requirements Architecture Answers the Following Questions for

the Business Analyst

Which models are appropriate for the business analyst to use?

How are the requirements structures relevant to different stakeholders?

In what ways do the models and requirements interact with and relate to

one another?

How do the parts of the requirements document fit into a cohesive

whole?

How do the requirements work together to achieve the overall

objectives?

How can trade-off decisions about requirements within this framework

be made?

Remember that requirements architecture and requirements traceability are

not the same thing. While traceability may represent and manage the

relationships between requirements, it does not prove the solution is a

cohesive whole that will actually work.

320

Figure 6.8 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used to define the requirements architecture.

FIGURE 6.8 Task summary: Define requirements architecture.

Several key inputs, guidelines, and tools are needed to help you define your

requirements architecture during requirements analysis and design. These key

inputs are produced by a number of other business analysis tasks and include

the requirements themselves, the information management approach, and the

solution scope. Let’s take a look at each of these task inputs in greater detail:

Requirements (Any State) The focus of requirements analysis and design

takes the requirements provided during elicitation and derives the real

requirements for your project. The requirements are analyzed, documented, and

modelled based on the requirements architecture you create with this task.

Information Management Approach Created during Business Analysis

Planning and Monitoring, the information management approach defines how

business analysis information will be stored and accessed.

Solution Scope The selected requirements architecture must describe the

solution scope fully and from all stakeholder perspectives. Think of the solution

scope as the frame for the more detailed picture you are painting with your

project requirements.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Guidelines are essentially instructions or descriptions on

why and how a business analyst will undertake a task. Tools, on the other hand,

are methods for conducting a business analysis task or shaping a task output.

Let’s take a look at the guidelines and tools that may also be used as inputs

when defining the requirements architecture:

Architecture Management Software Many business analysts use modelling

software to build and manage the requirements architecture. The focus is on the

321

volume, complexity, and version control for the information in the architecture

and the relationships it contains.

Legal/Regulatory Information Oftentimes, there are rules, regulations,

contracts, or standards-based constraints that must be incorporated into the

requirements architecture and followed.

Methodologies and Framework Many organizations have a predetermined

set of models and relationships between those models that are to be used in the

requirements architecture.

Table 6.15 summarizes the inputs, guidelines and tools to this task and lists the

task and knowledge area sources for each input used to define the requirements

architecture.

TABLE 6.15 Inputs, Guidelines, and Tools: Define requirements architecture.

Task Input Input

Type

Input Source Source Knowledge

Area

Requirements

(any state)

Input

Information

management

approach

Input Plan business analysis

information

management.

Business Analysis

Planning and

Monitoring

Solution scope Input Define change strategy. Strategy Analysis

Architecture

management

software

Guidelines

and tools

Legal/regulatory

information

Guidelines

and tools

Methodologies

and framework

Guidelines

and tools

There are several elements that business analysts should consider and address

when deciding how to structure and organize requirements on their projects,

such as the following:

Requirements viewpoints and views

Template architectures

Completeness

Relate and verify requirements relationships

Business analysis information architecture

Let’s look at each of these elements in greater detail:

Requirements Viewpoints and Views Viewpoints are templates for

specific stakeholder groups, defining how requirements will be represented,

organized, and related for each group. Viewpoints typically address the types of

models and model notations to be used, attributes to be included, and

322

relationships to be identified and maintained. Requirements documents using a

set of viewpoints from different perspectives make a stronger set of

requirements for your project.

The actual set of requirements and designs for a solution from a particular

viewpoint are referred to as a view. A collection of views makes up the

requirements architecture for a solution. Viewpoints tell you what information

to provide for each stakeholder group while views describe the actual

requirements and designs that are produced.

Template Architectures Many business analysts use predefined, template

architectures as the starting point for building a custom requirements

architecture. These architectural frameworks are typically a collection of

standard viewpoints across the organization.

Completeness A complete set of requirements should specify everything that

is needed at the appropriate level of detail. The requirements architecture

should help you assess if you have missed anything while building your

requirements document. Structuring requirements using different viewpoints

also helps with completeness and identifying potential gaps.

Relate and Verify Requirements Relationships Applying traceability

techniques as part of the Trace Requirements task shows the relationships

between requirements. When defining or using the requirements architecture,

business analysts also need to examine the traced requirements to make sure

the relationships meet certain quality criteria. Table 6.16 defines each item.

TABLE 6.16 Requirements relationships quality criteria

Criterion Description

Defined A relationship exists between the requirements, and the type of

relationship is described.

Necessary The relationship is necessary for understanding the

requirements.

Correct The elements have the relationship described.

Unambiguous There are no relationships linking elements in different or

conflicting ways.

Consistent Relationships are described in the same way with the same set

of standard descriptions in the viewpoints.

Business Analysis Information Architecture The business analysis

architecture is one type of information architecture. Interestingly enough, the

information architecture that is defined by the Information Management

Approach is a component of the requirements architecture. It defines

relationships for different types of information, such as requirements and

designs. The optimal approach is to define this architecture before setting up

information technology and infrastructure, such as requirements life cycle

management tools, architecture software, or document repositories.

There are several techniques that you may choose to apply when defining the

323

requirements architecture for your project. You should consider using

functional decomposition and organizational modelling to assist you in

determining what the best requirements architecture might be for your project.

Let’s take a look at these recommended techniques in greater detail right now.

Recommended Technique: Functional Decomposition

Functional decomposition breaks down or decomposes the solution scope into

its component parts based on a group of related functionalities. You can then

create a model of what needs to be done to deliver all or part of the solution.

Functional decomposition is an excellent way to break things into manageable

pieces and to understand the relationships between those pieces.

Functional decomposition is typically used during requirements analysis to

break an organizational unit or the solution scope into its component parts.

Each resulting part may have its own set of requirements. This is similar to

building a work breakdown structure (WBS) for a project where you break down

or decompose the project scope into phases, work packages, and deliverables.

The BABOK

Guide recommends breaking things down until the parts found at

the lowest level cannot be broken down further. You should then analyze each

part independently.

Recommended Technique: Organizational Modelling

Organizational modelling is used during requirements analysis to describe the

organizational units, the stakeholders, and the relationships between them. This

allows you the opportunity to structure your project requirements based upon

the needs of each stakeholder group.

Most of us have seen an organization chart showing the hierarchy of an

organization. This is an example of an organizational model. The model defines

the purpose and structure of an organization or an organizational unit. When

this technique is used for business analysis, an organization chart that shows the

organizational units, lines of reporting, the roles, and the people in those roles is

basically built.

Additional Techniques to Consider

The BABOK

Guide recommends using one or more of the following additional

techniques when you are defining the requirements architecture for your

project. They are summarized for you here:

Data Modelling Data models organize requirements by describing the

concepts and relationships between the concepts that are relevant to the defined

solution scope. Business analysts use this technique to describe the data

components of the requirements architecture.

Interviews Interviews are a way for the business analyst to speak directly to

key stakeholders to define the requirements architecture and structure in a

collaborative fashion.

324

Scope Modelling Scope models organize requirements based on the solution

components to which they are related. Solution components are parts of a

solution spanning the enterprise architecture of the organization, including

business processes, software applications, or hardware.

Workshops Workshops are a way for the business analyst to work with groups

of key stakeholders to define the requirements architecture and structure in a

collaborative fashion.

Once you have selected and applied one or more techniques as part of your

requirements architecture definition efforts, you are ready to continue with the

other requirements analysis tasks in this knowledge area. We will discuss those

tasks later in the chapter. First let’s look closely at the requirements architecture

output that helps you organize the requirements during your analysis work.

Produce the Requirements Architecture

The requirements architecture defines an organized structure for stakeholder

and solution requirements and the documented relationships between them.

The requirements structure defines the scope of each specific model or set of

requirements, and provides a location where each specific requirement can be

found. The requirements structure is not the same as traceability. Traceability

links related requirements. The requirements structure tells you where the

specific requirements for a project can be found.

One Size Does Not Fit All

Ginger was helping the IT department structure a set of requirements

documents for their IT projects. She was also tasked with building templates

for each of those documents so that project teams could use them

consistently across the organization. On first glance, this requirements-

focused consulting assignment seemed very straightforward. And it was—at

least until she started asking questions about the projects and the current

process for developing requirements.

The organization had projects in all sizes. They had extra-small

maintenance and support efforts lasting a few weeks and medium-size

software development projects lasting about six months or so. They were

doing agile development of their customer-facing websites and inline

capabilities in six-week sprints. They had small projects that were

noncritical and focused on a few months of work from a small team and

mission-critical complex projects lasting for a year or more and costing

millions of dollars.

Ginger quickly decided that this was not a “one size fits all” project

environment. The project teams would have to tailor her requirements

document set for their project type and scale it for the size of their efforts.

325

That would be the resulting requirements structure that they would use

during requirements development.

Using the project taxonomy that was provided, Ginger built a set of

requirements documents that could be tailored and scaled to fit the projects.

She also built a guidance document providing guidelines for scaling and

tailoring the requirements documents based on project type, complexity,

cost, and associated risks. This generic document set and guidance

document became part of the requirements development process and part

of the organizational process assets for the company.

Project teams used Ginger’s generic document set as an input to organizing

the requirements on their projects. They tailored and scaled the generic

documents to fit their projects within the provided framework. The resulting

requirements structure was used to document all of their project

requirements.

The requirements architecture is used as an input to defining the change

strategy and for analyzing the potential value of a particular solution. Table 6.17

summarizes these destination tasks and their knowledge areas.

TABLE 6.17 Output: Define requirements architecture.

Output Output Destinations Destination Knowledge Area

Requirements

architecture

Prioritize requirements. Requirements Life Cycle

Management

Assess requirements

changes.

Requirements Life Cycle

Management

Specify and model

requirements.

Requirements Analysis and

Design Definition

Define design options. Requirements Analysis and

Design Definition

A number of stakeholders are involved with defining the requirements

architecture. Remember that the primary responsibility for deciding how to

organize requirements falls to the business analyst. The project manager uses

the resulting organized set of requirements to verify solution scope and assess

the work that needs to be done. Other business analysis stakeholders

participating in requirements organization include the following:

Domain SME

Implementation SME

Project manager

Sponsor

Tester

Any stakeholder can use the requirements architecture to assess the

completeness of the requirements for a project.

326

Now let’s move on and look at the next task in the Requirements Analysis and

Design Definition knowledge area, Define Design Options.

Define Design Options

A design is a usable representation of a solution. For example, a text description,

a screen mockup, or prototype that represents a solution. A design option is the

possible form a solution might take. There are often multiple design options or

alternatives that can satisfy a set of requirements, which a business analyst

might represent as three different prototypes. Remember that design options

are tactical in nature versus the more strategic change strategy (solution) they

will be implementing. Over time, trade-off decision making is required in order

to choose the best design option to get the job done and achieve the desired

future state.

Is It a Design or a Solution?

As you become more deeply involved in a project, it’s easy to become lost in

the details. Remember, the BABOK

Guide defines terms to help you

maintain clarity.

Design A usable representation of a solution

Solution A specific way of satisfying a need

When you assess one or more solutions, be sure to evaluate the solution or

solutions relative to the approved stakeholder and solution requirements for

your project. If the requirements are not yet approved, you will not be able to

make a final decision on whether your solution meets the requirements,

addresses the business need, and provides value to the business.

You may find yourself assessing multiple design options to determine which

option is the best. The option you choose must meet the stakeholder and

solution requirements and address the business need. You will evaluate and

compare each option with the requirements, as well as with one another. You

are in search of the design option that delivers the most value to the business, so

you will compare the advantages and disadvantages of each proposed solution.

Figure 6.9 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used to assess a proposed design option or a set of design

options.

327

FIGURE 6.9 Task summary: Define design options.

Several key inputs are needed to adequately define design options. These key

inputs are produced by a number of other business analysis tasks; they include

the change strategy and the requirements architecture discussed in the previous

section. Let’s look at each of these task inputs in greater detail:

Change Strategy The change strategy, defined during Strategy Analysis,

describes the approach that will be taken to achieve the desired future state.

This impacts the design options for tactically getting from the current state to

this future state.

Requirements (Validated, Prioritized) Prioritized and validated

stakeholder and solution requirements allow you to define design options and

solution components relative to the most important requirements on your

project.

Requirements Architecture The requirements architecture defines the full

set of requirements and their relationships. This information is required when

defining design options to make sure you don’t miss anything.

There are additional inputs that may be used by business analysis tasks:

guidelines and tools. Let’s take a look at the guidelines and tools that may also

be used as inputs when defining design options:

Existing Solutions On many projects, existing products or services are

components of one or more design options. This includes third-party products

and services that were built external to the organization.

328

Future State Description The future state description, defined in Strategy

Analysis, describes the desired future state of the enterprise. The design options

being defined are part of this future state and should be evaluated relative to

where the enterprise wants to be when the solution is implemented and

operational.

Requirements (Traced) Traced requirements should be used when defining

design options to make sure all known requirements are fulfilled by the

solution.

Solution Scope Solution scope provides the boundaries for the design options

by telling the business analyst what is in and out of scope for the solution.

Table 6.18 summarizes the inputs, guidelines, and tools for this task; it also lists

the task and knowledge area sources for each input used to assess the proposed

solution.

TABLE 6.18 Inputs, Guidelines, and Tools: Define design options.

Task Input Input

Type

Input Source Source Knowledge

Area

Requirements

(validated,

prioritized)

Input Prioritize

requirements.

Requirements Life Cycle

Management

Input Validate

requirements.

Requirements Analysis

and Design Definition

Change strategy Input Define change

strategy.

Strategy Analysis

Requirements

architecture

Input Define

requirements

architecture.

Requirements Analysis

and Design Definition

Existing solutions Guidelines

and tools

Future state

description

Guidelines

and tools

Define future

state.

Strategy Analysis

Requirements

(traced)

Guidelines

and tools

Trace

requirements.

Requirements Life Cycle

Management

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

When you perform the Define Design Options task, you are expected to address

the several elements of that task. These elements guide you in getting the task

done by doing the following:

Defining solution approaches

Identifying improvement opportunities

Allocating requirements

329

Describing design options

Let’s take a look at each element in greater detail:

Define Solution Approaches The solution approach describes how you will

go about building and implementing the solution itself. Solution components

may be created or purchased, or perhaps some combination of “build and buy”

will be used.

Identify Improvement Opportunities Improvement opportunities often

occur when you are defining design options. There may be an opportunity to

increase efficiency by automating or simplifying the work that people perform.

The solution may be able to provide better access to information.

You might also find that your design options identify capabilities beyond the

required capabilities found in your stakeholder or solution requirements. You

will need to decide whether these additional solution capabilities provide value

to the organization, either now or in the future.

Allocate Requirements Requirements allocation assigns requirements to

solution components and releases. One goal of requirements allocation is to

maximize benefits and reduce costs for implementing the solution.

Requirements are typically allocated between organizational units, job

functions, solution components, or solution releases. This activity is ongoing,

beginning when the solution approach is determined and ending after design

and implementation of the solution.

Describe Design Options Design options are often developed in parallel with

defining the desired future state as part of Strategy Analysis. It is essential that

the design options for each design component be valid for the future state.

Design options can describe many things, such as the following:

Business policies and rules

Business processes

People operating and maintaining the solution

Operational business decisions

Software applications and application components used in the solution

Organizational structures and internal/external interactions

Several techniques are available for defining design options. For instance, you

should consider adding vendor assessment to your list of possibilities. Let’s take

a look at this recommended technique in greater detail right now.

Recommended Technique: Vendor Assessment

Vendor assessments allow you to assess an external vendor’s ability to provide

all or part of your solution. You look at their technical ability, financial stability,

staff skills, and reputation in their workspace. External vendors are often

involved in the design, construction, implementation, and maintenance

activities on our projects.

330

Here is a quick list of things you may want to consider:

Knowledge and expertise

Experience, reputation, and stability

Licensing and pricing models

Product reputation and market position

Contractual terms and conditions

Vendor assessments are used to ensure that your vendors are reliable and that

they will be able to meet your expectations.

Additional Techniques to Consider

The BABOK

Guide recommends several techniques when you are defining

design options for your project. These techniques are summarized for you here:

Benchmarking and Market Analysis Benchmarking studies are a source of

business analysis information, comparing an aspect of the system with an

external baseline. Market analysis is a mechanism for determining what

external customers want and what your competition provides. Both can be used

to identify and analyze existing solutions and market trends.

Brainstorming This technique is used during analysis to generate many ideas

from a stakeholder group in a short period of time. The resulting ideas can then

be organized and prioritized to identify improvement opportunities and design

options.

Document Analysis Business analysts use document analysis to confirm

analysis results against existing documents, source information, and other

elicitation results. This technique provides information to describe existing

solutions, design options, and design elements.

Interviews Interviews involve asking questions of stakeholders to uncover

needs, identify problems, or discover opportunities during the requirements

analysis process. This technique is used to identify improvement opportunities

and design options.

Lessons Learned Lessons learned provide a great way to identify

improvement opportunities during requirements analysis activities based upon

what others have experienced with previous products and services.

Mind Mapping Mind mapping is a visual, nonlinear, collaborative way of

generating, organizing, and prioritizing many ideas from a group of

stakeholders. This technique can be used to identify and explore possible design

options during requirements analysis.

Root-Cause Analysis This technique helps the business analysts and the key

stakeholders understand the underlying cause of problems being addressed by a

change and to propose design options to address those problems.

Survey or Questionnaire Surveys and questionnaires allow the business

analyst to discover business analysis information about customers, products,

331

work practices, and attitudes in a structured way from a group of stakeholders.

During analysis, they can be used to identify improvement opportunities and

design options.

Workshops Workshops are a collaborative and facilitated way to identify

improvement opportunities and design options with a group of stakeholders.

Once you have selected and applied one or more of these techniques as part of

your design option definition efforts, you are ready to continue with the one

remaining analysis and design task at hand. We will discuss that task shortly.

Defining the Design Options

Design options describe ways to satisfy one or more needs, such as the solution

approach, potential improvement opportunities that are part of the design

option, and the components defining the design option. Each of these ways

requires the business analyst to assess the value that each design option delivers

to the business. Your project’s validated and prioritized requirements are used

as an input for defining design options. Table 6.19 summarizes the destinations

for the results of your efforts.

TABLE 6.19 Output: Define design options.

Output Output Destinations Destination Knowledge

Area

Design

options

Define change strategy. Strategy Analysis

Analyze potential value and

recommend solution.

Requirements Analysis and

Design Definition

Remember that the design options should be based on the prioritized and

validated requirements for your project. Several key business analysis

stakeholders might be involved in the selection process when design options are

being defined. The project manager will need to plan and manage this definition

process as part of the project. Other stakeholders participating in defining

design options include the following:

Domain SME

Implementation SME

Operational support

Suppliers

Now let’s take a look at the next task found in the Requirements Analysis and

Design Definition knowledge area—analyzing the potential value and

recommending a solution.

Analyze Potential Value and Recommend Solution

The final task in the Requirements Analysis and Design definition knowledge

area is estimating and modelling the potential value of each design option and

332

figuring out which option is the most appropriate option for the enterprise.

Potential value is typically analyzed many times over the course of a change.

Remember the “do nothing” option may also be the best recommendation based

upon what you know.

The business value of design options and solution approaches changes

depending on how requirements are implemented. Some solution

implementation approaches cost more money but take less time to perform,

such as purchasing a proven commercial product versus developing your own

software application. On the flip side, some solution implementation

approaches are low cost but may eliminate capabilities in the initial deployment.

These low-cost alternatives fail to provide end users with the complete

functionality needed to do their jobs.

Figure 6.10 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used for estimating and modelling the potential value of each

design option that was defined and figuring out which option is the most

appropriate option for the enterprise.

FIGURE 6.10 Task summary: Analyze potential value and recommend

solution.

Several key inputs are needed to analyze potential value and recommend a

solution. These key inputs are produced by other business analysis tasks. They

include potential value and the design options. Let’s look at each of these task

inputs in greater detail:

Potential Value Potential value is often described in financial terms. It can be

333

used as a benchmark against the value a particular design option may deliver to

the enterprise.

Design Options Design options describe ways to satisfy one or more needs,

such as the solution approach, potential improvement opportunities that are

part of the design option, and the components defining the design option.

Design options are evaluated and compared to one another in order to select

and recommend one option for the solution.

There are additional inputs that may be used by business analysis tasks:

guidelines and tools. Let’s take a look at the guidelines and tools that can also be

used as inputs for this task:

Business Objectives Business objectives are measurable results used to

indicate a business goal has been achieved. They can also be used to calculate

the expected benefits of a design option or solution approach.

Current State Description Defined in Strategy Analysis, the current state

describes the existing context within which the work will be completed. The

current state provides a baseline to identify and quantify the value delivered by

the solution.

Future State Description The future state description describes the desired

future state of the enterprise. The design options being defined are part of this

future state and should be evaluated relative to where the enterprise wants to be

when the solution is implemented and operational.

Risk Analysis Results Assessing risks is a necessary step in analyzing the

potential value of design options. There is a level of risk associated with each

option that needs to be explored and assessed before decisions are made.

Solution Scope Solution scope provides the boundaries for the design options

by telling the business analyst what is in and out of scope for the solution.

Table 6.20 summarizes the inputs to this task and lists the task and knowledge

area sources for each input used to assess proposed solutions.

TABLE 6.20 Inputs, Guidelines, and Tools: Analyze potential value and

recommend solution.

Task Input Input Type Input Source Source Knowledge Area

Potential value Input Define future

state.

Strategy Analysis

Design options Input Define design

options.

Requirements Analysis and

Design Definition

Business

objectives

Guidelines

and tools

Define future

state.

Strategy Analysis

Current state

description

Guidelines

and tools

Analyze

current state.

Strategy Analysis

Future state

description

Guidelines

and tools

Define future

state.

Strategy Analysis

334

Risk analysis

results

Guidelines

and tools

Assess risks. Strategy Analysis

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

The elements to be considered when analyzing the potential value of design

options and recommending a solution are as follows:

Describing expected benefits

Defining expected costs

Determining value

Assessing design options and recommending a solution

Let’s look at each of these elements in greater detail:

Expected Benefits Expected benefits are the positive values that a solution

delivers to stakeholders and the enterprise. A solution’s value can consist of

benefits, reduced risk, compliance, improved usability, or any other positive

outcome. Benefits can be calculated for individual requirements, for groups of

requirements, or for the overall initiative. Benefits are typically realized over

time, often after the solution is implemented and operational.

Expected Costs Expected costs are the “flip side” of expected benefits. They

are the negative value associated with a solution, such as the cost to acquire,

build, or maintain that solution. Expected, or negative, costs include many

things, such as resources, operating costs, purchase costs, and maintenance

costs.

Exam Spotlight

Business analysts should also remember to look at the opportunity costs

when estimating the expected cost of a change. Opportunity costs are

alternative results that might have been achieved if resources, time, and

funds were allocated to a design option that was not selected. The

opportunity cost of any deign option equals the value of the best alternative

design option that was not selected.

Determine Value The potential value of a solution equals the sum of the

expected benefits and the associated costs of those benefits. A positive value

means that the benefits exceed the costs, while a negative value means that the

costs exceed the benefits. The value should be determined at the enterprise level

versus for a single group of stakeholders. This potential value is uncertain

because of the tangible and intangible costs that are part of the estimating

process.

Assess Design Options and Recommending Solution Each design option

is assessed based on its potential value. Understanding the cost and effort

335

required for each solution component is an essential step in evaluating and

recommending what should be done. The BABOK

Guide recommends taking

three factors into account during this process: available resources, solution

constraints, and requirements dependencies. Table 6.21 takes a closer look at

each factor.

TABLE 6.21 Assessment factors to consider

Factor Description

Available

resources

Allocated resources can impact or limit getting work done to

implement the requirements. Sometimes, a business case must

be used to justify additional resources to get things done.

Solution

constraints

Regulatory requirements may impact how requirements are

implemented in the solution. They can also drive requirements

prioritization.

Requirements

dependencies

Some capabilities support other high-value requirements in the

solution yet provide limited capabilities to the organization.

There are several techniques that you may choose to apply when analyzing

potential value and recommending a solution. Let’s take a quick look at those

techniques now.

Techniques to Consider

The BABOK

Guide recommends using one or more techniques to analyze

potential value and recommend a solution. These techniques are summarized

for you here:

Acceptance and Evaluation Criteria One best practice is defining

measurable acceptance criteria for each of your project releases. The criteria

define the set of requirements that must be met in order for your release and its

accompanying capabilities to be considered acceptable to its key stakeholders.

Test cases will be written to verify the release using this defined acceptance

criteria.

Backlog Management The backlog records, tracks, and prioritizes remaining

work. Managed backlogs put work items at the top of the list with the highest

business value, making these items the next things to be worked on.

Brainstorming Brainstorming allows a business analyst to identify potential

business benefits of the requirements in a collaborative fashion with

stakeholders.

Business Cases Be sure to compare the design options, their potential value to

the enterprise, and the resulting recommendations against the business goals

and initiatives contained in the business case.

Business Model Canvas This planning and monitoring tool is used to

understand strategy and initiatives relative to the current state of the business.

Decision Analysis Decision analysis allows you to examine and model the

336

costs and benefits of different requirements allocation schemes before making

or recommending a particular decision.

Estimation Estimating techniques are used to forecast the cost and effort of

meeting requirements and to provide financial information with which to rank

the design options and select the option to recommend.

Financial Analysis There are many financial techniques business analysts can

use to evaluate the financial return of different design options and choose the

best possible return on investment (ROI).

Focus Groups Focus groups allow you to get stakeholder input on which

design options best meet the requirements and to understand the stakeholder’s

value expectations relative to the solution.

Interviews Interviews are a face-to-face way to get stakeholder input on which

design options best meet the requirements and to understand the stakeholder’s

value expectations of the solution.

Metrics and Key Performance Indicators (KPIs) As part of analyzing the

potential value of design options, business analysts create and evaluate the

measurements used to determine value.

Risk Analysis and Management This technique identifies and manages

risks that could affect the potential value of the requirements, the design

options, and the resulting solution.

Survey or Questionnaire Surveys and questionnaires allow for stakeholder

input on which design options best meet the requirements and understand the

stakeholder’s value expectations.

SWOT Analysis Strengths, Weaknesses, Opportunities, and Threats (SWOT)

analysis is another technique that can be used to identify areas of strength and

weakness that impact the solution value.

Workshops Workshops or structured reviews are an excellent way to get

stakeholder input on which design options best meet requirements and

understand the stakeholder’s value expectations.

Once you have selected and applied one or more of these techniques as part of

your efforts, you are ready to continue with the other requirements analysis and

design tasks. First, let’s look at the key output from this task, the solution

recommendation.

Produce the Solution Recommendation

The solution recommendation identifies the most appropriate solution based

upon evaluating all defined design options. The recommended solution targets

maximizing the value provided to the enterprise. Table 6.22 summarizes these

destinations for the results of your task efforts.

TABLE 6.22 Output: Analyze potential value and recommend solution.

Output Output

Destinations

Destination Knowledge

Area

337

Solution

recommendation

Define change

strategy.

Strategy Analysis

A number of stakeholders are involved with analyzing potential value and

recommending a solution on your project. You should always involve project

managers in the selection process; they need to be aware of what is happening

in order to manage project scope and project work. End users should also be

made aware of your selection results because they will be impacted by the

capabilities that will be present in a given design option or solution component.

A number of additional business analysis stakeholders may be affected by your

requirements allocation work, including the following:

Customer

Domain SME

Implementation SME

Regulator

Sponsor

Now let’s wrap up our review of the Requirements Analysis and Design

Definition knowledge area.

338

How This Applies to Your Projects

In this chapter, you stepped through the tasks guiding you in analyzing the

requirements for your project. One of the biggest challenges that you will

encounter on your projects is making sure that the requirements you develop for

your projects are testable. As you develop your stakeholder and solution

requirements, keep asking yourself for each and every requirement: Can I prove

that this requirement has been met in the resulting solution? If the answer is no,

then you need to rewrite that requirement to make it measurable and testable. If

the answer is yes, you need to figure out how you will acquire that proof. That

means you should put on your tester’s hat and start thinking about your fit

criteria while you are specifying and modelling your requirements. Fit criteria

define the measurable goals that determine whether solution testing satisfies

the original requirements for that solution. This is true for every requirement

that you write.

Fit criteria are quantified and testable statements of a requirement that show

the requirement has indeed been met. They can be applied to both functional

and nonfunctional requirements. Let’s take a look at more details about defining

the fit criteria for each type of solution requirement you may write, functional

and nonfunctional.

Remember, functional requirements are capabilities that the solution or a

solution component must have. Your fit criteria are the yardstick that is used to

test whether those capabilities have been successfully implemented. They are a

quantified goal, containing numbers or measurements that your solution has to

meet. As you write your functional requirements, you should ask yourself the

following:

Has the function been successfully implemented?

Do the results satisfy the originator of the requirement?

What are the defined user acceptance criteria?

If you have a functional requirement to calculate a certain value, then the fit

criteria for that requirement are that the calculation results conform to the

intended result. Your fit criteria should satisfy the source of your requirement.

Either the source is capable of saying that they are satisfied, or the result of the

action taken will be measurable and consistent with a standard set for that kind

of action.

Nonfunctional requirements are properties or characteristics that your solution

or a solution component must have. The fit criteria quantify the necessary

behavior or quality indicated by the nonfunctional requirement. Some

nonfunctional requirements might at first seem a little hard to test. Writing fit

criteria for nonfunctional requirements is a matter of finding the appropriate

quantification. For nonfunctional requirements, you should ask yourself if you

can quantify the defined behaviors or properties that the solution using these

quality characteristics must have.

339

Summary

The six tasks in the Requirements Analysis and Design Definition knowledge

area guide you as you analyze the stakeholder and solution requirements for

your project. Requirements analysis is one of the most challenging activities for

business analysts, even experienced ones. There are many ways to organize,

document, and model your requirements in order to define what your solution

will do for its users. It is up to you to be familiar with all of the options and to

make the right decisions on documentation and models based on the nature of

your project and the preferences of your organization and your stakeholders.

Effective technical writing and graphical modelling skills are an underlying

competency enabling you to do this requirements analysis work. Successful

projects start with defining and agreeing to what is needed. Without the ability

to analyze your stakeholder’s stated requirements and determine the real

requirements for your project, you will find it difficult to deliver a successful

solution to your stakeholders.

The BABOK

Guide recommends that you apply one or more techniques to

specify and model the stakeholder and solution requirements for your projects.

You don’t need to be an expert in every modelling technique, but most

experienced business analysts are comfortable using a representative subset of

those techniques. Each requirements modelling technique should be evaluated

to see whether it fits the nature of your project and your requirements. Using

object-oriented modelling techniques for a traditional, relational database

project would be cumbersome at best.

A number of deliverables are produced by the tasks in this knowledge area,

including the ultimate deliverable of requirements analysis: your validated

stakeholder or solution requirements for your project. These requirements form

the basis for your design and development efforts later in the project life cycle.

340

Exam Essentials

Be able to list the tasks found in the Requirements Analysis and

Design Definition knowledge area. You will see questions about the tasks,

their associated techniques, their more detailed elements, and the key outputs

that they produce on your exam. You should memorize the tasks of this

knowledge area and the key outputs associated with them. The six tasks are as

follows:

Specify and model requirements.

Verify requirements.

Validate requirements.

Define requirements architecture.

Define design options.

Analyze potential value and recommend a solution.

Be able to understand and apply the modelling techniques

recommended for use during requirements analysis and design.

Understanding and applying the modelling techniques to model requirements is

a key focus for your Requirements Analysis and Design Definition knowledge

area exam questions. Be sure that you can name these techniques and that, at a

high level, you know what they are all about. Here’s the list:

Business Capability Analysis

Business Rules Analysis

Concept Modelling

Data Flow Diagrams

Data Modelling

Decision Modelling

Functional Decomposition

Interface Analysis

Mind Mapping

Organization Modelling

Process Modelling

Prototyping

Roles and Permissions Matrix

Root Cause Analysis

Scope Modelling

Sequence Diagrams

341

State Modelling

Use Cases and Scenarios

User Stories

Be able to distinguish between validated requirements and verified

requirements. Validated requirements are stakeholder, solution, or transition

requirements that are aligned with the business goals and objectives found in

your project’s business requirements or business case. Verified requirements are

stakeholder, solution, or transition requirements that have been reviewed and

are correctly defined at an acceptable level of detail. They are requirements of

sufficient quality to allow further project work based on those requirements to

be done.

Be able to list and explain the nine characteristics of well-written

requirements. The nine characteristics of well-written, high-quality

requirements are as follows:

Atomic

Complete

Consistent

Concise

Feasible

Unambiguous

Testable

Prioritized

Understandable

Be able to distinguish between viewpoints, views, design options,

solution components, and the solution approach. Be sure you know the

differences between these five concepts for a particular initiative. These terms

are closely related but very different.

Viewpoints: Stakeholder-focused templates, standards, and guidelines that

define how requirements will be represented, organized, and related to one

another

Views: Name given to the actual requirements and designs for a particular

solution from a chosen stakeholder viewpoint. A collection of views makes

up the requirements architecture for a specific solution.

Design Options: Possible ways to satisfy one or more needs in a solution

Solution Components: Subparts of a solution, such as people,

infrastructure, hardware, or software

Solution Approach: How to go about building and implementing the

solution, such as whether solution components will be created, purchased, or

some combination of both

Be able to describe the five categories of models used in requirements analysis

342

and provide an example of each type. The five categories of models used in

requirements modelling are as follows:

People and Roles

Rationale

Activity Flow

Capability

Data and Information

343

Key Terms

You have just finished stepping through the contents of the fifth knowledge area

from the BABOK

Guide: Requirements Analysis and Design Definition. There

is one more knowledge area to go after this one, so stay tuned.

You should understand how to apply the techniques and tasks in this knowledge

area in order to be an effective business analyst. Additionally, you will need to

know the six tasks and their associated elements and techniques from this

knowledge area in order to be successful on the CBAP

or CCBA

™

exams. The

tasks include the following:

Specify and model requirements.

Verify requirements.

Validate requirements.

Define requirements architecture.

Define design options.

Analyze potential value and recommend a solution.

Chapter 6 has a number of new key words related to analyzing stakeholder and

solution requirements on your projects. Here is a list of some of the key terms

you encountered in this chapter:

behavioral business rules

component

conceptual data models

data flow diagrams (DFDs)

decompose

definitional business rules

design option

expected benefits

expected costs

formal models

functional decomposition

informal models

logical data models

metadata

opportunity costs

organizational modelling

344

physical data models

potential value

process models

releases

requirements allocation

requirements architecture

sequence diagrams

solution approach

solution components

state modelling

user stories

validated requirements

view

viewpoints

345

Review Questions

1. The tasks and techniques in the Requirements Analysis and Design

Definition knowledge area are used to define what types of requirements?

A. Business and stakeholder

B. Stakeholder and transition

C. Solution and stakeholder

D. Transition and solution

2. What requirements analysis task ensures that solution requirements align to

the business requirements?

A. Validate requirements.

B. Verify requirements.

C. Prioritize requirements.

D. Specify requirements.

3. When reviewing a set of related requirements, you discover that two of the

requirements describe the same feature but produce different results. Based

on your well-written requirements checklist, you would note that these

requirements are not ____________.

A. Complete

B. Consistent

C. Testable

D. Concise

4. Data flow diagrams show how ____________ flows through a system.

A. Processes

B. Requirements

C. Decisions

D. Information

5. What is the name for an abstraction representing some or all of a proposed

solution?

A. Diagram

B. Concept

C. Matrix

D. Model

6. What is defined as a sequence of repeatable activities executed in an

organization?

346

A. Rule

B. Event

C. Process

D. Object

7. During requirements analysis, you are selecting a modelling technique to

represent the rationale or “why” of a proposed change. Which modelling

technique would be the best choice?

A. Organizational modelling

B. Decision modelling

C. Functional decomposition

D. State modelling

8. What component of an entity-relationship diagram is contained in the

labeled rectangle and represents a source or destination of data?

A. Attribute

B. Relationship

C. Entity

D. Constraint

9. Which of the following is a task performed as part of requirements analysis?

A. Specify and model requirements.

B. Manage solution scope and approach.

C. Prepare requirements package.

D. Manage requirements traceability.

10. Activity flow models show how the system behaves over the course of time

through the:

A. Structures describing what is important to the enterprise

B. Execution of business processes or a series of events

C. Set of related set classes and associations between them

D. Business’s policies, guidelines, standards, and regulations

11. During requirements analysis, the business analysis team created the

structure for all of the requirements of the proposed change. What was

created?

A. Requirements viewpoints

B. Requirements packages

C. Requirements architecture

D. Requirements components

347

12. What imposes limitations on your solution?

A. Attributes

B. Constraints

C. Assumptions

D. Priorities

13. All of the following are examples of improvement opportunities that may be

found when proposing design options except:

A. Increase efficiencies.

B. Improve information access.

C. Identify additional capabilities.

D. Include performance measures.

14. What is the purpose of nonfunctional requirements?

A. Addressing educational needs of users interacting with the solution

B. Defining quality attributes and design constraints of the solution

C. Protecting and preventing access to data that the solution uses or creates

D. Describing the likely growth of use of the deployed and maintained

solution over time

15. You are currently reviewing a specific requirement to see if it is atomic. What

is an atomic requirement?

A. Operationally feasible and fits within budget and schedule constraints

B. Logically structured in a related group and able to be changed

C. Technically feasible with a wide range of implementation options

D. Self-contained and capable of being understood independently

16. Which technique organizes your requirements based on the solution

components to which they are related?

A. Data dictionary

B. Business rules

C. Scope modelling

D. Class diagram

17. The output from specifying and modelling requirements is:

A. Specified and modelled requirements

B. Specified and traceable requirements

C. Verified and modelled requirements

D. Prioritized and validated requirements

18. What is the name for the individual pieces of information that describe an

348

entity in an entity relationship diagram?

A. Identifier

B. Relationship

C. Attribute

D. Cardinality

19. What is another name for the quality check performed following analysis of a

requirement?

A. Verification

B. Validation

C. Approval

D. Clarification

20. Assumptions and constraints defined and clarified as requirements are

understood and documented with their associated:

A. Limitations

B. Attributes

C. Restrictions

D. Requirements

349

Chapter 7

Controlled End: Solution Evaluation

350

CBAP

/CCBA

™

EXAM TOPICS COVERED IN THIS

CHAPTER:

Measure solution performance.

Analyze performance measures.

Assess solution limitations.

Assess enterprise limitations.

Recommend actions to increase solution value.

Solution Evaluation provides care and feeding for your

selected solution across the project life cycle. The tasks found in this knowledge

area focus on assessing solution performance and the value delivered by the

solution to the enterprise. The transition requirements are also developed as

part of this knowledge area. Transition requirements define how the solution

will be implemented after the project work is complete.

Care and feeding of a solution has many facets. One important aspect is the

benefits realization aspect of a solution once that solution is being used. During

a solution’s operational life, you will want to measure its performance and

quantify the business value it delivers. Keep in mind that there are many ways to

implement a solution once it has been selected. Experienced business analysts

always make sure that the solution is defined, designed, and implemented well.

351

Solution Evaluation

The Solution Evaluation knowledge area focuses on ensuring that the solution

can be successfully implemented within the organization in order to meet the

business need driving your project. You must have knowledge of your business

environment and be able to assess how each of your project’s proposed solutions

would affect that environment. Communicating solution requirements and

implementation-specific information to your stakeholders is also your

responsibility.

According to the BABOK

Guide, this knowledge area is where you will develop

your project’s transition requirements. Transition requirements describe the

solution capabilities required to transition from the current organizational state

to the future state. Transition requirements are no longer needed once the

transition to the new solution is complete.

Remember that the business requirements are developed by tasks in the

Strategy Analysis knowledge area, and your stakeholder and solution

requirements are built by tasks found in the Requirements Analysis and Design

Definition knowledge area.

Exam Spotlight

An important distinction between Solution Evaluation and other knowledge

areas is the existence of an actual solution. Solution Evaluation tasks can be

performed on solution components in varying stages of development,

including the following:

Prototypes or proofs of concept

Pilot release or Beta release

Operational releases

The tasks in this knowledge area follow the solution from early in the project life

cycle, where the solution begins to take form, to the end of the life cycle, where

the project itself ends and the solution is deployed. This solution-focused

knowledge area generates several key business analysis outputs. They include

the following:

Solution performance measures

Solution performance analysis

Solution limitation

Enterprise limitation

Recommended actions

352

We will cover each output in more detail later in this chapter.

To focus on what is important to business analysts across the life cycle of their

business analysis efforts, let’s consider the tasks of this knowledge area with the

framework of the BACCM™. Business analysts need to keep an eye on their

work relative to the six concepts contained in the framework: changes, needs,

solutions, stakeholders, value, and context. Table 7.1 lists these responsibilities.

TABLE 7.1 The BACCM™: Solution Evaluation

Core

Concept

The Business Analyst’s Responsibilities

Change Recommend a change to the solution or the enterprise in order

to realize a solution’s potential value.

Need Evaluate how a solution or solution component is fulfilling a

business need.

Solution Assess solution performance to see if it is delivering the potential

value.

Stakeholders Elicit information from stakeholders about solution performance

and value delivery.

Value Determine if a solution is delivering potential value and examine

why a value may not be being realized.

Context Determine solution performance measures and limitations

within the context of the project and the enterprise.

Many commonly used Solution Evaluation techniques can be applied for each

knowledge area task. Solution Evaluation work is multifaceted and applies a

wide range of techniques for validating the solution and its components relative

to the business case and allocating the stakeholder and solution requirements to

the solution components and releases.

The Solution Evaluation knowledge area also addresses monitoring and

reporting on the performance of the assessment and validation activities across

the project life cycle. It includes a task specifically focused on assessing the

solution performance after the solution is operational and in use. The business

analysis team is responsible for assessing the effectiveness of the techniques

being used to assess and validate their project’s resulting solution. The Solution

Evaluation knowledge area is found in Chapter 7 of the BABOK

Guide.

The Business Analyst’s Task List

A business analyst has five tasks to perform in the Solution Evaluation

knowledge area. We will look at each one of these tasks in detail later in this

chapter. The task list from the BABOK

Guide includes the following:

Measuring solution performance

Analyzing performance measures

Assessing solution limitations

353

Assessing enterprise limitations

Recommending actions to increase solution value

These tasks focus on making sure you select the best solution to meet your

project’s business need and that you define, design, and implement that solution

well. Your ultimate goal is to deploy the right solution that meets the business

need and adds value to the business. You know your business environment and

can assess how each proposed solution would affect that environment. You must

also ensure that your project stakeholders fully understand the prioritized and

approved solution requirements. Any implementation decisions that are being

made during Solution Evaluation should align with those requirements.

When Does Solution Evaluation Take Place?

When the territory and the map disagree, believe the territory.

—Swiss Army Manual

The tasks in the Solution Evaluation knowledge area begin early in the project

life cycle as the solution to the business problem or need is proposed, evaluated,

and agreed upon. The tasks in this knowledge area appear in both the controlled

middle and controlled end of the generic life cycle described in Chapter 1,

“Foundation Concepts.” The controlled middle of a project is where the actual

work gets done, one stage or phase at a time. Business analysis tasks during this

part of your project are typically from the Elicitation and Collaboration,

Requirements Analysis and Design Definition, and Solution Evaluation

knowledge areas with a little Requirements Life Cycle Management thrown in

for good measure.

Specific tasks in the Solution Evaluation knowledge area focus on the controlled

end to your project. In addition to wrapping things up, you also plan how you

will transition the new solution into its operational life and get ready to

measure the business benefits of the solution after it is in use. Typically,

defining the transition requirements on your projects takes place in the

controlled middle or early on in the controlled end of the project life cycle as

part of the project’s requirements development or definition phase.

Exam Spotlight

Approximately 16 percent of your exam questions focus on the Solution

Evaluation knowledge area. These exam questions target specific and

detailed aspects of the tasks, tools, and techniques that are found in the

knowledge area.

Let’s step through the first task in the Solution Evaluation knowledge area:

defining performance measures so you can collect data and actually measure a

solution’s performance.

354

Measure Solution Performance

The first task in the Solution Evaluation knowledge area is defining performance

measures for collecting solution performance data and measuring the

performance of a newly deployed or an existing solution. Performance is

typically measured using key performance indicators (KPIs), project goals and

objectives, process performance targets, or software application testing.

Figure 7.1 summarizes the inputs, guidelines/tools, outputs, techniques, and

associated tasks used to measure solution performance.

FIGURE 7.1 Task summary: Measure solution performance.

Several key inputs are needed to adequately measure solution performance.

These key inputs are produced by a number of other business analysis tasks;

they include business objectives and the solution to be measured. Let’s look at

each of these task inputs in greater detail.

Business Objectives Business analysts use the defined business objectives to

make sure that the solution will deliver measurable results to the enterprise.

Implemented Solution (External) A solution or solution component is

required in order to measure performance. The solution may be an

implemented solution, a prototype, or a beta solution.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Guidelines are essentially instructions or descriptions on

why and how a business analyst will undertake a task. Tools, on the other hand,

are methods for conducting business analysis tasks or shaping a task output.

Let’s take a look at the guidelines and tools that can also be used as inputs when

measuring solution performance:

Change Strategy The change strategy is a high-level plan of key activities and

events relative to a proposed change. Be sure to reference this information when

355

creating performance measures for your solution.

Future State Description The future state description provides a definition

of the boundaries for the solution scope and all of the solution components. It

also links back to the potential value expected from this future state.

Requirements (validated) Validated requirements have been analyzed and

appraised to determine their potential value.

Solution Scope Solution scope defines the solution boundaries for what is in

scope and what is out of scope. These boundaries are used to measure and

evaluate a solution.

Table 7.2 summarizes the inputs, guidelines, and tools for this task and lists the

task and knowledge area sources for each input used to assess proposed

solution.

TABLE 7.2 Inputs, Guidelines, and Tools: Measure solution performance.

Task Input Input

Type

Input

Source

Source Knowledge Area

Implemented

solution (external)

Input

Business objectives Input Define future

state.

Strategy Analysis

Change strategy Guidelines

and tools

Define change

strategy.

Strategy Analysis

Future state

description

Guidelines

and tools

Define future

state.

Strategy Analysis

Requirements

(validated)

Guidelines

and tools

Validate

requirements.

Requirements Analysis and

Design Definition

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

When you perform the Measure Solution Performance task, you are expected to

address the three detailed elements of that task. These elements guide you in

measuring existing or new solution performance on your projects by doing the

following:

Defining solution performance measures

Validating solution performance measures

Collecting solution performance measures

Let’s take a closer look at each of these task elements now:

Defining Solution Performance Measures The first step in defining

solution performance measures is to take a look at any existing performance

measures and methods. Make sure the existing measures are both accurate and

relevant to the new solution. Common sources for performance measures

include business goals, objectives, and processes as well as any legal or

356

regulatory constraints on the solution.

Exam Spotlight

Solution performance measures may be quantitative, qualitative or both,

depending on the value being measured. Quantitative measures are

numerical, countable, or finite, such as measuring amounts, quantities, or

times. Qualitative measures are more subjective in nature, such as attitudes

and perceptions of a solution and its operations. Be sure you can distinguish

between these two types of measures for your exam.

Validating Solution Performance Measures Solution performance

measures should be validated with key stakeholders to ensure the measures are

useful and relevant. More detailed performance measures should align with the

higher-level performance measures for the solution or for the enterprise.

Collecting Solution Performance Measures Statistical sampling

techniques are often used to collect solution performance measures. Be sure to

consider the volume or sample size for the initiative so you collect enough data

and achieve accurate results. The frequency and timing of measurements are

also critical. Watch the currency of your data as well. Measurements that are

more current tend to be more representative of solution performance than older

data. Additionally, effective business analysts often use qualitative measures to

estimate the value delivered by a solution with stakeholders.

Several techniques are available for defining, measuring, and collecting solution

performance measures. You should consider adding acceptance and evaluation

criteria to your list of possibilities. Let’s take a look at this recommended

technique in greater detail right now.

Recommended Technique: Acceptance and Evaluation Criteria

We think that defining and applying acceptance and evaluation criteria is a

required technique in the fundamental knowledge base of an effective business

analyst. Both acceptance and evaluation criteria can be tied to contractual

obligations, which can introduce associated legal and political issues and risks

into the project.

Acceptance criteria define a minimal set of requirements that must be met in

order for a solution or a solution component to be considered acceptable to its

key stakeholders. These criteria should be defined early in the project life cycle

and must be met in order to say that a solution is complete, correct, and worth

implementing. Test cases can and should be written that verify the solution

against these defined and agreed-upon acceptance criteria.

Evaluation criteria are a set of requirements used to choose between multiple

solutions to a particular problem. They are typically built to allow scoring of the

various solutions under consideration. To evaluate potential solutions, this set

357

of requirements is prioritized and ranked by order of importance. The solutions

will then be scored against the ranked set of requirements using a

preestablished evaluation scale. A must-have requirement that is not met by a

proposed solution should remove that solution from consideration.

Additional Techniques to Consider

The BABOK

Guide recommends several additional techniques when you are

assessing one or more proposed solutions for your project. These techniques are

summarized for you here.

Benchmarking and Market Analysis Benchmarking can be used to define

acceptable measures for a solution relative to the potential value defined in the

future state description and the change strategy.

Business Cases Business objectives are defined in the business case for the

project. Performance measures for the resulting solution can also be found here.

Data Mining This technique is used to collect and analyze the solution

performance data. Data mining is particularly useful when there is a lot of data

to analyze relative to a particular solution.

Decision Analysis Decision analysis allows you to examine and model the

consequences of different decisions before actually making or recommending a

particular decision. Effective decision analysis requires you to effectively

structure the decision problem and process, keeping in mind any relevant

values, goals, and objectives.

Focus Groups Focus groups are often used to give assessment, insight, and

impressions of a solution’s performance. The results of using this technique are

subjective in nature.

Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are

defined and used to measure solution performance. These measures are aligned

with enterprise measures, goals, and objectives.

Nonfunctional Requirements Analysis Nonfunctional requirements

define the expected characteristics of a solution. Be sure to use this technique

and its results when defining solution performance measures.

Observation Observation is used to provide feedback on stakeholder or user

perception of a solution or to reconcile contradictory results. Sometimes it

makes things clear when you watch them personally and see what is going on.

Prototyping Prototyping is commonly used to simulate a new solution prior to

constructing that solution. Performance measures can be defined, collected, and

analyzed using the prototype as a baseline.

Survey or Questionnaire Surveys and questionnaires are often used to

collect information from stakeholders about solution performance. They are

particularly useful when you are seeking input from a large number of

stakeholders.

Use Cases and Scenarios Use cases and scenarios define the expected

outcomes of a solution or a solution component. Performance measures can be

358

defined, collected, and analyzed using the use case or scenario as a baseline.

Vendor Assessment Vendor assessments allow you to assess an external

vendor’s ability to provide all or part of your solution. As part of the assessment,

be sure to look at their performance measures for the solution.

Once you have selected and applied one or more of these techniques as part of

your solution measurement efforts, you are ready to continue with the other

Solution Evaluation tasks at hand. We will discuss those tasks shortly.

Measuring the Proposed Solution

Measuring a solution or solution components requires you define the

performance measures that will be collected and analyzed. The solution

performance measures look at the solution performance relative to the value

that the solution brings to the enterprise. Table 7.3 summarizes this destination

for the results of your solution measurement efforts.

TABLE 7.3 Output: Measure solution performance.

Output Output Destinations Destination

Knowledge Area

Solution performance

measures

Analyze current state. Strategy Analysis

Analyze performance

measures.

Solution Evaluation

Several key business analysis stakeholders might be involved in the solution

measurement. The project manager will need to plan and manage this solution

assessment process as part of the project. Other stakeholders participating in

solution assessment include the following:

Customer

Domain SME

End user

Sponsor

Regulator

Now let’s take a look at the next task found in the Solution Evaluation

knowledge area—analyzing the solution performance measures that were

defined and collected.

Analyze Performance Measures

Analyzing performance measures typically begins once your constructed

solution is deployed and in operational use. Business analysts need to

understand the potential value of the solution and the enterprise context where

that solution is being implemented. You will find yourself looking at goals,

objectives, KPIs, risks, and other factors as part of this analysis work.

359

You may find yourself investigating how the solution is being used and assessing

the positive and negative impacts it has on the organization and its

stakeholders. Some folks analyze performance measures in a post-

implementation assessment performed shortly after their project is complete.

Do We Have the Right Acceptance Criteria?

In a recent consulting assignment, Ginger discovered firsthand that solution

performance evaluations can yield some surprising results. She was

performing a post-implementation review of a large software system’s

implementation at a major telecommunications company.

The new system automated the trouble-ticketing and problem-resolution

capabilities between the telecommunications company and its business

partners. Whenever a circuit problem was reported, the system would

initiate and carry on an electronic conversation between the two companies.

The conversation stepped through the problem-resolution process from

start to finish with the computer systems on each end performing the lion’s

share of the work.

Rather than talk with one another and do a lot of manual data entry and

status updates, the service representatives were able to simply check the

status of the trouble tickets and make sure the repairs that needed to be

done were actually scheduled and completed. The new system was viewed

by senior management as a system that would greatly enhance workplace

productivity by minimizing the manual transactions and telephone

conversations that took up so much of the service representative’s time.

As part of her solution performance evaluation work, Ginger visited a major

service center to see how well the new system was being used. She expected

to see a very quiet and efficient workspace with a lot of activity going on

behind the computer screens. What Ginger expected and what she

encountered on her visit were two very different things.

Ginger walked around the service center to see the end users in action. As

predicted, once the trouble ticket was opened in the new system, the

computer took over the conversation with the company responsible for

addressing the problem. However, instead of allowing the electronic

conversation to go on unaided, the service reps were on the phones with the

counterparts at the other company. As the computer systems exchanged

information and updated problem status, they were discussing what they

saw on the screens and making sure that all was going as planned. This

behavior on the part of the end users was most unexpected.

The project team and the business had failed to take into account how much

enjoyment the service representatives took from their interactions and

relationships with the folks at the other companies. They wanted to

360

continue those activities and found an easy workaround allowing them to do

just that—all they had to do was pick up the phone and dial.

As Ginger briefed the senior management team on the results of the post-

implementation assessment, she made the point that your solution’s end

users can be quite creative when it comes to figuring out new and

unintended ways to use the capabilities that a solution provides. Ginger told

the senior managers that the project had obviously missed defining the

acceptance criteria focusing on job satisfaction and relationship building

between the involved companies and personnel. These automated systems

are working quite well to this day—and the people-to-people conversations

are still going on right along with the electronic ones.

Figure 7.2 summarizes the inputs, outputs, techniques, and associated tasks

used to validate a solution against its business requirements.

FIGURE 7.2 Task summary: Analyze performance measures.

Several key inputs, guidelines, and tools are needed to analyze how an

operational solution is performing. These key inputs are produced by a number

of other business analysis tasks. They include the solution scope, any solution

performance measures, and the future state description. Let’s look at each input

in greater detail.

Potential Value Potential value describes the value that might be realized

from the operational solution. This estimate is often used as a benchmark when

analyzing the actual solution performance.

Solution Performance Measures Solution performance metrics define the

criteria that are used to measure and assess solution performance. They may be

quantitative or qualitative in nature. Examples of quantitative metrics include

361

numerical measures of time, revenue, or transaction volume. Qualitative metrics

are softer measures, such as customer satisfaction or recommendations.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Let’s take a look at the guidelines and tools that may also

be used as inputs when analyzing solution performance:

Change Strategy The change strategy is a high-level plan of key activities and

events relative to a proposed change. Be sure to reference this information when

analyzing solution performance using the defined performance measures.

Future State Description The future state description provides a definition

of the boundaries for the solution scope and all of the solution components. It

also links back to the potential value expected from this future state.

Risk Analysis Results The risk analysis results from Strategy Analysis

provide a look at both the overall level of solution risk and the more specific

individual risks inherent to the solution and its components.

Solution Scope Solution scope defines the solution boundaries for what is in

scope and what is out of scope. These boundaries are used to analyze solution

performance.

Table 7.4 summarizes the inputs to this task and lists the task and knowledge

area sources for each input used to analyze solution performance.

TABLE 7.4 Inputs: Analyze solution performance.

Task Input Input Type Input Source Source

Knowledge Area

Potential value Input Define future state. Strategy Analysis

Solution

performance

measures

Input Measure solution

performance.

Solution

Evaluation

Change strategy Guidelines

and tools

Define change

strategy.

Strategy Analysis

Future state

description

Guidelines

and tools

Define future state. Strategy Analysis

Risk analysis results Guidelines

and tools

Assess risks. Strategy Analysis

Solution scope Guidelines

and tools

Define change

strategy.

Strategy Analysis

Five elements are involved with analyzing solution performance. The solution

being evaluated needs to be live and in operation. If it isn’t being used, there

won’t be much for you to evaluate. The detailed elements of this task include

looking at the following:

Solution performance versus desired value

Risks

362

Trends

Accuracy

Performance variances

Let’s look at each of these five elements in greater detail:

Solution Performance vs. Desired Value To analyze performance

measures, you need to collect the metrics that describe solution performance.

Some software applications might provide these metrics to you automatically.

Other types of solutions will require manual collection of quantitative and

qualitative solution metrics for evaluation.

If you have a solution that is over- or under-performing and not meeting one or

more of the business goals and objectives, it may be that your solution metrics

associated with those goals and objectives are flawed. The solution metrics

should also be validated and defined more appropriately.

Risks A lack of performance measures for a solution is considered a solution

performance risk. Performance measures may uncover new risks to the solution

or the enterprise. The new risks are identified and managed just like any other

risk.

Trends Be sure to consider the time period over which performance

measurement data is being collected. A large time period and a good sample size

of data yields a more accurate view of a solution’s performance.

Accuracy Business analysts test and analyze solution performance data to

make sure the data is accurate and reliable. The results of accurate and reliable

performance measures can be reproduced and repeated.

Performance Variances Variance is the difference between the expected and

the actual solution performance. Business analysts watch the variance and

attempt to minimize or eliminate that variance to deliver solution value.

When analyzing performance measures, you can select from many

recommended techniques. You can use one or several of these techniques to

produce the solution performance analysis that is generated as an output by this

task.

Techniques to Consider

The BABOK

Guide recommends using one or more of the following techniques

when you are analyzing performance measures. They are summarized for you

here:

Acceptance and Evaluation Criteria These criteria define the acceptable

solution performance. The degree of variance in the collected data is used in

analyzing the solution performance.

Benchmarking and Market Analysis Benchmarking can be used to observe

the results of other organizations using similar solutions. This includes looking

at risks, trends, and variances relative to the solution being analyzed.

Data Mining This technique is used to collect and analyze the solution

363

performance data. The collected data typically includes performance measures,

trends, issues, and variances.

Interviews This technique is used with individuals or small groups. The

business analyst is speaking with them to determine the expected value of a

solution as well as how the solution’s performance is perceived.

Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are

defined and used to measure and analyze solution performance. The measures

are used to judge how well the solution contributes to achieving business goals.

Observation Observation allows you to observe the solution in action. This

technique may reveal problems or issues that have not been noticed or reported.

It may also reveal issues that are not obvious in the collected data.

Exam Spotlight

Make sure you know the difference between a defect and an issue. Defects

are deficiencies in your solution, reducing the quality of that solution. Issues

are points or matters in dispute or in question.

Risk Analysis and Management Risks are identified and managed on an

ongoing basis during solution performance analysis. Activities include risk

identification, analysis, response planning, and management.

Root-Cause Analysis Root-cause analysis is used to determine the underlying

cause of a significant performance variance within a solution.

Survey or Questionnaire Surveys and questionnaires provide you with a

vehicle to gather quantitative and qualitative information from large numbers of

stakeholders about how they perceive a solution performs.

Once you have selected and applied one or more of these techniques as part of

your analyze performance measures efforts, you are ready to produce the key

business analysis output from this task—the solution performance analysis.

Let’s review this deliverable.

Build the Solution Performance Analysis

The solution performance analysis describes how the solution is performing

relative to the business goals and objectives that led to its creation and

implementation. It contains the results of analyzing the solution performance

measurements that were collected. The deliverable also contains the business

analyst’s recommendations relative to the results of the measurements. The

focus is on recommendations to solve any performance gaps as well as

leveraging opportunities to create more value.

The contents of analysis may be used to assess both solution and enterprise

limitations as part of the tasks found in the Solution Evaluation knowledge area.

Table 7.5 summarizes this output and the tasks that use it.

364

TABLE 7.5 Output: Analyze Performance Measures.

Output Output Destinations Destination Knowledge

Area

Solution performance

analysis

Assess solution

limitations.

Solution Evaluation

Assess enterprise

limitations.

Solution Evaluation

The business analyst is responsible for ensuring that the solution analysis work

on the project gets done. If they are unable to follow through because of

reassignment to another project, you will need to plan for the work and hand off

the plan to another responsible party. There are a number of other business

analysis stakeholders who may be involved with this post-implementation

analysis, including the following:

Domain SME

Project manager

Sponsor

The project sponsor is ultimately responsible for solution operations from a

business point of view and needs to review the results of your solution

performance analysis to see whether any improvements or changes to the

solution need to be made.

Now let’s take a look at the next task found in the Solution Evaluation

knowledge area—assessing solution limitations that restrict the full realization

of value.

Assess Solution Limitations

Your next task in the Solution Evaluation knowledge area is assessing solution

limitations. This task identifies the root causes of underperforming and

ineffective solutions and solution components. This task is closely linked to

another task in the Solution Evaluation knowledge area—assessing the

enterprise limitations. We will discuss this task later in the chapter. The tasks

are often done concurrently at any point during the solution life cycle.

Solution Components

Let’s make sure you remember the definition of solution components. They

are the pieces and parts of a solution that span the enterprise architecture of

the organization including things like the following:

Business processes, policies, and rules

People along with their job functions and responsibilities

365

Software applications and application components

Organizational structure and its internal/external interactions

This task is often done concurrently with assessing enterprise limitations at any

point during the solution life cycle. Figure 7.3 summarizes the inputs,

guidelines, tools, outputs, techniques, and associated tasks used to assess

solution limitations.

FIGURE 7.3 Task summary: Assess solution limitations.

Two key inputs are needed to assess solution limitations. These inputs are

produced by a number of other business analysis tasks. They include the

implemented solution and the solution performance analysis. Let’s look at each

of these task inputs in greater detail.

Implemented Solution (External) Implemented solutions are those that

exist and can be evaluated. They may or may not be in operational use, such as a

prototype solution.

Solution Performance Analysis The solution performance analysis contains

the results of collected and analyzed solution performance measurements. It

also contains recommendations to solve any performance gaps or take

advantage of any opportunities that could improve the solution’s value.

There are additional inputs that may be used by business analysis tasks:

guidelines and tools. Let’s take a look at the guidelines and tools that may also

be used as inputs when assessing solution limitations.

Change Strategy The change strategy is a high-level plan of key activities and

events relative to a proposed change. Be sure to reference this information when

creating the performance measures for your solution.

366

Risk Analysis Results The risk analysis results document the overall level of

risk and individual risks for the solution and solution components.

Solution Scope Solution scope defines the solution boundaries for what is in

scope and what is out of scope. These boundaries are used to measure and

evaluate a solution.

Table 7.6 summarizes the inputs, guidelines, and tools for this task and lists the

task and knowledge area sources for each input used to assess proposed

solutions.

TABLE 7.6 Inputs, Guidelines, and Tools: Assess solution limitations.

Task Input Input

Type

Input Source Source

Knowledge

Area

Implemented solution (external)

requirements (prioritized and

approved)

Input

Solution performance analysis Input Analyze

performance

measures.

Solution

Evaluation

Change strategy Guidelines

and tools

Define change

strategy.

Strategy

Analysis

Risk analysis results Guidelines

and tools

Assess risks. Strategy

Analysis

Solution scope Guidelines

and tools

Define change

strategy.

Strategy

Analysis

The elements to be considered when assessing solution limitations are as

follows:

Identifying internal solution component dependencies

Investigating solution problems

Performing an impact assessment

Let’s look at each of these elements in greater detail.

Identifying Internal Solution Component Dependencies Solution

performance can be limited by internal dependencies. It is important to identify

internal solution dependencies between components and see if there is anything

about the components that limits performance or value realization. The

performance of an entire solution can be impacted by and limited to the

performance of the least effective solution component.

Investigating Solution Problems Business analysts often use problem

analysis techniques to investigate solution performance problems. It is essential

to identify the source of the problem so the problem can be addressed and

corrected. Problems may be indicated by an inability to meet a goal or objective

or by a failure to realize a benefit. Solution outputs may not be of sufficient

367

quality, or potential value may not be realized.

Performing an Impact Assessment Performing an impact assessment on

one or more identified solution problems determines the severity of the

problem, the probability of the problem occurring again, the impact on the

business operations, and the capacity of the business to absorb that impact.

Problems can be resolved, mitigated, or accepted. Risks are also assessed as part

of an impact analysis.

Techniques to Consider

The BABOK

Guide recommends the use of one or more techniques when you

are assessing solution limitations. These techniques are summarized for you

here:

Acceptance and Evaluation Criteria These criteria define the acceptable

solution performance. The degree of variance in the collected data is used in

analyzing the solution performance and assessing solution limitations.

Benchmarking and Market Analysis Benchmarking can be used to observe

the results of other organizations using similar solutions. This includes looking

at risks, trends, and variances relative to the solution being analyzed.

Business Rules Analysis This technique shows the current business rules

and the changes to those rules that are required to achieve the potential value of

the change. Business rules may limit or constrain solution performance or

impact value realization.

Data Mining This technique is used to identify factors that may constrain or

limit solution performance. The collected data being analyzed and reviewed

typically includes performance measures, trends, issues, and variances.

Decision Analysis Decision analysis allows you to examine and model the

costs and benefits of different requirements allocation schemes before making

or recommending a particular decision.

Interviews This technique is used with individuals or small groups. The

business analyst is speaking with them to determine the problems or limitations

of a solution as well as how the solution’s performance is perceived.

Item Tracking This technique is used to record and manage stakeholder

issues related to solution limitations that are impacting value realization.

Lessons Learned Lessons learned could be used to look back and discover

what happened along the way to limit the solution and its ability to deliver

value.

Risk Analysis and Management Risks are identified and managed on an

ongoing basis during solution performance analysis. Activities include risk

identification, analysis, response planning, and management.

Root Cause Analysis Root cause analysis is used to determine the underlying

cause of a significant performance variance within a solution.

Survey or Questionnaire Surveys and questionnaires provide you with a

368

vehicle to gather quantitative and qualitative information from large numbers of

stakeholders during your problem analysis efforts.

Once you have selected and applied one or more of these techniques as part of

your solution limitation assessment efforts, you are ready to continue with the

other Solution Evaluation tasks. First, let’s look at the key output from this task,

the solution limitation.

Assess Solution Limitations

The solution limitation describes the current limitation of a solution or solution

component, such as constraints and defects. Table 7.7 summarizes these

destinations for the results of your solution limitation assessment efforts.

TABLE 7.7 Output: Assess solution limitations.

Output Output Destinations Destination

Knowledge Area

Solution

limitation

Analyze current state. Strategy Analysis

Recommend actions to increase

solution value.

Solution Evaluation

A number of stakeholders are involved with assessing solution limitations on

your project. You should always involve the end users with this work; they

contribute to the actual value realized by the solution they are using and can

provide feedback on the solution.

A number of additional business analysis stakeholders may be affected by your

solution limitation work, including the following:

Customer

Domain SME

Regulator

Sponsor

Tester

Let’s move on and take a detailed look at the next task found in the Solution

Evaluation knowledge area—assessing the enterprise limitations for a solution.

Assess Enterprise Limitations

Another interesting task in the Solution Evaluation knowledge area is assessing

the enterprise limitations of a solution. As a business analyst, you are an agent

of change; you shepherd new solutions from conception to completion. The trick

is proving that the operational solution delivers its potential value to the

enterprise. Assessing enterprise limitations identifies the root causes of specific

factors and describes how those factors can limit a solution’s value realization

potential.

369

Exam Spotlight

Be sure you recognize what an enterprise limitation for a solution or

solution component might be on your exam. Enterprise limitations include

the following factors:

Culture

Operations

Technical components

Stakeholder interests

Reporting structures

Many factors external to a solution may impact its ability to deliver business

value. Frequently, solutions operate across organizational boundaries within the

enterprise with many interactions and interdependencies. Solutions may

depend upon external factors, such as outsourcing your solution’s servers to a

third-party vendor.

Enterprise limitations can be assessed at any time during the solution life cycle,

from component development to full solution implementation. Existing,

operational solutions can also be assessed if the need arises.

Figure 7.4 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used to assess enterprise limitations relative to a solution.

FIGURE 7.4 Task summary: Assess enterprise limitations.

370

Several key inputs are needed to assess the enterprise limitations of a solution.

These key inputs are produced by a number of other business analysis tasks, and

they include the implemented solution (also known as the constructed solution),

the current state description, and the solution performance analysis results.

Let’s look at each of these task inputs in greater detail.

Implemented or Constructed Solution (External) The implemented or

constructed solution must actually exist. It may be in operational use or a

prototype. In either case, the solution must be in use so its performance can be

measured and analyzed.

Current State Description The current state description describes the

environmental, cultural, and internal factors of the solution being measured and

analyzed.

Solution Performance Analysis This deliverable describes how the solution

performs relative to the business goals and objectives that led to its creation and

implementation. It contains the results of analyzing the solution performance

measurements that were collected and the business analyst’s recommendations

relative to the results of the measurements.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Let’s take a look at the guidelines and tools that may also

be used as inputs when assessing solution limitations:

Business Objectives Business objectives are measurable results indicating a

business goal has been met. Be sure to consider these objectives when

measuring solution performance.

Change Strategy The change strategy is a high-level plan of key activities and

events relative to a proposed change. Be sure to reference this information when

implementing a solution and when creating performance measures for that

solution.

Future State Description The future state description provides a definition

of the boundaries for the solution scope and all of the solution components. It

also links back to the potential value expected from the future state.

Risk Analysis Results Risk analysis results contain the overall level of risk for

the solution as well as the individual risks for the solution components.

Solution Scope Solution scope defines the solution boundaries for what is in

scope and what is out of scope. These solution boundaries are used to define

what needs to be measured and evaluated.

Table 7.8 summarizes the inputs, guidelines, and tools for this task and lists the

task and knowledge area sources for each input used to assess enterprise

limitations.

TABLE 7.8 Inputs, Guidelines, and Tools: Assess enterprise limitations.

Task Input Input

Type

Input Source Source

Knowledge

Area

371

Implemented or

constructed solution

(external)

Input

Current state description Input Analyze current

state.

Strategy

Analysis

Solution performance

analysis

Input Analyze

performance

measures.

Solution

Evaluation

Business objectives Guidelines

and tools

Define future

state.

Strategy

Analysis

Change strategy Guidelines

and tools

Define change

strategy.

Strategy

Analysis

Future state description Guidelines

and tools

Define future

state.

Strategy

Analysis

Risk analysis results Guidelines

and tools

Assess risks. Strategy

Analysis

Solution scope Guidelines

and tools

Define change

strategy.

Strategy

Analysis

Four key elements are found in a thorough enterprise limitations assessment.

Together they make up the bulk of your assessment findings. They are as

follows:

Enterprise culture assessment

Stakeholder impact analysis

Organizational structure changes

Operational assessment

Let’s look at each of these four elements in greater detail:

Enterprise Culture Assessment The cultural part of your assessment

focuses on the willingness of your key stakeholders to change and accept the

solution. You need to put your marketing hat on and sell this solution as part of

your business analysis activities. This involves understanding each key

stakeholder’s willingness to change and getting them on board with the changes

that are coming with the new solution. Your stakeholders need to understand

and buy into the rationale for the new solution and the benefits it provides.

Stakeholder Impact Analysis Your assessment must address how the

changes from your new solution will affect your stakeholders. There are a

number of things to consider.

Functions Your impact analysis should look at the solution capabilities that

each stakeholder group uses and address the significant work changes. Consider

new or modified processes, as well as specific applications that the stakeholders

will now be using as part of their jobs.

Locations Stakeholder location also comes into play when assessing the

372

impacts of change. If your stakeholders are all located in one place, it will be

easier to train and support their use of the new solution. If your stakeholders are

found in multiple locations, you will have to address how they learn to use the

new solution and get assistance when they have questions in a virtual

environment.

Concerns Stakeholder concerns and issues should also be addressed in your

analysis. There are several areas to consider, such as solution usability, work

demands, potential job loss, or changes in work satisfaction.

Organizational Structure Changes Solutions can impact and change

organizational structure. Business analysts need to assess the organizational

structure supporting a solution to make sure that structure allows the solution

to perform effectively. In addition to the formal working relationships,

knowledge of the informal stakeholder relationships within the organization can

be very helpful to the business analyst in understanding the practical, day-to-

day working structure.

Operational Assessment This part of your assessment focuses on the

capabilities that the new solution will provide and how the stakeholders will use

those capabilities. You might need to create new policies and procedures

governing use of the solution. Training might be needed so folks know how to

use the solution correctly. Systems support and maintenance also need to be

planned and put in place prior to solution implementation.

Exam Spotlight

When conducting an operational assessment for a solution, business

analysts should consider the following six areas:

Policies and procedures

Capabilities and processes

Skill and training needs

Human resources practices

Risk tolerance and management approaches

Tools and technology required for supporting the solution

There are several techniques that you may use when assessing enterprise

limitations. Let’s step through those techniques now.

Techniques to Consider

The BABOK

Guide recommends using one or more of the following techniques

when you are assessing enterprise limitations. These techniques are

summarized for you here:

373

Benchmarking and Market Analysis Benchmarking can be used to identify

existing solutions and enterprise interactions for a new solution. This

identification is done relative to the potential value of that new solution defined

in the future state description and the change strategy.

Brainstorming This technique is used to generate many ideas from a

stakeholder group in a short period of time. The resulting ideas can then be

organized and prioritized to identify solution improvement opportunities and

stakeholder concerns.

Data Mining This technique is used to collect and analyze the solution

performance data. Data mining is particularly useful when you are identifying

factors that constrain the performance of the solution.

Decision Analysis Decision analysis allows you to examine and model the

consequences of different decisions before actually making or recommending a

particular decision. This technique helps you to make decisions about

functional, technical, or procedural gaps in the solution.

Document Analysis Reviewing existing documentation is a way for the

business analyst to understand the enterprise culture, operations, and structure.

Interviews Interviews provide a forum for identifying organizational gaps or

stakeholder concerns with the new solution and discussing possible solutions or

workarounds.

Item Tracking This technique is used to record and manage stakeholder

issues related to solution limitations that impact value realization.

Lessons Learned Lessons learned could be used to look back at previous

initiatives and discover what happened along the way to limit the solution and

its ability to deliver value to the enterprise.

Observation Observation is used to provide feedback on stakeholder or user

perception of a solution or to reconcile contradictory results. Sometimes it

makes enterprise and solution interactions clear when you witness them and see

what is going on.

Organizational Modelling Organization models offer a view of your

stakeholder groups and stakeholders to use while assessing organizational

readiness and the need for organizational changes.

Process Analysis Process analysis assesses a process for efficiency and

effectiveness. This technique is used to identify opportunities to improve

solution performance.

Process Modelling Process models identify activities that will change when

the new solution is implemented and tell you which stakeholders perform these

activities. This allows you to focus on who is impacted by the change.

Risk Analysis and Management This technique is used to consider the risks

of a new solution relative to the enterprise across several areas: technology,

finance, and business. It is essential that the required functionality and ability of

the organization to change be considered and addressed.

Roles and Permissions Matrix The roles and permissions matrix helps the

374

business analyst determine roles and permissions for stakeholders and end

users of a new solution.

Root-Cause Analysis Root-cause analysis is used to determine the underlying

cause of a significant performance variance within a solution. Sometimes this

underlying cause is related to enterprise limitations.

Survey or Questionnaire Surveys and questionnaires are techniques that

give you a forum for identifying organizational gaps or stakeholder concerns

with the new solution.

SWOT Analysis The strengths, weaknesses, opportunities, and threats

(SWOT) analysis technique demonstrates how a change will help the

organization by categorizing the strengths, weaknesses, opportunities, and

threats associated with the new solution.

Workshops Workshops, or review meetings, are used to identify

organizational gaps or stakeholder concerns about a new solution in a

structured group setting.

Once you have selected and applied one or more of these techniques as part of

your enterprise limitations assessment efforts, you are ready to continue with

other assessment tasks. Before moving on, let’s look at the key output from this

task, the description of the enterprise limitations that were found.

Build the Enterprise Limitation Assessment

Your enterprise limitation assessment describes the current enterprise

limitations of a solution. Be sure to look at how solution performance impacts

the enterprise. You always need to keep in mind that a solution isn’t a success if

people are unable to use it effectively.

Table 7.9 summarizes the enterprise limitation assessment and the task that

uses this output.

TABLE 7.9 Output: Assess enterprise limitations.

Output Output Destinations Destination

Knowledge Area

Enterprise

limitation

Analyze current state. Strategy Analysis

Recommend actions to increase

solution value.

Solution Evaluation

A number of stakeholders will be involved with assessing enterprise limitations

for a new solution. Domain SMEs and end users should be part of this effort

since they are close to the solution and can identify how the organization

interacts with it. Several other business analysis stakeholders might be involved

with the enterprise limitation assessment, such as the following:

Customer

Regulator

375

Sponsor

Let’s move on and step through the final task found in the Solution Evaluation

knowledge area—recommending actions to create solution value.

Recommend Actions to Increase Solution Value

Estimating the potential value of a solution can be quite different from realizing

the actual value once that solution is operational. One key task performed by

business analysts is trying to align the potential value and the actual value of a

solution as much as possible. The previous four tasks in the Solution Evaluation

knowledge area collect solution performance data, measure the solution

performance, and assess solution and enterprise limitations that may impact the

actual value. This task uses the results from the other tasks to understand the

big picture of a solution’s value and recommend ways to improve solution

performance and value realization.

The New Solution Strikes Back

Russ, a project manager, held a meeting at a biotechnology company to

discuss kick-off plans for a new project targeting the upgrade of their

existing Laboratory Information Management System (LIMS). This

company is a leading human therapeutics company in the biotechnology

industry, focused on providing drugs that support cancer treatments.

The current LIMS system was homegrown and had evolved over many years

to reach its current state. Although the system supported the integration of

the laboratory software, hardware, and instruments, the product quality

team felt that a newer system and solution could do a much better job of

tracking laboratory-related work, planning samples, and automating

workflow.

As part of his introduction to the organization, the plant manager took Russ

on a tour of the production facility. Russ was very impressed with the plant

and its operations. At one point on his tour, Russ stopped in front of a very

large processing vat placed beneath a very large skylight.

“What an interesting piece of equipment.” Russ commented. “What is it

used for?”

Dan, the plant manager, replied that this particular piece of equipment was

used to distill the drug as part of its production.

Russ looked up at the skylight and asked, “Does the process require this

much natural light?”

Dan smiled and shook his head. “Oh, no,” he replied. “This is my daily

reminder of what happens when you don’t spend enough time planning for

376

implementation.”

Dan went on to explain to Russ that this particular piece of equipment was

ordered from Germany and shipped to the plant location in the United

States. When it arrived at the new plant building, the installation team was

stunned to discover that the vat did not fit in the doors.

To get this critical piece of equipment into the new building, Dan had to

authorize cutting a skylight in the roof and using a crane to drop the vat into

place. As Dan told Russ, the transition requirements that assist you in

implementing your project are quite critical. They are even more critical

when you discover after the fact that you missed something. Missing

something during your solution development implementation can equal

more costs, which equals less value realization from that solution.

Solution-focused recommendations look at how solutions should be replaced,

retired, or enhanced. These recommendations have a long-term perspective

over the life of the solution within the enterprise. The solution or the

organization may require adjustment in order to use the solution more

effectively and realize additional value from its use.

Figure 7.5 summarizes the inputs, guidelines, tools, outputs, techniques, and

associated tasks used to assess the readiness of your organization to adopt and

use a new solution.

FIGURE 7.5 Task summary: Recommend actions to increase solution value.

Several key inputs are needed to define transition requirements. These key

inputs are produced by a number of other business analysis tasks. Let’s take a

look at each of these task inputs in greater detail:

Enterprise Limitation Enterprise limitations look at how solution

377

performance impacts the enterprise relative to any limitations that enterprise

might have.

Solution Limitation Solution limitations focus on the limits, constraints, and

defects of the solution itself and how those limitations might impact value

realization.

There are additional inputs that can be used by business analysis tasks:

guidelines and tools. Let’s take a look at the guidelines and tools that may also

be used as inputs when recommending actions to increase solution value:

Business Objectives Business objectives are measurable results indicating a

business goal has been met. Be sure to consider these objectives when

evaluating, measuring, and determining solution performance.

Current State Description The current state description provides the

context of the existing enterprise where the work needs to be done. It can be

used to assess alternatives and understand ways to increase solution value.

Solution Scope Solution scope defines the solution boundaries for what is in

scope and what is out of scope. These solution boundaries are used to define

what needs to be measured and evaluated.

Table 7.10 summarizes the inputs to this task and lists the task and knowledge

area sources for each input used when recommending actions to increase

solution value.

TABLE 7.10 Inputs, Guidelines, and Tools: Recommend actions to increase

solution value.

Task Input Input Type Input Source Source

Knowledge Area

Enterprise

limitation

Input Assess enterprise

limitations.

Solution Evaluation

Solution

limitation

Input Assess solution

limitations.

Solution Evaluation

Business

objectives

Guidelines and

tools

Define future state. Strategy Analysis

Current state

description

Guidelines and

tools

Analyze current state. Strategy Analysis

Solution scope Guidelines and

tools

Define change

strategy.

Strategy Analysis

Two key elements must be considered when you are building these

recommendations for your project. Let’s look at each of these elements in

greater detail:

Adjust solution performance measures. Sometimes a new solution does

not quite fulfill the business goals and objectives that triggered the project in the

first place. Issues, defects, problems, or discrepancies need to be recorded,

prioritized, and resolved. Another option is to change the solution performance

378

measures based upon what is taking place. For a particular solution, more

appropriate and achievable measures may be required.

Recommendations Recommendations describe ways to increase solution

performance. There are several common recommendations that might be made

based upon the situation. Table 7.11 summarizes these recommendations.

TABLE 7.11 Common solution recommendations

Recommendation Description

Do nothing. Remain in the current state when the value of a change is

low and the cost/risks of making the change are high.

Organizational

change

Make changes to organizational structure or personnel,

such as automating work, simplifying work, or improving

access to information.

Reduce interface

complexity.

Make it easier to share and understand work or data

between systems or people.

Eliminate

redundancy.

Meet the common needs of different stakeholder groups

with a single solution to reduce implementation costs.

Avoid waste. Remove activities that do not add value and minimize

activities that do not directly contribute to the final

product.

Identify additional

capabilities.

Be aware of capabilities in the solution that exceed

requirements and make sure they will provide future

value.

Retire the solution. Replace a solution or component because of old

technology, insourcing, outsourcing, or a solution not

fulfilling its goals.

Additional factors may impact a decision to replace, retire, or revamp a solution.

Be sure to look at the ongoing costs of operating the solution versus the initial

investment that was made to create the solution. Remember that opportunity

costs also come into play. Opportunity cost is the potential value that could be

realized from pursuing other solutions versus the solution you have on hand.

Necessity also plays a role here. Many solutions and their components have a

limited life span and must be replaced at a certain point in time. Don’t forget the

sunk costs, which are the money and effort already committed to a solution.

Many folks hold on to a bad solution versus replacing, eliminating, or

redirecting the solution because of the sunk costs that cannot be recovered.

You can select from a number of business analysis techniques when

recommending actions to increase solution value. Let’s take a look at them now.

Techniques to Consider

The BABOK

Guide recommends using one or more of the following techniques

when you are recommending actions to increase the value of a new solution.

379

They are summarized here:

Data Mining This technique is used to generate predictive estimates of

solution performance. Data mining is particularly useful when there is a lot of

data to analyze relative to a particular solution.

Decision Analysis Decision analysis allows you to examine and model the

consequences of different decisions before actually making or recommending a

particular decision. Effective decision analysis helps you determine the impact

of acting upon solution issues.

Financial Analysis There are numerous financial analysis techniques

available to assess the potential costs and benefits of a proposed change.

Focus Groups Focus groups are often used to give assessment, insight, and

impressions of a solution’s performance and the associated performance

measures.

Organizational Modelling Organization models offer a view of your

stakeholder groups and stakeholders to use while assessing organizational

readiness and the need for organizational changes.

Prioritization Many business analysts use prioritization techniques to identify

the relative value of different actions that might be taken to improve solution

performance.

Process Analysis Process analysis assesses a process for efficiency and

effectiveness. This technique is used to identify opportunities to improve

solution performance.

Risk Analysis and Management This technique is used to evaluate different

solution outcomes and their associated risks under specific conditions.

Survey or Questionnaire Surveys and questionnaires are often used to

collect information from stakeholders about solution performance. They can

help you get feedback on value realization based upon the performance

measures and analysis that has been done.

Once you have selected and applied one or more of these techniques as part of

your efforts, you are ready to continue with the work at hand. Before moving on,

let’s look at the key output from this task—your recommended actions.

Develop the Recommended Actions

The recommended actions provide a summary of what should be done to

improve the value of a solution within the enterprise. This output is picked up

by the Manage Stakeholder Collaboration task in the Elicitation and

Collaboration knowledge area. Stakeholders participate in the recommendation

review and the decision making regarding what is to be done, if anything.

Remember that the more significant the impact of a change, the more attention

is directed to managing stakeholder collaboration as part of the business

analysis activities.

Table 7.12 summarizes the task output and the task that uses it.

380

TABLE 7.12 Output: Recommend actions to increase solution value.

Output Output Destinations Destination Knowledge

Area

Recommended

actions

Manage stakeholder

collaboration.

Elicitation and

Collaboration

The business analyst is responsible for recommending ways to increase solution

value and opportunities on your project. A number of stakeholders are ready

and able to assist you in defining these value-focused recommendations for a

new solution. Several other business analysis stakeholders may be involved with

your efforts, including the following:

Customer

Domain SME

End user

Regulator

Sponsor

381

How This Applies to Your Projects

In this chapter, you stepped through tasks focusing on the solution that is being

built and deployed by your project. These tasks ensure that the solution can be

successfully implemented within the organization and add value once it is

operational. In many organizations, the business analyst is responsible for

supporting the business stakeholders as the solution is implemented and

facilitating their transition to the new ways of doing things. Part of your

responsibility is planning for the actual set of implementation activities down to

the right level of detail.

Your solution implementation plan and approved solution design enable you to

create data conversion requirements and build any necessary business

transition strategies. It is helpful to produce an implementation plan, a data

conversion plan, and any high-level requirements for the next solution release

as part of your preparations for transitioning from the old solution to the new

solution. A conversion plan maps data from the old solution to the new solution.

It details the business rules for data conversion and sets the timing of the work.

You might have a small set of transition requirements addressing your

implementation plan as part of your transition requirements. For example, they

may state the following:

TR 1.0 Develop an implementation plan for the constructed solution.

TR 2.0 Plan work activities to support the contents of the implementation

plan.

However, the actual implementation plan may be far more detailed based on the

solution that is being implemented. Table 7.13 provides you with a sample

implementation plan for a software solution implementation.

TABLE 7.13 Sample implementation plan

Date/Time

(All times

MST)

Task Description

Pre-Rollout Steps

7/10/10

12:00 AM

Send release notes to sys admin to post. Send support

documentation to sys admin.

7/10/10

12:00 AM

Update website with upcoming maintenance message via GUI

interface.

7/10/10

12:00 AM

Confirm production environment is ready for release rollout.

7/12/10

12:00 AM

Set up all new policy templates.

7/12/10

12:00 AM

Set up Oracle templates (release data).

382

7/12/10

12:00 AM

Set up Oracle templates (asset data).

7/15/10

10:30 AM

Shut down Oracle database.

7/15/10

10:45 AM

Drop the replication for groups that have changed.

7/15/10

11:30 AM

Run the table, stored procedure, and data changes.

7/15/10

11:30 AM

Run the database update scripts.

7/15/10

12:00 Noon

Verify the scripts ran successfully.

7/15/10

12:00 Noon

Set the billing start time to 00:05.

7/15/10

12:30 PM

Rebuild the changed replication groups.

7/15/10

2:00 PM

Restart Oracle.

7/15/10

2:00 PM

Join conference bridge for checkpoint.

7/15/10

2:00 PM

Publish build kit to lab to test rollout procedure.

7/15/10

4:00 PM

Copy latest/final build out to all production servers in two data

centers.

Rollout Steps

7/16/10

12:00

Midnight

Verify that all participants have joined the maintenance bridge

and that there are no network jeopardies that would cause this

maintenance to be rescheduled.

7/16/10

9:00 AM

Post maintenance message on websites.

7/16/10

12:01 AM

Verify that billing has completed.

7/16/10

12:02 AM

Reset billing to its original start time.

7/16/10

12:03 AM

Stop services and web servers.

7/16/10

12:05 AM

Export a copy of the application in case you have to roll back.

7/16/10

12:30 AM

Shut down Oracle database (15 minutes).

7/16/10 Drop the replication for groups that have changed (45 minutes).

383

12:45 AM

7/16/10

1:30 AM

Run the table, stored procedure, and data changes (1 hour).

7/16/10

1:30 AM

Run the database update scripts.

7/16/10

2:00 AM

Verify the scripts ran successfully (5 minutes, overlapping).

7/16/10

2:00 AM

Rebuild the changed Replication Groups (90 minutes).

7/16/10

3:30 AM

Restart Oracle (5 minutes).

7/16/10

6:00 AM

Copy the configuration file in the SFTPFileFetcher directory to

temp to preserve the data.

7/16/10

6:00 AM

Publish application code to data center production servers.

7/16/10

6:30 AM

Copy the config file from the temp directory and verify.

7/16/10

6:30 AM

Move SetDBDefaults.exe to c:\netfiles\bin to run it to avoid

errors.

7/16/10

6:30 AM

Run the script for the web service:

DeploymentUtil\UtilityScripts\ Rollout 6.0\Run.bat.

7/16/10

6:30 AM

Ensure all services are running in production.

7/16/10

6:30 AM

Join the conference bridge for checkpoint.

7/16/10

6:30 AM

Verify the correct application operation over a period of time.

(unit testing).

7/16/10

7:00 AM

Join the conference bridge for checkpoint and quality control

handoff.

7/16/10

8:00 AM

Quality assurance testing period begins.

7/16/10

8:00 AM

1 End-to-end Test of Policy Propagation (Client–Manual/Auto).

Note: Expect testing to take 10 to 12 hours.

7/16/10

12:00 Noon

Join the conference bridge for checkpoint.

7/16/10

4:00 PM

Join the conference bridge for checkpoint.

7/17/10

9:00 AM

Verify the billing is back up-and-running.

7/17/10

9:00 AM

Copy updated software download files to each of the web servers

in preparation for the Saturday deployment.

384

7/17/10

12:00 AM

Set up URL links in export server.

7/17/10

9:00 AM

Copy updated software download files to each of the web servers.

7/17/10

6:30 PM

Correct an issue with the policy feed.

7/18/10

11:00 PM

Request a final security scan of all servers.

7/19/10

12:00 AM

External system production testing.

7/19/10

6:00 AM

Release complete; publish management and customer

notifications.

This particular solution implementation plan was built and performed for a

software upgrade at a client site in Colorado. As you can see, the two statements

—build the plan and schedule the work from that plan—exploded into a detailed

set of steps to support implementation of this software release.

385

Summary

The five tasks in the Solution Evaluation knowledge area guide you in effectively

assessing, selecting, and validating the solution that will be implemented in the

organization to meet the business goals and objectives. Effective problem-

solving skills are an underlying competency enabling you to do this solution-

focused work. You will be asked to analyze problems with the designed and

constructed solution and recommend ways to address any defects and issues

that you and your stakeholders find. Applying your structured problem-solving

skills results in implementing a solution that meets or exceeds its quality and

acceptance criteria.

The BABOK

Guide recommends applying a number of techniques as part of

your solution evaluation efforts. You don’t need to be an expert in every

technique, but most experienced business analysts are comfortable using a

representative subset of those techniques.

A number of key business analysis deliverables are produced by the tasks found

in this knowledge area. You will produce several assessments looking at the

solution, the organization’s readiness to adopt that solution, and the solution’s

performance once operational. These assessments are a key part of your role in

making sure the right solution is implemented in the right way for your

business.

386

Exam Essentials

Be able to list the tasks found in the Solution Evaluation knowledge

area. You will see questions about the tasks, their associated techniques, their

more detailed elements, and the key outputs that they produce on your exam.

You should memorize the tasks of this knowledge area and the key outputs

associated with them. The five tasks are:

Measure solution performance.

Analyze performance measures.

Assess solution limitations.

Assess enterprise limitations.

Recommend actions to increase solution value.

Be able to understand and apply the techniques found in this

knowledge area. Understanding and applying the techniques to assess and

validate your solution and its performance is a key focus for your Solution

Evaluation knowledge area exam questions. Be sure that you can name the

techniques recommended here and associate them with the tasks that use them.

Be able to describe and distinguish between assessing solution and

enterprise limitations. Make sure you can define and distinguish between

the solution and enterprise limitation assessments that are created and used by

the tasks in the Solution Evaluation knowledge area.

Be able to define the three recommended statistical sampling

techniques. The BABOK

Guide uses three statistical sampling concepts for

collecting solution performance measures. Make certain you understand what

they are and how they differ.

Volume or sample size

Frequency and timing

Currency

Be able to discuss the three aspects of stakeholder impact analysis

relative to a new solution. When assessing enterprise limitations, there are

three areas to be considered as part of the stakeholder assessment.

Functions

Locations

Concerns

Be able to distinguish between a solution, solution components, and

a release. A solution is a set of changes to an organization’s current state

enabling the organization to meet a business need, solve a problem, or take

advantage of an opportunity.

Solutions are made up of solution components, the parts of a solution that span

387

the enterprise architecture of the organization, such as new business processes,

new software applications, or new hardware. Each solution component

implements a subset of the solution requirements.

Solutions are typically implemented in releases. A release is the distribution of

all or part of a scheduled operational solution, such as a release consisting of

software application code, related documents, and support materials.

388

Key Terms

You have just finished stepping through the contents of the sixth and final

knowledge area from the BABOK

Guide: Solution Evaluation. The tasks in this

knowledge area focus on making sure that the defined solution can be

successfully implemented in the organization and used by its stakeholders.

To be an effective business analyst, you should understand how to apply the

techniques and tasks in this knowledge area. Additionally, you will need to know

the five tasks and their associated elements and techniques from this knowledge

area in order to be successful on the CBAP

or CCBA

™

exam. The tasks include

the following:

Measure solution performance.

Analyze performance measures.

Assess solution limitations.

Assess enterprise limitations.

Recommend actions to increase solution value.

A number of new key words in Chapter 7 relate to assessing and validating your

new solution. Here is a list of some of the key terms that you encountered in this

chapter:

acceptance criteria

Beta release

constructed solution

currency

enterprise limitations

evaluation criteria

frequency and timing of measurements

implemented solution

necessity

operational assessment

operational life

operational releases

opportunity costs

pilot release

proofs of concept

prototypes

389

qualitative measures

quantitative measures

solution component

solution performance analysis

solution performance measures

sunk costs

transition requirements

variance

volume or sample size

390

Review Questions

391

1. Solution Evaluation tasks can be performed on solutions in different stages

of development. You want to evaluate a solution component that is part of a

limited implementation that is not fully released. What type of solution are

you working on?

A. Prototype

B. Operational

C. Pilot

D. Proof of concept

2. Which input best provides you with the measurable result that the enterprise

wants to achieve?

A. Business goal

B. Business objective

C. Business requirement

D. Business need

3. What technique ensures that issues arising from assessing enterprise

limitations are addressed and resolved?

A. Decision analysis

B. Item tracking

C. Metrics and KPIs

D. Root cause analysis

4. According to the BACCM™, a business analyst may recommend a change

either to a solution or to the ____________ to realize the potential value

of a solution.

A. Limitations

B. Requirements

C. Solution

D. Enterprise

5. You are determining the most appropriate response to identified problems in

a delivered solution. What task are you performing?

A. Measuring solution performance

B. Assessing solution limitations

C. Analyzing solution performance

D. Assessing the enterprise limitations

6. What is the best recommendation to make when the value of a change from a

current state is low relative to the effort required to make that change?

A. Retire solution.

392

B. Reduce complexity.

C. Do nothing.

D. Avoid waste.

7. To evaluate solution performance, the solution must exist in some form and

be ____________.

A. Verified

B. Approved

C. External

D. In Use

8. Which stakeholder approves the potential value of a solution?

A. Business analyst

B. Sponsor

C. Domain SME

D. Project manager

9. Requirements that are associated with the solution component that will

implement them are called:

A. Verified requirements

B. Solution requirements

C. Traced requirements

D. Allocated requirements

10. You are making decisions about replacing or retiring a solution. One factor

you consider includes the money and effort that has already been committed

to this current initiative. What factor are you considering?

A. Sunk cost

B. Necessity

C. Opportunity cost

D. Ongoing cost

11. What is another name for a solution that exists in some way?

A. Designed solution

B. Constructed solution

C. Implemented solution

D. Allocated solution

12. When should you begin to allocate requirements to the solution components

that will implement those requirements during a project?

A. When the real project requirements are derived

393

B. When the proposed solution is being assessed

C. When the solution approach is determined

D. When solution design and construction starts

13. When should transition requirements be defined?

A. While the solution is being designed

B. After the solution has been designed

C. Before the solution is actually designed

D. When required capabilities are defined

14. What technique would you select to discover whether a solution defect is a

symptom of a deeper, underlying problem?

A. Root-cause analysis

B. SWOT analysis

C. Force-field analysis

D. Decision analysis

15. You are investigating how a solution affects a particular stakeholder group

after that solution has been deployed. What Solution Evaluation task are you

performing?

A. Assessing enterprise limitations

B. Analyzing performance measures

C. Assessing solution limitations

D. Measuring solution performance

16. When assessing enterprise limitations using the risk analysis and

management technique, what three areas of risk should be considered?

A. Strategic, tactical, operational

B. Technology, finance, business

C. High, medium, and low impact

D. Capability, condition, constraint

17. What type of requirements should address employee training, conversion of

existing information, and user acceptance testing?

A. Stakeholder

B. Transition

C. Implementation

D. Functional

18. What technique might assist you in measuring solution performance?

A. Business cases

394

B. Decision analysis

C. Metrics and KPIs

D. Vendor assessment

19. Which task has solution performance measures as an input?

A. Measure solution performance.

B. Assess solution limitations.

C. Analyze performance measures.

D. Assess enterprise limitations.

20. What is the best reason for involving a business analyst in Solution

Evaluation tasks?

A. They bring technical skills to the solution assessment process.

B. They have built relationships with all key project stakeholders.

C. They are most knowledgeable about the business environment.

D. They work closest with the project manager and the project team.

395

Chapter 8

Underlying Competencies

396

CBAP

/CCBA

™

EXAM TOPICS COVERED IN THIS

CHAPTER:

Business analysis underlying competencies

Analytical thinking and problem-solving skills

Key business-analysis behavioral characteristics

Business knowledge, tools, and technology

Communication and interaction skills

Successful business analysts possess a wide spectrum of skills

and knowledge. Being a technical expert in a particular area or possessing

subject matter expertise in a particular industry does not guarantee success as a

business analyst on a project. Effective business analysts possess a core

framework consisting of business, technical, and domain knowledge. This core

framework is further enhanced by your management, interpersonal,

communication, business, and structured problem-solving skills.

The required knowledge and skills range from applying structured analysis

techniques to managing issues to addressing solution usability. You must be

able to provide relevant business and domain knowledge for the organization’s

products, processes, markets, and systems, and incorporate specific business

and software application skills. The personal qualities, knowledge, behaviors,

characteristics, and skills you bring to and acquire for your role as a business

analyst are known as the underlying competencies.

397

Essential Skills of Effective Business Analysts

Underlying competencies describe and reflect the behaviors, characteristics,

knowledge, and personal qualities that make you an effective business analyst

on a project. The BABOK

Guide categorizes these essential skills and

knowledge into six categories. You can think of these categories as building

blocks that you bring to each of your projects when you put on your business

analysis hat, roll up your sleeves, and start working. The underlying

competencies include the following:

Analytical thinking and problem-solving skills

Behavioral characteristics

Business knowledge

Communication skills

Interaction skills

Tools and technology

This chapter of the book steps you through these core skills. A strong and

balanced set of these underlying competencies provides you with tremendous

value when performing your project’s business analysis tasks. The “Underlying

Competencies” section is found in Chapter 9 of the BABOK

Guide.

Exam Spotlight

You will not find a specific percentage of questions about underlying

competencies on your certification exam. Instead, you will find questions

within the six knowledge areas that check your skills in and your knowledge

of these underlying competencies. Be sure to study this chapter thoroughly

because it is all considered testable content.

Of course, the skills and knowledge discussed here are not confined just to

performing business analysis work. They are fundamental skills required to

perform almost any role in any organization. Project managers, subject matter

experts, and senior managers are expected to possess a solid set of these

underlying competencies.

When Are the Underlying Competencies Used?

Even if you are on the right track, you will get run over if you just sit there.

—Will Rogers

The knowledge and skills found in the underlying competencies are used by

business analysts across the project life cycle as well as in their day-to-day work

398

that is not related to a specific project. You might find yourself selecting a

project approach by facilitating a meeting of key stakeholders and reaching

agreement on the best way to get the project underway and completed. You

might be called on to resolve a conflict between two opposing stakeholder

groups about the relative priorities of solution requirements. You might build

and deliver training on new solution capabilities to your end users.

Remember the Six Knowledge Areas

Be sure you know the six knowledge areas and the work you perform when

you are using them. These knowledge areas and their tasks are where you

apply the underlying competencies.

Business Analysis Planning and Monitoring This knowledge area is

where you plan how to approach your project’s business analysis effort. The

approach is a set of processes, templates, and activities used to perform

business analysis in a specific context. The tasks govern and monitor the

performance of all other business analysis tasks. These planning and

monitoring activities take place throughout the project life cycle. The results

of this knowledge area govern the tasks found in the remaining five

knowledge areas and set the performance metrics to be used to evaluate all

business analysis work.

Elicitation and Collaboration Elicitation and Collaboration defines how

business analysts work with stakeholders to identify and gather

requirements and understand their needs and concerns. A tremendous

amount of interaction with people occurs in this knowledge area. You will

find yourself working with the project team and the stakeholders to gather

requirements information, record the elicitation results, and confirm those

results with your stakeholders.

Requirements Life Cycle Management This knowledge area describes

how you will manage and maintain requirements and design information

from the beginning of the project to the end. You will find yourself

managing changes, conflicts, and issues related to the project requirements

across the project life cycle.

Strategy Analysis Strategy Analysis focuses on identifying the current

business state that drives a project and defining a feasible solution scope

that will provide the desired future state including the change strategy and

risk assessment. This knowledge area includes developing the business

requirements for a project that define the high-level goals, objectives, and

needs of the organization and the high-level business functionality needed

in the resulting solution.

Requirements Analysis and Design Definition Requirements

Analysis and Design Definition steps you progressively through elaborating

and prioritizing the stakeholder and solution requirements for a project.

Stakeholder requirements define the needs of stakeholders and how they

399

interact with a solution. Stakeholder requirements act as a bridge between

high-level business requirements and more-detailed solution requirements.

In turn, the more-detailed solution requirements describe the solution

characteristics and architecture that will be needed to meet the higher-level

business and stakeholder requirements.

Solution Evaluation Solution Evaluation determines whether value is

being delivered by proposed, in-progress, and implemented solutions

before, during, and after the project life cycle. This is also where the

project’s change strategy is defined. The solution limitations would also be

assessed and recommendations provided to increase the value of the

advised solution.

These key skills and knowledge may be used to perform any task or technique

found in any of the six knowledge areas. Let’s take a look at the first set of core

skills—analytical thinking and problem solving.

Analytical Thinking and Problem-Solving Skills

Facilitating solutions to business problems would be impossible without a

structured approach for addressing the problem at hand. Analytical thinking

and problem-solving skills enable you to assess and understand a situation.

Once that situation is fully understood, you can assess and recommend one or

more potential solutions to address the business need, problem, or opportunity

at hand. The BABOK

Guide breaks the essential analytical thinking and

problem-solving skills into seven more detailed areas:

Creative thinking

Decision making

Learning

Problem solving

Systems thinking

Conceptual thinking

Visual thinking

Let’s take a look at each of these areas that add up to an effective skill set in

analytical thinking and problem solving. First up are your creative thinking

skills.

Creative Thinking

Creative thinkers are able to generate new ideas, concepts, and alternative

solutions when solving business problems. Many times, the ideas being

generated are innovative and new ways to get the job done. It isn’t just about

your creative thinking skills. You also need to ask questions and challenge

assumptions in order to foster creative thinking in your other team members

and stakeholders.

400

Palmer Divide Vineyards: An Unexpected Freeze

Palmer Divide Vineyards recently reaped the benefits of creative thinking

and problem solving. Even though the weather at the vineyard is fairly

temperate, every now and then winter brings a freeze. There was an

unexpected freeze recently, but the vineyard watering systems suffered no ill

effects because the agriculture team quickly reacted to the cold

temperatures. Several years ago, the vineyard installed a new watering

system for the terraces of grapes it grows. The design of the new watering

system was a bit backward—starting with the water supply at the top of the

vineyard terraces and ending at ground level. Because of this creative

organization, staff members were able to turn a few knobs to drain the

watering system when the freeze hit instead of trying to find a company to

come and blow pressurized air to clear water out of the system. Using

gravity to drain the system from the terraces was both creative and

practical.

Creative thinking is just one piece of the puzzle. It is one thing to generate

innovative ideas and possible solutions to a problem and quite another thing to

decide what actually should be done in a particular situation. With that in mind,

let’s move on and talk a bit about business analysts and approaches to effective

decision making.

Decision Making

You should take a two-pronged approach to your decision making. You must

understand what is involved in making a good decision and be able to help other

project team members and stakeholders make good decisions. Decisions need to

be made in situations where you are faced with multiple ways of doing things.

You might be selecting between possible solutions to solve a business problem

or deciding which supplier will provide your project with goods or services. Your

decision analysis activities should include the following:

Gathering and breaking down relevant information

Making comparisons and evaluating trade-offs between options

Identifying the option that is most desirable

Part of your decision-making process is assessing the impacts of uncertainty and

of any new information. Remember, risk is defined as an uncertain event or

condition on your project. There are always risks associated with making

decisions. Your job is to minimize those risks by making the best decision

possible given what you know at the time.

There are several potential traps you might encounter during decision-making

401

activities. The first trap is accepting the initial framing of a problem without

questioning whether it is complete or correct. The second trap is the sunk cost

fallacy, where you look at what the organization already has and how much

time and money have been invested in those solutions. Based on that

information, organizations often continue on in the same vein. Another phrase

used to describe the sunk cost fallacy is “escalation of commitment to a failing

course of action.” The third potential trap is a tendency to place greater weight

on evidence confirming existing impressions instead of thinking out-of-the-box

and looking for more information.

Effective decision making is a key element for the business analyst. However,

there is more to doing your job well than just making decisions. You need to

learn from your experiences and be able to apply them to the work at hand. Let’s

take a closer look at how learning fits into our creative thinking and problem-

solving skills.

Learning

Dynamic project environments encourage business analysts and all stakeholders

to learn new things. As you develop requirements for different parts of the

business, you should absorb new business information so you can translate that

information into your requirements and their resulting solution.

It isn’t enough just to learn and remember data and raw facts. Learning can

occur from visual input, auditory experiences, and the kinesthetics of doing

something new. Experienced business analysts apply their understanding of the

information to determine what is required for a given situation. This application

is also known as analysis. You should also be able to synthesize what you have

learned in order to identify opportunities to create new solutions. After new

solutions are in place, you are also responsible for evaluating them to make sure

that the resulting new solutions are effective and then making stakeholders

aware of the new elements, which will allow for a full cycle of learning processes.

One key application of learning new business domain information is being able

to apply it properly to the business analysis tasks in your project. Let’s take a

look now at the problem-solving skills of effective business analysts.

Problem Solving

Business analysts are frequently asked to evaluate and select solutions that meet

defined business objectives. Your project’s selected solution targets solving an

underlying problem, meeting a business need in the organization, or both. Your

primary goal when addressing a business problem is solving that problem. You

get this done through a combination of problem definition, alternatives

identification, and decision making. Let’s take a look at each item.

Problem Definition You need to make sure that the problem or business

need being addressed is clearly defined and understood by your stakeholders.

Any issues related to the problem or need should be identified and shared with

the group. All conflicts between stakeholders relative to the problem or need

should also be addressed.

402

Alternatives Identification Often there are many ways to solve a problem or

address a business need. Solution options are developed, analyzed, and

evaluated by the group. Remember that the solution options under

consideration should meet the defined objectives and actually solve the problem

and/or meet the business need.

Decision Making Once your problem or need is clearly defined and the

solution alternatives are identified, it is time to make or recommend a decision.

Trade-off decision making may be required to select the best solution to the

problem or need. You want to avoid selecting a suboptimal solution because of

politics or preconceived notions.

Making good decisions during your project’s business analysis work requires

having the right information and involving the right people. Your ability to put

together all the pieces—what your organization does, what is known about the

problem at hand, and who needs to be involved—supports your skills in

structured problem solving and decision making. This takes us right into the

next area of competency, systems thinking.

Systems Thinking

Systems thinking looks at your ability to put all the pieces together and

understand the properties, behaviors, and characteristics of the system as a

whole—across people, processes, and technology. This information is a moving

target and can be quite unpredictable. You need to recognize that systems are

not just information technology systems. You are looking at systems in the

broader sense, consisting of not just the technology components but the people,

the processes, and almost any other factors that come into play. This holistic

approach will produce the most optimal results.

Projects and their resulting solutions are like puzzles; they possess many pieces

and parts. Changes to one part of the puzzle can impact other parts, as well as

the whole puzzle. You need to be aware of the complex systems that make up

your business operations and keep an eye out for impacts within your new

solution, as well as to the business itself, as work is being performed and

decisions are being made.

Let’s move on to the next category, one that also requires a holistic perspective.

Conceptual Thinking

Business analysts receive and process vast amounts of information and details

in the course of their work. Applying conceptual thinking to the entire data set

means that business analysts are able to identify patterns or connections

between seemingly unrelated information. This big-picture view allows you to

connect seemingly abstract, disconnected parts into something that makes

sense. Past experience, innate skills, and your creativity help bring everything

from multiple stakeholders and perspectives together in a cohesive, workable

solution.

Your ability to confirm and convey with confidence the relationship between

403

seemingly disparate information will help stakeholders grasp the connections

and put them into action. Sometimes, the picture becomes clearer to those we

are trying to help understand with the use of our next skill.

Visual Thinking

Effective communication is often aided by connecting the content receiver with

as many different touch points as possible. You have no doubt heard the saying

“A picture is worth a thousand words.” Visual thinking allows a business analyst

to communicate complex ideas through visual representation, such as models,

graphics, diagrams, and illustrations. Some stakeholders may prefer nonvisual

and descriptions; others may really grasp the ideas you are trying to convey once

they see the visual. Both together will give the greatest opportunity to convey

your concepts in a way that both right-brain and left-brain thinkers will be able

to understand.

Finding the patterns, visually mapping the ideas and connections, and making

comparisons may also be easier to understand when an illustration is provided.

Some diagrams or images can be universally useful for conveying a specific

thought or concept each time it is presented.

The next category in the underlying competencies is the behavioral

characteristics of the business analyst. Your effectiveness on projects is not

based totally on how well you illustrate your point, solve problems, or make

decisions. It is also impacted by the behaviors and personal values you bring to

the work you do.

Behavioral Characteristics

Effective business analysts should apply personal integrity and strength of

character when dealing with people. This includes dealing with your business

analysis team, your project team, and your internal and external project

stakeholders. Your ability to build strong, lasting working relationships serves

you and your project well. The BABOK

Guide breaks the key behavioral

characteristics into these five areas:

Ethics

Personal accountability

Trustworthiness

Organization and time management

Adaptability

Let’s take a look at each of these essential behaviors you should exhibit in the

workplace. Our first stop is a quick look at ethics and ethical behavior.

Ethics

To be respected and trusted by your team and your stakeholders, you must

behave ethically. That’s easy enough to say, but what exactly does it mean?

404

Ethical people know the difference between moral and immoral behavior and

understand the standards that govern their own behavior. They act in a moral

way to meet those behavioral standards.

Surprise Status

During lunch, Ginger overhears information that concerns her regarding the

current status of an important business continuity study program she is

working on for a large financial services firm. One of the new technical team

members sitting at the next table is talking loudly to a group of his friends.

He brings up a piece of information regarding the project’s status that is

inconsistent with the current status that he just reported to Ginger and Kim,

the program manager, on an area that he is responsible for in the project

plan.

“Guys, I’ve only been here six months, and I’m working on something that is

leading edge and important. I just found out from my buddy in IT that the

set of records that tracks which staff members were trained and cross-

trained on critical plant operations is gone. The data got erased in a failed

server transfer. Poof! No backup files. How weird is that? Hope they have

hard copies somewhere. But it’s cool. They’ll find what we need eventually.”

Ginger leans across the table and asks, “Wait a minute; have you told the

rest of our team about this?”

He replies, “No way, Ginger. Tomorrow someone will find the hard copies in

somebody’s cube, and I’ll look like an idiot. I just sent in my status report

anyway. I’m not revising that thing unless I absolutely have to.”

Ginger gets to her feet and collects her things.

“Come on, let’s find Kim and give him this update. That missing data affects

our results tremendously, and this can’t wait. Grab your sandwich and come

with me.”

Withholding critical project information and issues is neither good nor

ethical project team behavior. You should always be straightforward in

sharing important information so problems can be identified and addressed

as early as possible.

Your ethical behavior often comes into play during business analysis work. You

may find yourself recognizing that a proposed solution or a particular

requirement presents ethical difficulties. Ethical business analysts consider the

interests of all stakeholders when making decisions and are sure to clearly

articulate the basis of their decisions so everyone understands. Any conflicts of

interest should be promptly and fully disclosed.

Ethical behavior generates trust and respect in the workplace. Personal

405

accountability is another behavioral characteristic that you need to review. Let’s

do that right now.

Personal Accountability

When business analysts are responsible and answerable for their own decisions,

work, and results, the effectiveness of the team can greatly increase. Colleagues

and stakeholders will have confidence that tasks will be completed to

expectation and on time. The team is counting on the business analyst to deliver

value, achieve stated milestones and goals, and assure that the business needs

are satisfied with the right solutions. Personal accountability also means

escalating risks to appropriate parties and managing concerns while meeting the

ultimate goal.

Personal accountability and our next key behavioral characteristic go hand-in-

hand, so on to exploring trustworthiness.

Trustworthiness

Behaving ethically while performing your business analysis work effectively

generates trust between you and your stakeholders. They trust you to do the

right thing at the right time on the project and to keep their interests front and

center in your decision-making process. This allows you to engage with your

stakeholder’s needs and act in their best interests at all times.

Earning the trust of key stakeholders is a linchpin of successful business

analysis. It is difficult to develop requirements when folks won’t tell you what

you need to know to define the best solution to meet their needs. Respect and

trust can also be earned by exhibiting effective time management skills. Let’s

take a quick look at organization and time management and see how it enhances

your behavior and how you are perceived as a business analyst.

Organization and Time Management

Experienced business analysts can quickly locate needed information and use

work time efficiently. Your ability to effectively manage your time, tasks, and

information has an impact on how your team members and other stakeholders

perceive you. A disorganized business analyst is not viewed as an effective

business analyst. You should set your work priorities, be clear about what needs

to be done, and get that work done quickly and well.

Let’s move on to the next category in the underlying competencies, adaptability.

Adaptability

A business analyst encounters a number of stakeholders, departments, groups,

or concerns daily. It is critical to your success that you are able to adjust readily

to different conditions, situations, and changes. This may mean switching your

approach, technique, style, or tool currently in use to meet the needs of one or

more of your stakeholders.

406

By nature, we often think others like things or process ideas exactly the same

way we do. It is a sign of leadership to understand that sometimes it is best to

bend our ways and get out of our comfort zone to make things easier for another

to understand or process. Observing what worked, what did not, and what could

be done differently next time is a good adaptability trait to own.

Let’s move on to the next category in the underlying competencies, business

knowledge. Your effectiveness as a business analyst is defined not just by what

you do but also by what you know.

Business Knowledge

It is impossible to be a liaison between the business and the technology

stakeholders on your projects if you have no understanding of the business.

Skilled business analysts understand the internal and external business

environment surrounding their projects. They use that knowledge to make good

decisions and recommendations about what should be done to define and

deliver a solution that addresses business needs. The BABOK

Guide breaks

your business knowledge into these five areas:

Business acumen

Industry knowledge

Organization knowledge

Solution knowledge

Methodology knowledge

Let’s take a look at each of these areas, starting with assessing your business

acumen.

Business Acumen

Effective business analysts are aware of the business principles and business

best practices in their organizations. This is important because you need to

incorporate and support these principles and practices in your solutions.

Business principles are defined as the characteristics common to organizations

of similar purpose and structure, such as human resources, finance, and

information technology functions. In contrast, business practices or processes

vary based on what an organization does and the size of that organization.

Business principles for a large pharmaceutical organization are very different

from the principles found at a large retail organization. However, there may be

many similarities in how their business practices work for hiring their people

and getting those folks paid every two weeks. Business acumen goes beyond just

the principles and practices of a specific organization or setting and shows that

you comprehend the business needs. Your solution will be based on all your

experience, skill, knowledge, and expertise applied to the current situation. This

also includes knowledge of your organization’s industry. Let’s take a quick look

at your expected level of industry knowledge.

407

Industry Knowledge

Do you have good knowledge and understanding of the industry of which your

organization is a part? If not, you should. Understanding what is taking place in

your industry can have positive impacts on your projects and their solutions.

You should be aware of your major competitors, partners, and customer

segments. Your knowledge should also encompass your organization’s common

products and product types.

Case Study: Palmer Divide Vineyards

The project team was meeting about the Research Study project effort that

was underway at Palmer Divide Vineyards. The effort had been scoped out,

and more detailed solution requirements were being developed. The key

stakeholders and team members disagreed about whether the project

should build a new software application using existing technology or

purchase a customizable software package containing the capabilities the

organization needed. Everyone was concerned about making sure that the

new system accommodated the alcoholic beverage licensing requirements.

Taylor, the IT director, was facilitating a meeting where people could not

agree on a course of action. Prior to developing the detailed solution

requirements, she felt that a decision needed to be made about the project

approach. The requirements that the group would build for a vendor

selection effort were significantly different from the more technical

requirements they would write if the development work was to be done by

the internal IT team.

Luckily, Taylor was prepared for this meeting and brought some additional

research data for the group to review. A recent issue of American Vineyard

Magazine contained a study that evaluated a number of software

applications targeting operations for smaller, regional vineyards. Among the

evaluation criterion for these packages was the requirement for meeting

alcoholic beverage licensing requirements. As the group reviewed this

information relative to the new capabilities already agreed upon for the new

system, they quickly discovered that purchasing a package would provide

them with more capabilities than they were looking for at a higher cost than

they had been planning to pay.

Using their own research and the software study, the group was able to put

together a business case and impact analysis for the two options for review

and selection by the senior management team and the vineyard owners. The

industry knowledge was invaluable in preparing their business case without

taking the time to reinvent the wheel and research each vendor product in

detail.

408

There are many existing assets to use during your business analysis work, such

as industry-focused resource and process documents, standard processes,

methodologies, current industry trends, market forces or market drivers, and

information pertaining to any regulatory environment where work is done.

Possessing some basic knowledge of the industry where you do business adds

great context to your project efforts. Industry and business knowledge should be

supplemented by organization knowledge. Let’s take a look at that subject right

now.

Organization Knowledge

Understanding your organization and how things get done enables you to get

your own work done and make good decisions within that organization. This

includes understanding how your organization generates their profits and how

goals are communicated and accomplished. Your organization provides the

primary context for your work efforts. This definition of organization includes

the entire business architecture: business models, management structure and

how that relates to the organizational structure, business unit relationships, and

your key project stakeholders.

Organization knowledge includes recognizing the informal lines of

communication, authority, who the subject matter experts are, and what

internal politics are in play relative to your project. It is important that you

speak the organizational language, using the right terminology or jargon during

your work efforts. Organization, industry, and business knowledge should be

supplemented by more technical solution knowledge as well. Let’s get just a

little bit technical for the next area.

Solution Knowledge

Experienced business analysts are familiar with existing solutions and their

capabilities within the organization. This allows them to effectively identify,

assess, and implement changes to those solutions. These changes can range

from simple alterations to complex replacement projects. When change is

requested, your role is to make certain the request is accompanied by a cost-

benefit analysis so the change request can be justified by the business benefit

that will be gained through its implementation. Your solution knowledge often

reduces the time you spend developing project requirements or assisting with

solution design activities on your project. This can lead to reduced

implementation time and/or cost on a project when the change can be proven to

offer business value. When the benefit cannot be validated, wasted time and

unnecessary cost can be avoided.

Now let’s look at one last business knowledge category, methodology

knowledge.

Methodology Knowledge

While developing your business analysis approach, understanding an

organization’s standard methodologies sheds light on opportunities, constraints,

409

dependencies, and context.

Organizations may adopt industry-standard methodologies or create their own

to fit their industry, culture, adaptability, and maturity. Methodologies can also

shift based on emerging best practices or changes in the organizational

leadership. A business analyst who remains flexible and able to integrate new

methodologies quickly will be well served by this skill.

That sums up the key knowledge required of effective business analysts. This is

a lot of information about your business principles, business practices, industry,

methodology, organization, and existing solutions. As previously mentioned,

you don’t have to be an expert in everything, but a little knowledge in each of

these areas can be of great assistance on your projects. Let’s move on and look at

your knowledge and skills when using tools and technology in your role as a

business analyst.

Tools and Technology

Software applications are typically used by business analysts to support

communication and collaboration and develop and manage requirements. They

store information about model concepts, issues, risks, and requirements, as well

as track productivity. Specific applications may include a word processor to

document project scope, a requirements management tool for developing

detailed user and system requirements, or a cloud service to store all the

information. Although using a requirements management tool is not a required

skill, the ability to master and apply requirements management, word

processing, spreadsheet, and communications tools is considered a desirable

trait in experienced business analysts.

You need proficiency in three types of software applications. Office productivity

tools are the first. Second, you will need awareness and skills with business

analysis tools and technology. Third, you must be familiar with communication

tools and technology. Table 8.1 summarizes each of these types.

TABLE 8.1 Tools and technology

Type Definition Examples

Office

productivity

tools and

technology

Tools used to capture,

organize, dissect, study,

manipulate, store, and

distribute information

Word processing Spreadsheet

Presentation Document repositories

Cloud or web-based services (such as

document storage) Printers Digital

projectors Scanners Copiers

Business

analysis tools

and technology

Requirements

development tools used

to develop, validate,

and implement formal

models, and to

build/manage

requirements

documentation and

Diagramming tools Modelling tools

Requirements management and

workflow tools Change control

Traceability Configuration

management Risk management

410

artifacts

Communication

tools and

technology

Tools used to

collaborate in the

planning and execution

of tasks. Allows

collaboration whether

co-located or working

with virtual team

members

Voice communications Instant

messaging Online chat Email

Blogging Video conferencing

Electronic white boarding Wikis

Electronic calendars Online

brainstorming tools Electronic

voting and decision-making tools

Document share tools

Diagramming tools are viewed as low-cost options that support the rapid

drawing and documentation of graphical models by providing a set of templates

for a given notation method. In contrast, modelling tools tend to be more of a

medium- to high-cost tool. They convert graphical models into an executable

form either by using a proprietary engine or by generating actual application

code.

While proficiency with tools and technology is appreciated on your projects,

proficiency in many forms of communication is even more crucial to your

project’s success. Let’s look at the communication skills that effective business

analysts bring to their projects.

Communication Skills

A major reason for project failures is poor communication. Business analysts

must have excellent communication skills in order to develop project

requirements that correctly and completely state what the new solution will do

for its users and the business. Communication has several dimensions that are

addressed by the BABOK

Guide.

Verbal communication

Nonverbal communication

Written communication

Listening

Let’s dig a little deeper into each of these areas, starting with your proficiency in

communicating verbally.

Verbal Communication

Experienced business analysts are experts at conveying facts, concepts,

opinions, and ideas in understandable ways. One way to do this is by verbal

communications. This means that you transfer ideas or information verbally to

your target audience. This exchange of information between a sender and

receiver involves more than just speaking the words. Your words are

accompanied by emotional and other nonverbal cues that can add positive

reinforcement to what is being said.

411

Lines of Communication

Communication becomes more complex as the number of people involved

increases. Network models are used to explain the complexity of

communications. They consist of nodes with lines between the nodes

indicating communication. You need to be able to calculate the lines of

communication in a network as part of your preparations for taking your

certification exam.

The calculation for the number of lines of communication in a network is as

follows:

(n × (n – 1))/2

where n = the number of people or nodes in the network. So, for a

project network containing five stakeholders, the number of lines of

communication is as follows:

(5 × 4)/2 = 20/2 = 10

Figure 8.1 graphically depicts these ten lines of communication between the

five nodes in the network.

FIGURE 8.1 Lines of communication

Good communicators are able to facilitate meetings and deliver presentations

and briefings. Nonverbal communication is also used when you are sharing your

knowledge and communicating with others about your project. Let’s move on

and talk a little bit about the nonverbal communication skills found in effective

business analysts.

Written Communication

As a business analyst, you will find yourself spending much time documenting

and recording your elicitation results, project requirements, and other relevant

information. This work takes place across the project life cycle. If you are not a

good technical and business writer, you will need to master those skills quickly.

You must be able to write effectively for different contexts and audiences on

412

your projects. The BABOK

Guide recommends that effective business analysts

possess the following written communications attributes:

Broad vocabulary

Strong grasp of grammar and style

Understanding of idioms and terms

Exam Spotlight

Be sure you are comfortable explaining the basics of information exchange

using the sender-receiver model. This model governs both written and oral

communications on your projects. Senders package or encode messages that

are sent to the receivers. The receivers then unpack or decode the messages.

Transmitting gets information from the sender to the receiver for both

spoken and written forms of communication. Decoding of the received

message is performed by the receiver. This is where the receiver converts

the message to a form that they understand.

Listening

Effective listeners, sometimes referred to as active listeners, stay focused on the

speaker and are not distracted from what is being said. Your ability to maintain

your focus on the speaker allows you to understand, interpret, and evaluate

what is being said in a calm, systematic fashion. Often, active listeners maintain

eye contact with the speaker and then paraphrase statements back to the

speaker to ensure that the listener understands what is being said. This assures

that both parties have the same understanding of the communicated message.

Your communication skills are closely linked to your interaction skills. Effective

business analysts play well with others. Let’s move on and explore those

interaction skills in greater detail.

Interaction Skills

Strong business analysts tend to be team players. In large part, this is because of

their ability to interact and work well with other members of the team. The team

is often composed of many different types of people from different

organizational areas and personalities. Organizational areas may include

executive level, client side, sponsors, colleagues, developers, vendors, users, and

subject matter experts. Personality differences may include learning and

communication styles and corporate knowledge. Leadership and facilitation

skills play a key part in defining and agreeing to a solution to a business

problem or need. The BABOK

Guide breaks the necessary interaction skills

into these components:

Facilitation

413

Leadership and influencing

Teamwork

Negotiation and conflict resolution

Teaching

Let’s look closer at each of these components, starting with your facilitation

skills.

Facilitation

Strong facilitation skills serve multiple purposes for business analysts. You may

find yourself facilitating many different types of interactions between

stakeholders, such as resolving disagreements regarding the priority and nature

of requirements during requirements development. You will moderate any

number of group discussions and meetings, making sure that all participants get

to share their views and opinions on the topics being discussed. Good

facilitators must ensure that there is recognition and appreciation of differing

viewpoints across the project life cycle.

Effective facilitation on your projects must be accompanied by leadership and

influencing skills. Let’s look at this next component of interaction skills required

for a good business analyst.

Leadership and Influencing

Managing is primarily concerned with consistently producing the key results

expected by your stakeholders. Good leaders and good managers are not

necessarily the same thing. Leadership is not quite so tangible. It establishes the

vision and direction to a desired future state and enables people to work

together to get to that future state. Good leaders motivate and align people to

work toward a vision. They communicate that vision through their own words

and deeds.

You will fill many formal and informal leadership roles as a business analyst.

You are responsible for developing requirements and getting your project

stakeholders on board with the vision for a desired future state—the new

solution and its capabilities. You are an agent of change, since your new solution

will change the way people do their jobs.

Your leadership skills are directly related to your ability to influence people in

order to get things done. You must have a solid understanding of the formal and

informal organizational structure where you are working. You must be able to

apply the mechanics of power and politics to get things done, even when you

have no formal power in a given situation.

Power is the potential ability to influence behavior and change the course of

events. Power allows you to overcome resistance and get people to do what they

would not do otherwise. In comparison, politics is all about getting collective

action from people who may have different interests. Sometimes, you will find

yourself using conflict and disorder creatively in order to get things

414

accomplished in your organization.

There are five levels of power. Of these levels, punishment power is the least

desirable technique for obvious reasons. Although the BABOK® Guide does not

discuss the levels of power directly, they have been known to show up in

certification exam questions. Here they are for your review as part of your study

preparations:

Reward Power Reward power allows you to provide people with incentives or

bonuses in order to get things done. Rewards don’t have to be money. They can

be comp time for working over a weekend or movie tickets for a team member

and their family.

Punishment Power Punishment power is not a recommended type of power

for collaborative team environments. Punishment power involves threatening

people with negative consequences (penalties) if they do not do as you say.

Expert Power Expert power allows you to influence others based on your

knowledge or abilities. In addition to your role as a business analyst, you might

also be a specialist or subject matter expert (SME) in a particular industry area.

Legitimate Power Legitimate power is associated with the formal job position

that you occupy and should be exercised carefully. You can always demand that

things be done based on your power of position. However, it is better to

collaborate with your team members and reach consensus about how everyone

will perform their work.

Referent Power Referent power is a positive source of power for you. It is

given to you by your subordinates based on their respect and regard for you.

This earned power can be used to influence and motivate your team members to

perform at a high level.

In addition to your leadership and influencing skills, you must be able to work

well in a team environment. Let’s talk a bit more about your essential teamwork

skills.

Teamwork

Business analysts must work closely with other project team members to

effectively define and implement new solutions. You have a role in creating the

team environment, as well as contributing to that environment where everyone

shares the ownership of the team goals for the project. Experienced business

analysts are quite good at building effective working relationships with others in

order to enhance the quality of team communications and reduce conflicts.

Modelling Team Development

The Tuckman model of team development breaks team development into

four or five stages. Each stage has distinct characteristics. Be sure you are

familiar with this model and its stages for your certification exam.

415

Forming Forming is the earliest stage of team development where the

team members meet and are introduced to one another and to the project.

Team members working together in this phase tend to exhibit reserved and

more formal behavior to one another.

Storming This stage is characterized by confrontations as team members

vie for position and control within the group. Everyone is jockeying for

status within the group, and things can be a bit chaotic.

Norming This is the stage where team members have adjusted to one

another. They can now focus on project issues and objectives. There is

cooperation and collaboration between folks on the team, and work is

getting done.

Performing In this stage of team development, the planets are in

alignment, and the team members work effectively and productively

together. The group shares a high level of trust and achievement.

Adjourning or Mourning Some sources added a fifth stage of this model

where the team is broken apart as work is completed and folks move on to

their next project effort.

Another key aspect of teamwork is the ability to motivate yourself and other

members of the team. You will often find yourself using your motivation skills to

energize your fellow team members and project stakeholders in order to achieve

a high level of performance and to overcome any barriers to change.

There are several common motivational theories that you, as a business analyst,

might bring into play. The BABOK

Guide does not address them in detail, but

they are known to occur occasionally in a question or two on your certification

exam. They are listed here for your review:

Achievement Theory People are motivated by a need for achievement,

power, and affiliation. Teams populated by achievement-motivated team

members are a dream come true. Many folks work hard and motivate

themselves because it is important to them that they do a good job. Other folks

may be motivated by more tangible things, such as compensation, bonuses, and

possibilities of advancement.

Frederic Herzberg’s Motivational-Hygiene Theory Herzberg’s theory of

motivation is fascinating. There are two sides to the theory. The first side

contains the hygiene factors. Hygiene factors are things that prevent people

from becoming dissatisfied (such as pay, benefits, work conditions, and working

relationships). The funny thing about these factors is that in and of themselves

they don’t motivate people. The second side contains the motivation factors.

These factors lead to work satisfaction and motivation and are quite different

from the hygiene factors. They include opportunities for advancement, learning,

challenges, and the work itself.

Expectancy Theory Expectancy theory is a little bit like the carrot and the

stick—well, at least the carrot portion of the situation. The basis of this theory is

that expecting a positive outcome creates motivation in people. This is because

416

the expectancy and the likelihood of a reward are linked to people’s behavior.

The rewards don’t have to be tangible things, such as money. They can be less

tangible things, such as recognition for a job well done.

Theory X and Theory Y This motivation theory has been around for quite

some time. Theory X tells us that people are inherently lazy and need to be

threatened in order to be motivated. In contrast, Theory Y states that people

seek out responsibility and respond to proper expectations in the workplace.

Theory Y is more commonly found in today’s workplace, especially among

knowledge workers.

Contingency Theory Contingency theory puts forth that the effectiveness of a

leader is dependent on the characteristics of that leader, the situation they find

themselves in, and the group in which they are a part. There is no one ideal

leader, so your management style and your methods to motivate your team

should be appropriate to the situation that is at hand. This is a more situational

approach to motivating people.

Negotiation and Conflict Resolution

Negotiation is often a facet of business analysis work. People don’t always agree

on things, and that needs to be sorted out. Effective negotiators are able to

identify the underlying interests of involved parties, distinguish those interests

from their stated positions, and ultimately identify solutions that satisfy the

underlying interests while still keeping the business need and objectives in

mind.

Working in teams also requires you to manage and address conflict. The basic

types of conflict are emotional and cognitive. Emotional conflict stems from

personal interactions, while cognitive conflicts are based on disagreements on

matters of substantive value or impact on the project or organization.

Resolution of cognitive conflict requires the team to focus on examining the

premises, assumptions, observations, and expectations of the team members.

Working through such problems can have the beneficial effect of strengthening

the foundation of the analysis and the solution. Many conflict situations

encompass both emotional and cognitive elements.

Increasing Your Space

Russ, a project manager, was walking down the office hallway one day when

he noticed something odd. One of the cube walls situated between the cubes

of his project’s top two systems architects had come loose from the floor.

The wall had moved over into one person’s cube and looked as though it

would require a bit of repair. It was the end of a very busy day, so Russ

made a mental note to follow up about the mysterious moving cube wall the

next morning.

417

The next morning, Russ was walking by with his coffee, and he noticed that

the traveling cube wall had moved yet again. Today, the wall was occupying

space in the other team member’s cube. Shaking his head, Russ decided to

do a little investigating right after the morning project status meeting.

Russ didn’t have to wait very long after the meeting to discover what was

happening with the moving cube wall. As he exited the meeting and turned

down the hallway, he was treated to a full exhibition of how the cube wall

was moving back and forth. The systems architect in the space-limited cube

was sitting on the floor, pushing the cube wall back into the other team

member’s cube with his feet.

“How interesting,” Russ thought. “I wonder what happens next.”

What happened over the next few days was a conflict in motion. Each team

member took turns shoving the cube wall into his teammate’s space. After

observing the phenomenon, Russ decided to intervene. Calling both team

members into his office, he asked them what was up with the cube wall.

“He unbolted it and started this,” complained one team member. “It was

right after the project approach meeting where my approach to solution

technology and infrastructure was selected as the solution approach for the

project.”

“My approach was the better one,” replied the other team member. “Yours

was chosen because you have worked here longer, not because it had any

technical merit.”

They continued to bicker for a short time, until Russ interrupted them.

“Since you two are obviously in need of some togetherness,” Russ said, “Let

me tell you what we are going to do. The moving cube wall will be removed,

and the two of you can share the office space for a time to see if you can

work out your differences.”

And that’s exactly what happened. Russ, knowing the men’s fast friendship,

confronted the problem and offered up a compromise solution where each

team member gave up their private space for a time. The good news is that

after a few days, the team members’ differences were resolved, and they

asked Russ to put their cubes back the way they were. The missing cube wall

was reinstalled (and bolted down with a few extra bolts) the following week.

Although it was risky to exercise a mild form of punishment power by

combining the cubes, Russ used the situation as an opportunity to stress

that the team members needed to work together. The underlying problem

was a battle of technical egos, and moving the wall was a convenient way for

each team member to be (at least temporarily) the king of the hill with the

larger cube. The two team members involved were actually good friends.

Moving the cube wall had started out as a joke and somehow escalated into

a larger conflict that was beginning to polarize the remaining team members

by implying that they should take sides.

Luckily, there was more than enough technical work to go around on this

project. The friendship was stronger than the conflict between the two

418

architects. Everyone discovered that the project results and the general

work environment were much better when these two systems architects

were pulling in tandem instead of pulling against one another. Russ took a

calculated risk with this approach, and he solved his problem.

There are a number of conflict resolution techniques you may choose to apply in

a given situation. Be sure you are familiar with them as you may see them

mentioned on your certification exam even though they are not specifically

outlined in the BABOK

Guide. Table 8.2 summarizes these techniques and

their outcomes for you to use in your studies.

TABLE 8.2 Summary of conflict resolution techniques

Technique Outcome Description

Forcing Win–Lose People often force others in order to resolve

conflicts. They can do this if they have power and

demand a particular outcome.

Smoothing Lose–

Lose

This technique results in a temporary reduction in

the perceived severity of a conflict but provides no

permanent solution.

Compromise Lose–

Lose

Each party reluctantly complies and gives up

something to reach a solution. This can lead to a

permanent solution if commitments are kept even,

although all parties lose something in this situation.

Confrontation Win–Win This addresses the conflict using problem-solving

methods where an analysis of facts leads to the best

solution that becomes a permanent solution.

Withdrawal Lose–

Lose

This occurs when one party refuses to even discuss

the conflict. This approach never addresses or

resolves the conflict.

You will often find yourself resolving interpersonal conflicts by using your

effective interpersonal negotiation skills. Learning to manage conflict is integral

to a high-performance team. It is important to recognize that not all conflicts

can be resolved. Effective business analysts assess and establish their own

conflict management approach and acquire skills in conflict resolution

techniques and conflict modes.

Confronting a problem is considered to be the best method for conflict

resolution with the highest likelihood of permanent solution. This involves

laying the problem and any related information out on the table, getting the

involved parties to discuss what is going on, and reaching a resolution.

Teaching

Teaching is closely related to communicating with your project stakeholders.

You may find yourself operating in a teaching mode as you communicate project

issues and requirements to your stakeholders, making sure they are understood

419

and agreed upon. Many times, business analysts find themselves facilitating the

learning experiences of their project stakeholders, teaching them about the new

capabilities, describing a new solution, or leading a meeting to determine what a

set of requirements might be.

Effective teachers are aware of the different learning styles found in their

students and alter their teaching approach to accommodate those preferences.

There is also a practice and feedback loop in teaching, very much like the

sender-receiver model of effective communications. It isn’t enough to deliver

your information to the stakeholders. For example, you might find yourself

teaching stakeholders about a new graphical modelling technique. Whenever

you are teaching, you must provide your audience the opportunity to practice

and then confirm that your audience has learned what was needed and can

apply what they have learned.

Learners receive and process information differently depending upon the

learner, the content, and the situation. As discussed earlier in this chapter, there

are three learning styles: visual (seeing or viewing), auditory (hearing and

verbalizing), and kinesthetic (doing). Best practice for training material design

is to encode your content in a way that reflects at least two learning styles.

That wraps up your review of the underlying competencies required for an

effective business analyst. This is certainly a significant list of knowledge and

skills for any business analyst to master. Remember not to try to excel in all

areas at once. Work to your strengths and slowly improve your weak areas over

time. This is one situation where practice certainly strives to create perfection.

420

How This Applies to Your Projects

Professional detachment is another essential skill for business analysts. Your

ability to remain in control of yourself will be tested regularly when people

become angry or frustrated when the way things are done changes, when people

don’t get their way, or when your fellow team members and stakeholders have

straightforward personality clashes. Being self-aware and regulating your own

emotional responses in such situations will serve you well.

Mastering your professional detachment skills provides you with a new attitude

toward what happens on your projects regardless of the emotional intensity.

Professional detachment is about looking at the events from a distance without

being too emotionally involved or taking what happens on your projects

personally. Professional detachment must be nurtured to prevent

embarrassment and steer you away from making uncalculated actions and

reactions. People usually regret being provoked into instant emotional reactions

because those reactions must be followed by damage control. Analysts prefer to

handle conflict professionally and avoid the need for the damage control.

Tolerance for others and their verbal or physical actions is the key to your own

professionalism. Observe yourself and learn what your triggers are. Discover

your preferred approaches to managing conflicts. Learn to be a stronger, more

capable facilitator. Practice your presentation skills and remember how your

mother always said to count to ten before you say anything when you are angry

or irritated.

Phil’s Checklist: Dealing with the People on Your Projects

Phil, a fellow business analyst, offers up the following list of techniques that

he practices faithfully and successfully. He recently presented it at a team

meeting kicking off the requirements development effort for a major IT

project, and everyone found his practical advice to be quite useful. You will

probably like Phil’s list, too.

Compartmentalize. Focus on one task at a time. Don’t let everything pile

on you all at once. You don’t want your mind to be thinking about what you

just did or what you’re going to do, only on what’s in front of you.

Be proactive. Focus on what needs to be done and then do it. Action

creates positive energy; inactivity leads to frustration. If you don’t know

what to do, figure it out. And don’t forget that you have a business analysis

team to help you figure things out.

Have real conversations. When you talk to your clients or your team,

focus on what needs to be done, not on emotions. Don’t buy into your

421

stakeholder’s emotions. Rather, lead them to focus on what can be done to

solve the problem or resolve an issue.

Focus on what to do next. There’s nothing you can do about the past

except learn from it. Lessons learned are great when applied to future

situations. You never stop learning lessons when dealing with people on

your projects. And remember, hindsight is always 20/20.

Build a Plan B. To become detached from the outcome, have a

contingency plan or a Plan B for certain situations on your projects. Then,

you don’t have to worry so much about what is happening now, because you

aren’t as dependent on the outcome. You have a contingency plan to

implement if things go astray.

It is about the business, not about you. Do not internalize the

behavior and emotions of your stakeholders or business analysis team.

Acknowledge their feelings, let them know that you understand, and then

use your professional detachment to help them become more detached

themselves so they can get beyond their emotions and make rational

decisions.

Objectively assess your performance. Resist the impulse to get down

on yourself. At least half of your job is looking for desired future states and

new solutions. No one’s crystal ball ever operates at 100 percent.

422

Summary

The skills and knowledge found in the “Underlying Competencies” section form

the basis for your work activities and people interactions on your projects. It is

difficult to work on a project without possessing a core set of skills, knowledge,

and capabilities that enhance how you perform your tasks and interact with the

people around you on a daily basis.

The underlying competencies enable you to do your work effectively in a

collaborative business environment. The skills, knowledge, and behaviors that

you bring to your projects are a significant factor in your ultimate success at

defining the right requirements and deploying a new solution that meets

everyone’s needs and expectations.

The BABOK

Guide recommends that you apply a subset of the underlying

competencies to every business analysis task and technique that gets done on

your projects. You don’t need to be an expert in every skill or possess knowledge

in every aspect of the business, but most experienced business analysts have a

core set of skills and behaviors that serve them well as they get the job done.

423

Exam Essentials

Be able to list and describe the high-level skills, knowledge, and

behaviors found in the “Underlying Competencies” section. You will

see questions about high-level skills, knowledge, and behaviors found in the

“Underlying Competencies” section throughout your certification exam. These

questions may appear in each of the six knowledge areas.

You should memorize the key competencies and make sure you understand

what they are all about. The six areas are:

Analytical thinking and problem-solving skills

Behavioral characteristics

Business knowledge

Tools and technology

Interaction skills

Communication skills

Be able to apply the additional skills and knowledge found in this chapter that

are not specifically contained in the BABOK® Guide. Several topics contained in

this chapter provide additional details to the contents of the BABOK

Guide.

These topics are known to show up in certification exam questions, and they are

worth learning as part of your exam preparation activities.

Lines of communication

Tuckman model of team development

Conflict-resolution techniques

Motivational theories

The five levels of power

Be able to discuss the three types of learning styles. As a teacher, you

will typically encounter three types of learning styles. They include visual

(learning best by seeing something done), auditory (learning best by hearing),

and kinesthetic or tactile (learning best by doing themselves).

Be able to compare business principles and business practices.

Business principles are defined as the characteristics common to organizations

of similar purpose and structure, such as human resources, finance, and

information technology functions. Business practices or processes vary based on

what an organization does and the size of that organization.

Be able to identify office productivity, business analysis, and

communication tools and technology. Office productivity tools are used to

store, capture, dissect, manipulate, organize, and distribute information.

Business analysis applications consist of more sophisticated requirements

development tools that are used to develop, validate, and implement formal

424

models, as well as build/manage requirements documentation. Communication

tools and technology help connect team members near and far with shared

applications or easily accessible communication options.

Be able to break down each of the high-level areas of underlying

competencies into their pieces and parts. Your exam questions on the

underlying competencies may drill down into the more detailed pieces and parts

of each competency. Make sure you are familiar with each of them.

Analytical thinking and problem-solving skills consist of creative thinking,

decision making, learning, problem solving, and systems thinking.

Behavioral characteristics include ethics, personal accountability,

trustworthiness, organization and time management, and adaptability.

Business knowledge consists of business acumen, industry knowledge,

organization knowledge, solution knowledge, and methodology knowledge.

Tools and technology is composed of office productivity, business analysis,

and communication tools and technology.

Interaction skills consist of facilitation, leadership and influencing,

teamwork, negotiation and conflict resolution, and teaching.

Communication skills are composed of verbal communication, nonverbal

communication, written communication, and listening.

425

Key Terms

You have just finished stepping through the contents of the “Underlying

Competencies” section from the BABOK

Guide. The skills and information in

this chapter are used by the tasks in the six knowledge areas. They are the

foundation that allows you to do your job wisely and well.

Use the skills and information found in this chapter as the basis for evaluating

and improving your underlying competencies in the business analysis realm.

You will need to know this section in order to be successful on the CBAP

CCBA

™

exams. Although there are no specific questions on this specific section,

questions about the underlying competencies can be found throughout your

exam as part of the six task- and technique-focused knowledge areas. The

underlying competencies include:

Analytical thinking and problem solving

Behavioral characteristics

Business knowledge

Interaction skills

Communication skills

A number of new key words in Chapter 8 are related to the underlying

competencies of effective business analysts. Here is a list of some of the key

terms that you encountered in this chapter:

alternatives identification

auditory learning style

business best practices

business practices

business principles

decision making

kinesthetic (tactile) learning style

methodology knowledge

organization knowledge

politics

power

problem definition

solution knowledge

sunk cost fallacy

systems thinking

426

Tuckman model

underlying competencies

visual learning style

427

Review Questions

1. Business ____________ are those characteristics that are common to all

organizations with a similar purpose and structure, whether or not they are

in the same industry.

A. Processes

B. Principles

C. Practices

D. Rules

2. You have strong political ties with your stakeholders from previous work in

the organization, enabling you to get things done. Which underlying

competency will these previous relationships enhance most for your current

assignment?

A. Facilitation

B. Negotiation

C. Leadership

D. Influencing

3. You understand the existing business models, structure, business unit

relationships, and people. This is an example of what type of knowledge?

A. Organization

B. Industry

C. Business

D. Strategic

4. You are deciding between three solution options early in the project life

cycle. Your stakeholders have trouble visualizing what these solutions

contain without graphical models to support the discussions. What type of

teaching method would enhance their learning?

A. Kinesthetic

B. Auditory

C. Tactile

D. Visual

5. What four stages of team development (in the order they are experienced)

would you expect your new business analysis team to go through?

A. Collecting, understanding, realization, working

B. Norming, storming, forming, performing

C. Forming, storming, norming, performing

428

D. Forming, norming, storming, performing

6. Confrontation as a method of conflict resolution is best for achieving a

____________-____________ solution.

A. Win-Win

B. Win-Lose

C. Lose-lose

D. Lose-Win

7. The process of gaining knowledge or skills is also known as:

A. Learning

B. Synthesis

C. Experience

D. Feedback

8. You are able to effectively manage your time by clearly defining goals and

expectations and prioritizing your work efforts. These abilities illustrate your

skills in:

A. Information retrieval

B. Politics and power

C. Time management

D. Analytical thinking

9. You are a business analyst measuring alternatives against objectives and

identifying trade-offs to determine which possible solution is best. You are

most likely engaged in what activity?

A. Problem solving

B. Systems thinking

C. Creative thinking

D. Decision making

10. Your team needs a low-cost tool that supports rapid drawing and

documentation of models. What type of tool should they choose?

A. Requirements tool

B. Modelling tool

C. Diagramming tool

D. Presentation tool

11. Knowledge management and collaboration tools that may be used to capture

and distribute knowledge throughout an organization include:

A. Discussion forums, word processors, and spreadsheets

B. Document repositories, wikis, and discussion forums

429

C. Presentation software, wikis, and other web-based tools

D. Email, instant messaging, and document repositories

12. You are focusing the business analysis team on examining the premises,

assumptions, observations, and expectations of its team members. What

type of conflicts are you most likely addressing?

A. Interaction

B. Emotional

C. Cognitive

D. External

13. You are developing a vision of a desired future state toward which people can

be motivated to work. After it is developed, you will encourage people to

work toward that future state. What business analysis competency are you

exhibiting?

A. Influencing

B. Leadership

C. Interaction

D. Trustworthiness

14. The business analysis team has been working hard to meet tight deadlines

on their project. The project manager offers them a bonus and some time off

if they can meet their deadlines. Which motivational theory best describes

what the project manager just did?

A. Expectancy theory

B. Herzberg’s hygiene theory

C. Achievement theory

D. Maslow’s hierarchy of needs

15. Which of the following capabilities is not part of your analytical thinking and

problem-solving skills?

A. Decision making

B. Teaching

C. Systems thinking

D. Learning

16. Effective problem solving consists of what three elements?

A. Alternative identification, facilitated discussion, and decision making

B. Problem definition, creative thinking, and decision making

C. Creative thinking, systems thinking, and problem definition

D. Problem definition, alternatives identification, and decision making

430

17. During an elicitation interview, you find yourself paraphrasing statements to

the speaker to reinforce that you understand what is being said. What skill

are you applying?

A. Facilitation

B. Influencing

C. Active listening

D. Learning

18. Your boss tells you that you should motivate your people by threatening

them with additional weekend work if project deadlines are not met. What

motivation theory is being suggested to you?

A. Achievement

B. Theory X

C. Theory Y

D. Expectancy

19. What method of conflict resolution offers the highest likelihood of reaching a

permanent solution?

A. Confrontation

B. Smoothing

C. Compromise

D. Withdrawal

20. The business analysis team members are jockeying for status within the

group. This is a symptom found in which stage of team development

according to the Tuckman model?

A. Performing

B. Forming

C. Storming

D. Norming

431

Chapter 9

Five Perspectives on Business Analysis

CBAP

/CCBA™ EXAM TOPICS COVERED IN THIS CHAPTER:

Describe the five perspectives on business analysis.

Elaborate the approaches used with each perspective.

Define the techniques recommended for each perspective.

Explore the knowledge area impacts of each perspective.

Recognize the underlying business analysis competencies for

each perspective

This chapter steps through the five high-level perspectives on

business analysis from the BABOK

Guide. It takes a look at what it means to

be a business analyst and how to successfully perform business analysis work on

different types of projects and from differing points of view. This content aligns

with the content in Chapter 11 of the BABOK

Guide.

Remember, the set of generally accepted best practices defined by the BABOK

Guide provides a business analysis framework defining areas of knowledge,

associated activities and tasks, and the skills required to perform them. The

scope of this standard covers pre-project activities, the full project life cycle, and

the final product’s operational life.

Business analysts find themselves working on many types of projects. The

BABOK

Guide defines five common points of view or perspectives for business

analysis work. Your initiatives may have one or more of these perspectives in

play. For example, you may be performing business analysis work on a project

that has an information technology component being developed using an agile

approach.

Exam Spotlight

At the time of publication, it was not decided if or how this content would

appear on the exam.

432

The five perspectives on business analysis equate to the common types of

projects business analysts find themselves working on in their organizations.

Recognizing the perspective or perspectives you are working in will help you

focus on the right business analysis tasks and techniques. The five common

perspectives are:

Agile

Business Intelligence

Information Technology (IT)

Business Architecture

Business Process Management

Each perspective impacts how you use the knowledge area tasks and techniques.

Remember, different types of initiatives facilitate different types of changes to

the business. Make sure you have the right people, the right methods, and the

right approach to define what has to be done. Let’s take a look at each

perspective in greater detail.

433

The Agile Perspective

Agile initiatives are characterized by constant change. “Flexible and adaptable”

is the battle cry for business analysts involved in agile initiatives. They find

themselves constantly reassessing, adapting, and adjusting their business

analysis efforts in order to respond to a rapid rate of change.

According to the BABOK

Guide, “agile business analysis ensures

that information is available to the agile team at the right level of detail at

the right time.” Basically, you are performing “just-in-time” business

analysis work.

Being a business analyst on an agile team requires constant communication,

facilitation, and negotiation. Business analysts help the agile team define the

business need they are trying to satisfy and decide the right thing to do to satisfy

that business need.

Change Scope

When working on a proposed change using agile methods, business analysts

work closely with the business sponsor of the initiative to define how the

proposed product or outcome aligns with the organization’s objectives.

Requirements are developed through ongoing exploration and analysis of

business needs over time.

Once the high-level product is defined, the business analyst works with key

stakeholders to decompose that “big picture” into a list of prioritized work

items. Agile teams deliver small, incremental changes and commit to prioritize

work items for a single iteration at a time. Iteration in an agile environment is

an agreed-upon period of work time.

Most agile approaches are iterative in nature. However, not all

iterative approaches are agile. There are agile approaches that are not

iterative, such as the kanban method. Kanban is a “just-in-time” approach

to getting work completed by matching the amount of work in progress to

the team’s work capacity. A kanban team is focused only on the work that is

actively in progress. Once the team completes a work item, they move to the

next work item off the top of the backlog list. As long as the most important

work items are at the top of the backlog list, the kanban team is delivering

maximum value to the business.

434

There are five elements to consider as part of the agile perspective and the scope

of a proposed change. Let’s step through each of those elements now in greater

detail:

Breadth of Change The most common use of agile methods is in software

development projects, although agile is being applied to process engineering

and business improvement projects as well. Agile initiatives may focus on a

single area of the business or span multiple areas across the organization.

Adopting agile principles requires an agile mind-set, a focus on continuous

improvement, ongoing changes in behavior, and continual progress.

Depth of Change Agile initiatives are often part of a larger program or project.

As mentioned previously, the agile work stream frequently focuses on software

development. Agile methods can be successfully applied in initiatives where

there is a clear commitment from the customer and engagement by the SMEs.

They also work well when the business needs are complex, complicated,

changing, unknown, and still emerging over time.

Value and Solutions Delivered Agile approaches focus on delivering value

early in a project. Ongoing feedback and review of the work performed involves

and engages stakeholders from the beginning of the effort. The business analyst

must build rapport and trust between the agile team and the stakeholders to

facilitate this collaboration and communication.

Delivery Approach Agile approaches focus on interacting with people,

transparent communications, and ongoing delivery of value. There are many

agile approaches that a business analyst can use. I recommend using The Agile

Extension of the BABOK

Guide to learn about the many agile approaches to

business analysis in more detail.

Major Assumptions There are a number of assumptions that work well in

agile projects. Here is a quick list for you:

Changing requirements are welcome at any time.

A business problem can be reduced to a set of needs that can be met.

Customers and SMEs are engaged and empowered.

Team members do not change and can perform multiple roles within the

team if required.

Multidisciplinary and co-located teams are preferred.

Team members have the continuous improvement mind-set, are

empowered, and can organize themselves.

Business Analysis Scope

Now let’s take a look at the specific elements of business analysis work as part of

the agile perspective. There are four elements to consider. We will step through

each of the four elements now in greater detail.

Change Sponsor The BABOK

Guide stresses the importance of a project

sponsor who is actively involved with the project. The sponsor should be

435

familiar with the agile mind-set and approach to getting work done. The sponsor

also should be able to deal with constant stakeholder feedback and trade-off

decision making. Make sure your agile sponsor accepts the use of adaptive

planning versus predictive planning and supports using a fixed period of time

for a work cycle.

Change Targets and Agents Agile projects or initiatives require intensive

collaboration, frequent communication, and incremental delivery of value to be

successful. The typical agile project team is small in size. There are a number of

roles that need to be addressed as part of an agile project. Table 9.1 describes

the agile-specific roles and responsibilities.

TABLE 9.1 Agile roles and responsibilities

Role Responsibilities

Agile team leader Facilitator of the team’s work who delegates planning,

scheduling, and prioritization activities to the team

Customer

representative or

product owner

Ensures the change addresses the requirements for

which it has been mandated

Team members Specialists or domain experts performing the work or

providing support to the team as needed

External stakeholders Parties interested in the outcome of the project who

play a supporting role

Business Analyst Position Business analysts on agile teams may perform

additional roles on the team in addition to business analysis work. Business

analysts may work on an agile team full- or part-time, be a customer

representative or product owner, or be several team members performing the

business analysis work.

Business Analysis Outcomes Business analysts on agile projects facilitate

communication and collaboration between the team and the stakeholders. They

make sure the project’s vision and direction align with the business need and

the organization’s goals. Business analysts help define strategic project

completion criteria as well as acceptance criteria. They also make sure that the

“just-in-time” and “just-enough” documentation for the project is complete.

Approaches and Techniques

There are many agile approaches to projects and initiatives. Business analysis is

a component in all of the approaches, although few of the approaches formally

define the business analyst role. Table 9.2 summarizes the agile approaches.

TABLE 9.2 Summaries of agile approaches

Approach Description

Crystal Clear Methodology defined by hardness and color. Hardness is

business criticality or potential for causing harm. Color is

436

heaviness of the project such as number of people and risk

elements.

Disciplined

Agile Delivery

(DAD)

Decision process framework using ideas from many agile

approaches. Customized by the team to support a project from

initiation through delivery

Dynamic

Systems

Development

Method

(DSDM)

Framework fixing cost, time, and quality at the beginning with

contingency managed by varying the features to be delivered

Evolutionary

Project

Management

(Evo)

Develops and delivers a system incrementally by quantifying

value for multiple stakeholders and planning increments based

on delivery of that measured value

Extreme

Programming

(XP)

Takes software engineering to the extreme by focusing on

technical development processes. Uses pair programming, test-

driven development, and other craftsmanship approaches

Feature

Driven

Development

(FDD)

Focuses on client-driven functionality or features to develop

working software

Kanban Performs work as a continuous flow of activities by working on

one item at a time. Work begins on a new item when it is

required to maintain flow downstream and after the previous

item is complete

Scaled Agile

Framework

(SAFe®)

Implements agile practices at the enterprise level by

highlighting individual roles, teams, activities, and artifacts

Scrum Uses empirical process control to perform work in a series of

fixed length iterations, or sprints. Each sprint produced

working software that could be delivered to the customer.

There are a number of techniques used in agile projects. Some of the techniques

are found in the BABOK

Guide, while others are agile-specific and can found

in the Agile Extension to the BABOK

Guide. Table 9.3 summarizes how each

technique can be used in an agile project environment.

TABLE 9.3 Agile business analysis techniques

Approach Description

Behavior

Driven

Development

(BDD)

Enhancing communication between stakeholders and team

members by expressing product needs as concrete examples

Kano Analysis Understanding which product features will help drive

437

customer satisfaction

Lightweight

Documentation

Producing documentation that fulfills an impending need and

does not create unnecessary overhead

MoSCoW

Prioritization

Used to prioritize stories in incremental and iterative

approaches. MoSCoW stands for must have, should have,

could have, and won’t have.

Personas Fictional characters or archetypes showing how typical users

interact with a product

Planning

Workshop

Collaborative workshop allowing an agile team to determine

what value can be delivered over a time period

Purpose

Alignment

Model

Used to assess ideas in the context of the customer and value

Real Options Helps people know when to make decisions rather than how to

make those decisions

Relative

Estimation

Team estimation using story points (representing relative

complexity of a user story) or ideal days (representing the

amount of total effort a story would take to develop)

Retrospectives Held after each agile iteration to focus on continuous

improvement of the teamwork process. Similar to the Lesson

Learned technique

Story

Decomposition

Represents product requirements by deriving them from

business objectives and defining those requirements at an

appropriate level of detail

Story Mapping Visual and physical view of the sequence of activities

supported by a solution

Storyboarding Visual and textual representation of the sequence of activities

showing user interaction with a system or business

Value Stream

Mapping

Complete, fact-based, time-series representation of the activity

stream required to deliver a product/service to the customer

Underlying Competencies

Agile business analysts are experts at communication and collaboration with the

project team and the stakeholders. According to the BABOK

Guide, the

required competencies for an agile business analyst include the following:

Communication and collaboration

Patience and tolerance

Flexibility and adaptability

Ability to handle change

Ability to recognize business value

438

Continuous improvement

Knowledge Area Impacts

Knowledge area tasks and techniques in the BABOK

Guide can be modified for

agile projects before being applied as part of your business analysis work.

Additional agile-specific techniques may also be applied to the tasks and their

elements within a knowledge area in addition to or in place of the techniques

used on more traditional projects. As a reminder, these are the knowledge areas:

Strategy Analysis

Business Analysis Planning and Monitoring

Elicitation and Collaboration

Requirements Analysis and Design Definition

Requirements Life Cycle Management

Solution Evaluation

There are numerous BABOK

Guide techniques and Agile Extension to the

BABOK

Guide techniques that are used during business analysis activities on

agile projects. Table 9.4 contains a mapping of techniques by knowledge area for

agile projects.

TABLE 9.4 Mapping BABOK

Guide techniques to knowledge areas for agile

projects

Technique BAPM EC RLCM SA RADD SE

Acceptance and evaluation criteria X X X X

Backlog management X X X X

Brainstorming X X

Business capability analysis X X X

Business rules analysis X

Collaborative games X X X X X

Concept modelling X X X

Estimation X

Interface analysis X X

Metrics and key performance indicators

(KPIs)

X X X

Mind mapping X X

Nonfunctional requirements analysis X X X

Prioritization X X X

Process analysis X X

Process modelling X X

439

Prototyping X X

Reviews X X X

Scope modelling X X X X

Stakeholder list, map, or personas X X X

Use cases and scenarios X X X

User Stories X X X X

Workshops X X X X X X

Table 9.5 contains a second mapping of techniques from the Agile Extension to

the BABOK

Guide by knowledge area for agile projects.

TABLE 9.5 Mapping Agile Extension to the BABOK

Guide techniques to

knowledge areas

Agile Extension Technique BAPM EC RLCM SA RADD SE

Behavior Driven Development X X

Kano Analysis X X X

Lightweight Documentation X X X

MoSCoW Prioritization X X X

Personas X X X X

Purpose Alignment Model X X

Real Options X X

Relative Estimation X

Retrospective (Lesson Learned) X

Story Decomposition X X

Story Elaboration X

Story Mapping X X X

Storyboarding X X

Value Stream Analysis X X X

Use these two tables as you navigate and learn about the agile variations for

each knowledge area. Make sure you know which techniques might apply to

specific knowledge areas and activities on your agile projects.

Let’s step through each knowledge area and look at what might need to be done

differently for agile projects:

Business Analysis Planning and Monitoring On agile projects, detailed

business analysis planning tends to be adaptive, deferring the planning until

work on an activity is ready to begin. An initial business analysis activity plan is

developed at the beginning of the project. This high-level plan is updated at the

start of each development cycle. Expect to see informal communication on agile

projects. Business analysis deliverables are often verbal interactions versus

440

written documents.

Elicitation and Collaboration Elicitation and Collaboration occurs across

the life cycle of agile projects. Typically, business analysts elicit the high-level

solution scope early in the project and build a milestone plan for product

delivery. Moving forward, each agile cycle involves eliciting details and building

a list of backlog items to be developed in that specific cycle.

The intent of elicitation activities on agile projects is to generate

just enough detail to complete the work and meet the goals for the project.

Requirements Life Cycle Management During agile projects, the scope of

the effort is defined in more detail as the project progresses and work is being

done. Often, business analysts discover that the project scope changes over time

as the needs and designs evolve. Be sure to prioritize the features being

developed as this drives the work that is done in a particular agile cycle. Solution

validation takes place at the end of each cycle and replaces a formal

requirements approval process.

Strategy Analysis Similar to Elicitation and Collaboration, Strategy Analysis

activities are ongoing across an agile project. Activities in this knowledge area

are used to define the product’s vision and build the development roadmap.

Risk analysis helps the business analyst address uncertainty about the needs

and the solution scope over time. Adapting the project to changes in the

organization’s goals is an expected component of an agile project.

Requirements Analysis and Design Definition Progressive elaboration

combined with “just-in-time” analysis and design is the key to a successful agile

project. Analysis is done prior to an iteration to estimate the planned work.

Additional analysis is done during the iteration to give the team what they need

to get the work done.

Solution Evaluation Agile projects build a solution in an incremental fashion,

iteration by iteration. Stakeholders evaluate the solution as it progresses

through its iterations to ensure the end result will meet stakeholder needs and

expectations. The business analyst facilitates these reviews.

Remember that all these knowledge area tasks and techniques can be modified

for agile projects before being used. Let’s move on and take a look at the next

perspective that business analysts need to be familiar with: looking at business

analysis work on a project from the business intelligence point of view.

441

The Business Intelligence Perspective

Business intelligence initiatives focus on transforming, integrating, and

enhancing data. Value-added information is the goal for business analysts

involved in business intelligence initiatives. To transform data into value-added

information, you must source, integrate, and enhance the data before you can

use it to support business decision making. I think of business intelligence as a

three-pronged approach relative to the data on hand: reporting, integration, and

analysis.

Business analysts often find themselves using data-centric systems and tools to

support the acquisition, storage, and analysis of information. Business

intelligence project teams frequently use technologies and tools to deliver

information that helps their stakeholders manage strategic, tactical, and

operational performance.

Change Scope

When working on a proposed change as part of a business intelligence solution,

business analysts work closely with the business sponsor of the initiative to

define how the proposed product or outcome aligns with the organization’s

objectives. Requirements are defined to address information and decision-

making needs at the strategic, tactical, and process levels within the

organization.

The enterprise-wide view of a business intelligence solution is often a data

warehouse with operational data stores, data marts, unstructured data, and

analytical sandboxes. Infrastructure services are often developed to support a

business intelligence solution, such as data governance and metadata

management.

There are five elements to consider as part of the business intelligence

perspective and the scope of a proposed change. Let’s step through each of those

elements now in greater detail:

Breadth of Change Business intelligence systems must consistently define

and use information across the organization. Consistency is achieved by

establishing a “single point of truth” for diverse business data. This diverse

business data can come from multiple data sources internal and external to the

organization.

Depth of Change Business intelligence focuses on providing information that

supports making decisions at strategic, tactical, and operational process levels

within the organization. In addition to the information required for effective

decision making, requirements are also developed for

communication/reporting, information analytics, and data integration.

442

Strategic decisions are made at the executive level within the

organization. Tactical decisions are made at the management level. Process

decisions are made at the operational level.

Value and Solutions Delivered If your business intelligence initiative is not

targeting providing folks with timely and accurate data, then the initiative is off

target. People need access to high-value, actionable information to make the

right business decisions at the right time. This decision making takes place at all

levels in the organization: strategic, tactical, and operational. Oftentimes,

performance improvements resulting from these decisions are realized as

increased revenues and decreased costs.

Delivery Approach There are a number of ways to deliver a business

intelligence solution in an organization. The solution architecture should

support the multiple levels of decision making and the information that is

required at each level. This allows the development team to progressively

introduce the solution by organizational level or by functional area. Additional

data sources may also be phased in to the solution over time. Organizations can

“build or buy” a business intelligence solution that works for them.

Major Assumptions There are a number of assumptions that work well in

business intelligence projects. Here is a quick list for you:

Existing business processes and systems can provide definable and

predictable source data.

The cross-functional data infrastructure has not been precluded by the

organization.

The organization recognizes that process reengineering and change

management is needed to realize value from a business intelligence solution.

Business Analysis Scope

Now let’s take a look at the specific elements of business analysis work as part of

the business intelligence perspective. There are four elements to consider. We

will step through each of the four elements now in greater detail:

Change Sponsor Every business intelligence initiative needs a change sponsor

to champion the effort and clear the path for getting work done. Choose a

sponsor with the highest-level organizational role you can when selecting your

change sponsor. The more power and authority your sponsor has, the more

consistent and cohesive your usage of data assets in the business intelligence

solution will be.

Change Targets Business intelligence solutions support making good business

decisions in a timely fashion. These decisions are made at different levels in the

organization and focus on different aspects of the business. Better reporting,

monitoring, and predictive modelling of performance-based data can help

443

people and processes make even better decisions over time.

Business Analyst Position On business intelligence projects, the business

analyst liaises between the business intelligence stakeholders and the

development team. Their focus is on eliciting, analyzing, and specifying the

business needs for the solution. Many business analysts participate in the more

technical business intelligence work, such as enterprise data modelling, decision

modelling, dashboard design, and ad hoc query design.

Business analysts on business intelligence projects often take one

or more of the following roles:

Defining business requirements and assessing potential solutions

Understanding and analyzing data mining, predictive analysis, and

developing visualizations

Defining source systems data to be used for analytical purposes

Defining source and target data structures in a logical data model

Business Analysis Outcomes Business analysts working on business

intelligence projects focus on the major components of the solution architecture.

Components include the specification of business systems to be changed as well

as the collection of data from source systems. The integration of divergent data

sources must also be addressed. Once the solution and its data are in place, the

business analyst makes sure the stakeholders have access to the information

that they need. Table 9.6 summarizes the major business analysis outcomes on

this project type.

TABLE 9.6 Business analysis outcomes on business intelligence projects

Outcome Description

Business

process

coverage

Defines the high-level scope of the change, how information

will be used, and the value it provides

Decision

models

Identifies information requirements of each business decision

and specifies the business rules logic

Source logical

data model and

data dictionary

Providing standard definitions of required data in each source

system and the business rules applied to that data

Source data

quality

assessment

Evaluating completeness, validity, and reliability of source

data

Target logical

data model and

data dictionary

Providing standard definitions of data elements and integrity

rules in the target, or new, system

444

Transformation

rules

Mapping source and target data elements to specify

requirements for decoding/encoding of values in the

transformation process

Business

analytics

requirements

Defining information and communication requirements for

decision support outputs (such as reports, queries, and

analytics) including data selection and presentation rules

Solution

architecture

Giving a high-level design view of how decision support

requirements for each functional area map to the business

intelligence framework, such as where data is stored and

how/when it will be extracted

Approaches and Techniques

Business intelligence projects do not have any formal methodologies that impact

business analysis work. However, there are many informal and overlapping

approaches you can take for business intelligence projects and initiatives.

Business analysis is a component in all business intelligence projects, although

many of the approaches take an informal and flexible view of the business

analyst role. Table 9.7 lists the approaches, brief descriptions of each approach,

and the business analyst’s focus in each area.

TABLE 9.7 Summary of business intelligence approaches

Approach Description BA Focus Is On…

Descriptive

analytics

Using historical data to

understand and analyze past

business performance

Information and

communication

requirements for

standard/ad hoc reporting,

queries, and dashboards

Predictive

analytics

Applying statistical analysis

methods to historical data to

identify patterns, understand

relationships/trends, and predict

future events

Information requirements

for pattern recognition

through data mining,

predictive modelling,

forecasting, and condition-

driven alerts

Prescriptive

analytics

Identifying decisions and

initiating actions to improve

business performance using

statistical optimization and

simulation techniques

The business objectives,

constraints criteria, and

business rules underpinning

the decision-making process

Supply-

driven

Improving existing information

systems by defining what data is

available. For a given cost, what

value can we deliver?

The technical goals of

improving the existing

information delivery systems

and databases and exploring

insights to be gained from

consolidated data

445

Demand-

driven

Providing information to improve

decision making by identifying the

needed information outputs and

tracing it back to the data source.

For a given value, what cost do

we incur?

The business goals of

providing the appropriate

information to improve

decision making that is not

based on existing database

structures or reporting

Structured

data

Traditional data warehouse

solutions consolidating structured

data from operational systems.

Using rules-driven templates to

ensure data integrity

Data models, data

dictionaries, and business

rules defining information

requirements and

capabilities

Unstructured

data

Using semi-structured or

unstructured data with no

predefined structure, rules, or

relationships

Metadata definitions and

data matching algorithms to

define information

requirements and

capabilities

Let’s change direction and take a look at the skills and competencies a business

analyst should bring to the table when working on a business intelligence

project.

Underlying Competencies

Business analysts on business intelligence projects should possess good

communication skills and analytical competencies. These skills are essential

when you find yourself coordinating business information requirements with

business intelligence systems outcomes. Business analysts will find themselves

collaborating with and liaising between the technical project team and the

business stakeholders. According to the BABOK

Guide, the required

competencies for a business intelligence business analyst include knowledge

and experience in the following areas:

Business data and functional usage

Complex data structure analysis

Business processes, including KPIs and metrics

Decision modelling

Data analysis techniques such as basic statistics, data profiling, and pivoting

Data warehouse and business intelligence concepts and architecture

Logical and physical data models

Extract, Transform, Load (ETL) best practices

Business intelligence reporting tools

Knowledge Area Impacts

446

Knowledge area tasks and techniques in the BABOK

Guide may be modified

for business intelligence projects before being applied as part of your business

analysis work. Additional business intelligence–specific techniques may also be

applied to the tasks and their elements within a knowledge area in addition to or

in place of the techniques used on more traditional projects.

There are numerous BABOK

Guide techniques that are used during business

analysis activities on business intelligence projects. Table 9.8 contains a

mapping of these techniques by knowledge area for business intelligence

projects.

TABLE 9.8 Mapping BABOK® Guide techniques to knowledge areas for

business intelligence projects

Technique BAPM EC RLCM SA RADD SE

Acceptance and evaluation criteria X X X

Backlog management X

Balanced scorecard X X X

Benchmarking and market analysis X

Brainstorming X X X

Business rules analysis X X X

Data dictionary X

Data flow diagrams X X X

Data modelling X X X

Decision analysis X X X

Decision modelling X X X

Document analysis X X X

Estimation X X X

Focus groups X X X

Functional decomposition X X X X X

Glossary X X X X

Interface analysis X X

Interviews X X X X

Item tracking X X X X

Metrics and KPIS X X X

Nonfunctional requirements analysis X X

Observation X X X

Organizational modelling X X X X X

Prioritization X X X X

Process modelling X X X

447

Prototyping X X

Reviews X X X

Risk analysis and management X X X

Roles and permissions matrix X X

Root-cause analysis X X

Scope modelling X X

Sequence diagrams X

Stakeholder list, map, or personas X X X X X X

State modelling X

Survey or questionnaire X X X

SWOT analysis X X

Use cases and scenarios X X X

User stories X X

Vendor assessment X X

Workshops X X X

Use this table as you navigate and learn about the variations on each knowledge

area. Make sure you know which techniques might apply to specific knowledge

areas and activities on your projects. Let’s step through each knowledge area

and look at what might need to be done differently on your business intelligence

projects.

Business Analysis Planning and Monitoring When planning a business

intelligence project, business analysts must discover how knowledgeable their

stakeholders are regarding this type of initiative. Information and

communication requirements need to be expressed in the business intelligence

context. Interpreting those requirements for the business intelligence technical

specialists can be challenging for inexperienced business analysts. External

business intelligence solutions typically provide frameworks, tools, and

techniques to assist the business analyst in requirements development and

modelling.

According to the BABOK

Guide, business intelligence solutions

that integrate multiple data sources result in many stakeholders with

overlapping information requirements. Business analysts must analyze and

synthesize these individual requirements into a complete and cohesive set of

requirements that have no conflicts or redundancies.

Elicitation and Collaboration Business analysts often find themselves using

specialized documentation tools and techniques to elicit requirements from

their business and technical stakeholders. These stakeholders often have only

448

partial knowledge and expertise relative to the business decisions that need

support. This partial knowledge extends into the detail of the data elements

supporting the business decisions; how data is sourced, transformed, and

integrated; and how this required information should be presented.

Business intelligence projects are often cross-functional in nature. Commercial

off-the-shelf business intelligence packages offer business analysts prototyping

tools to elicit and clarify requirements with stakeholders. Helpful elicitation

techniques include interviews, workshops, data models, data dictionaries,

decision models, and process models.

Requirements Life Cycle Management Most business intelligence

solutions require infrastructure capabilities as part of the solution. This

technology dependency within the solution can impact how and in what order

solution components are developed and delivered. Keeping solution delivery

focused on the prioritized business needs can be challenging. Implementing sets

of related requirements simultaneously might address some or all of these

concerns.

Strategy Analysis During Strategy Analysis, high-level conceptual data

models are often used to map the current state of corporate information,

identify information “silos,” and assess related problems and opportunities.

Organizational models are also helpful on business intelligence projects. They

allow the business analyst to see the current data management infrastructure.

There are four high-level data models commonly used to model a future state

business intelligence strategy. They are listed and described for you in Table 9.9.

TABLE 9.9 Four common future state data models

Name Description

Logical

data

models

Provides a static solution architecture view, representing the

information portal connecting the operational data inputs with the

delivery of business information outputs

Data

flow

diagrams

Maps the dynamic aspects of the solution by showing data in motion

and identifies architectural constructs such as latency and

accessibility

Decision

models

Defines how business decisions are made and how data analytics are

used to meet the needs of the decisions and the decision makers

Physical

data

models

Shows the implementation environment including the data

warehouse and the data marts

The desired future state can also be mapped for data storage, conveyance, and

transformation using high-level models. This future state can be implemented

incrementally across different functional areas of the business. This allows

business analysts to define their change strategy based on business needs and

priorities, operational impacts, and usability of existing infrastructure

components.

Requirements Analysis and Design Definition Business analysts use

449

data-oriented modelling techniques when specifying the data requirements for a

business intelligence solution. Techniques include data modelling, data

dictionaries, decision modelling, and business rules analysis. The first step is

modelling the existing system’s data so you can define availability, identify

redundancies, and discover any data quality issues. Sometimes this requires

reverse engineering if no documentation exists.

The future state is typically modelled using data flow diagrams that show how

source information is structured in the proposed solution. Be sure to analyze

existing reports to see if they can be replaced or repaired. Including ad hoc

query and data mining capabilities in a business intelligence solution makes the

solution more flexible and usable over time.

Solution Evaluation Many business intelligence solutions are implemented

and then not used to the full extent of their capabilities. Many stakeholders use

the solution the “old way” and don’t even try the new capabilities that are

present. Business analysts need to be aware of this underutilization and

encourage stakeholders to use the solution to the fullest. Training and a good set

of user documentation may be helpful in this regard.

Remember that all of these knowledge area tasks and techniques can be

modified for business intelligence projects before being used. Let’s move on and

take a look at the next perspective that business analysts need to be familiar

with: looking at business analysis work on a project from the information

technology (IT) point of view.

450

The Information Technology Perspective

Working as a business analyst in the information technology realm is never

boring. So many of our projects these days contain at least one IT system and its

associated software applications and infrastructure. As a business analyst

working on an IT project, you will be faced with a wide range of technology-

related projects. These projects can range from “bug fixes” to application

enhancements to adding new capabilities to implementing an entirely new IT

infrastructure.

This section takes a look at the nonagile aspect of IT projects and initiatives.

Business analysts on IT projects find themselves acting as translators between

the business stakeholders and the technical project teams. Fostering

collaboration and communication between these two groups is essential for

project success and acceptance of the resulting solution.

Exam Spotlight

Watch out when using the term design on your exam. On IT projects, the

term is traditionally used to denote technical design work performed by

developers or architects after the requirements are developed by the

business analysts. To be clear what you are working on as a business

analyst, you may want to use the term solution requirements or solution

design instead of design. Your exam questions may also use these terms to

maintain this separation between the business and the technical aspects of

an IT project.

Business analysts working on IT projects do their work while keeping an eye on

three factors. The first factor to watch is the solution’s impact, which includes

the value and risk of the solution to the business. The second factor consists of

the maturity, formality, and flexibility of your organization’s change processes.

The third factor is the scope of the proposed change that is being addressed.

Change Scope

There are many ways to initiate or trigger an IT project in an organization. The

BABOK

Guide lists five common ways IT projects get started:

Create a new organizational capability.

Achieve an organizational objective by enhancing an existing capability.

Facilitate an operational improvement.

Maintain an existing IT system.

Repair a broken IT system.

451

There are five elements to consider as part of the IT perspective and the scope of

a proposed change. Let’s step through each of those elements now in greater

detail:

Breadth of Change IT projects come in many shapes and sizes. IT projects

can address one system or many interacting systems. Systems may be developed

or maintained in-house or by a third-party vendor external to the organization.

Projects may focus on just hardware and software or reach across the enterprise

and impact how things get done. Be aware of this wide range of values when you

are working as a business analyst, as the context of the proposed change has an

impact on your work. There are five questions to ask early on about your

business analysis activities on an IT project:

What happens to the business if this system shuts down?

What happens to the business if system performance degrades?

What business capabilities and processes depend on this system?

Who contributes to these business capabilities and processes?

Who uses these business capabilities and processes?

Depth of Change Requirements for IT projects can be very detailed.

Sometimes those details dip into the technical side of things or cross many areas

and functions of an organization. Business analysts find themselves defining

interfaces between IT systems, discovering how their organization works, and

finding out just how the proposed change and an IT solution supports the

business. All of these things should allow you to define the value your solution

will bring to the business and the capabilities it brings to its end users.

Value and Solutions Delivered Typically, IT systems are implemented to

add value to the organization. This value includes the support capabilities and

processes that will use the system. The IT functionality and effects of the system

should be measurable.

Changes to IT systems can increase value in many ways, including reducing

operating costs and decreasing wasted effort. They can target an increase in the

organization’s strategic alignment. Systems can be made more stable and

reliable. Manual processes can often be automated, and problems can be

repaired. Business capabilities can be supported and enhanced, or new

capabilities can be implemented.

Delivery Approach The size and complexity of your IT solution impacts how

much business analysis work needs to be done. Small enhancements can often

be completed quickly. A single business analyst can perform their work in a

short period of time as part of a small project such as this. In contrast, large IT

solution efforts may require a multirelease, multiphase project to get things

completed. These larger efforts may involve several business analysts over a

longer period of time.

Major Assumptions There are some assumptions that go along with the IT

perspective on projects. Remember that these projects are not agile projects.

Agile projects were covered earlier in this chapter.

452

Business capabilities and processes that use an IT system deliver value to the

organization.

Business analysts working from other perspectives can integrate their work

with the IT business analyst’s work.

IT systems changes are mostly driven by business needs, although some may

originate from the technical side of things.

Business Analysis Scope

Now let’s take a look at specific elements of business analysis work as part of the

IT perspective. There are four elements to consider. We will step through each

of the four elements now in greater detail:

Change Sponsor Every IT project or initiative needs a change sponsor. This

person may be sponsored by the business, by the IT department, or as

collaboration between the two. Since overall organizational strategy alignment

is still critical to project success, choose a sponsor who can champion the effort

with the business and clear the path for getting work done. Many organizations

have a program or project management office within their IT department that

selects, prioritizes, and manages their projects.

Change Targets IT solutions have a business and a technical impact within

the organization. The changes that are being made require the business analyst

to have a handle on all possible departments, processes, applications, and

functions that may be impacted in some way. You need to keep your eye on both

the big picture and the little details.

Business Analyst Position On IT projects, the business analyst liaises

between the business stakeholders and the technical development team. Their

focus is on eliciting, analyzing, and specifying the solution requirements for the

change. You find business analysts with a myriad of backgrounds working on IT

projects. Sometimes the business analyst is chosen for a specific skill set, while

other times they are chosen because they are available to perform the work.

Business analysts on IT projects may be IT business analysts, SMEs, software

users, systems analysts, business process owners, technical team members, or

from an external vendor.

Business Analysis Outcomes Business analysts working on IT projects focus

on the business processes impacted by the change as well as the data and

information collected by the system. The deliverables and work effort should be

planned in advance so you don’t miss anything. Use the project’s change

approach and any organizational guidelines to make sure all business analysis

deliverables and outcomes are accounted for.

The BABOK

Guide lists a comprehensive set of business analysis deliverables

that IT business analysts may be responsible for on their projects. Take a look

and see how many of these deliverables are required for your IT projects. They

include the following:

Defined, complete, testable, prioritized, and verified requirements

453

Analysis of alternatives

Business rules

Gap analysis

Functional decomposition

Use cases and scenarios and/or user stories

Interface analysis

Prototypes

Process analysis

Process models

State models

Decision models

Context models or scope models

Data models

Approaches and Techniques

Solution development methodologies on IT projects are either predictive or

adaptive. Predictive methodologies have structured processes that emphasize

planning and formal documentation. Each phase of a predictive project must be

completed before the next phase can begin. Adaptive processes are more

iterative and incremental in nature. They allow for rework and greater flexibility

across the project life cycle. Some organizations use a blend, or hybrid, of these

two solution development methodologies.

There are many IT methodologies that are used on IT projects and initiatives.

Business analysis is a component in all of the methods. Table 9.10 summarizes

some established IT methodologies.

TABLE 9.10 Summary of IT methodologies

Methodology Description

Homegrown or

organization

specific

Derived from components of other established

methodologies and used by the IT organization to govern

their IT initiatives and projects

Requirements

Engineering (RE)

Structured approach for requirements development and

management used in predictive, adaptive, and agile

environments

Structured

Systems Analysis

and Design

(SSADM)

Predictive development methodology focusing on

establishing logical models and separating requirements

from solutions during systems analysis and development

Unified Process

(UP)

Adaptive development approach where most of the

requirements development is performed in the inception

454

and elaboration phases

Underlying Competencies

IT business analysts are experts at influencing, facilitating, and negotiating with

the technical project team and the business stakeholders. Although technical

skills are not required, they may also be technically skilled at programming,

database creation, system/solution architecture creation, or software testing.

According to the BABOK

Guide, business analysts on IT projects

must understand and deliver the details required in the project

requirements to support a technical solution. They must also develop

requirements that are technically feasible for their organization.

Systems thinking is a crucial competency for business analysts on IT projects.

They need to be able to see both the “big picture” of the solution within the

framework of the enterprise as well as details of the specific need and the

resulting technical solution. Identifying impacts to people, processes, and

software at both levels helps the business analyst to identify and address risks

and deliver a successful outcome.

Knowledge Area Impacts

Knowledge area tasks and techniques in the BABOK

Guide may be modified

for IT projects before being applied as part of your business analysis work.

There are many BABOK

Guide techniques that are used during business

analysis activities on IT projects. Table 9.11 contains a mapping of techniques by

knowledge area for IT projects.

TABLE 9.11 Mapping BABOK

Guide techniques to knowledge areas for IT

projects

Technique BAPM EC RLCM SA RADD SE

Acceptance and evaluation criteria X X

Backlog management X

Brainstorming X

Business capability analysis X

Business rules analysis X

Collaborative games X

Data dictionary X

Data flow diagrams X

Data modelling X

455

Decision analysis X X X

Decision modelling X

Document analysis X X X

Estimation X X X

Focus groups X X

Functional decomposition X X X

Glossary X

Interface analysis X X

Interviews X X

Item tracking X X X X

Metrics and KPIS X X X

Nonfunctional requirements analysis X

Observation X X

Organizational modelling X X X

Prioritization X

Process analysis X

Process modelling X X X X

Prototyping X X

Reviews X

Risk analysis and management X

Roles and permissions matrix X X

Scope modelling X X X X

Sequence diagrams X X

Stakeholder list, map, or personas X X X

State modelling X

Survey or questionnaire X X

SWOT analysis X X

Use cases and scenarios X X

User stories X

Vendor assessment X X

Workshops X X

Please refer to and review this table as you navigate and learn about each

knowledge area. Make sure you know which techniques might apply to specific

knowledge areas and activities on your projects.

Let’s step through each knowledge area and look at what might need to be done

differently for IT projects:

456

Business Analysis Planning and Monitoring Use the business analysis

approach to identify the resources required for business analysis work on your

IT project. The approach also allows you to plan the effort and integrate the

business analysis work into the overall project plan. In many organizations, IT

projects have predefined business analysis tasks and deliverables. Typical tasks

target the interoperability of business processes, software systems and data, and

the impact a change may have across the board.

Business analysts on IT projects are often part of the software development

team. In addition to working with the team members and key internal

stakeholders, the business analyst may work with external vendors who are

providing all or part of a software solution.

Elicitation and Collaboration Eliciting business analysis information on IT

projects involves both the business and the technical stakeholders for the

project. Scheduling a workshop or group session with the technical and business

stakeholders can help identify additional solution impacts on technology as well

as on the business side of things. Effective business analysts facilitate

collaboration between the business and technical staff members on their

projects.

In addition to using the Elicitation and Collaboration techniques

defined in Chapter 10 of the BABOK

Guide, try using one or more of the

following elicitation methods on your IT project:

Investigation: Using organization process assets, market research,

competitive analysis, functional specifications and observation

Simulation: Using statistical modelling and mock-ups

Experimentation: Using proof of concept, prototypes, alpha- and

beta-releases, and A/B testing

Eliciting requirements on IT projects can require the business analyst to work

across organizational boundaries. This adds risk to the effort by potentially

causing communication breakdowns and rework. It is essential to keep your key

stakeholders engaged, informed, and active during elicitation.

Requirements Life Cycle Management IT projects can change

considerably across the project life cycle. Sometimes new functionality provided

by the solution impacts the business and technology in ways that were not

considered early on. These evolving requirements must be communicated to

stakeholders and agreed upon as the project progresses. IT business analysts

must pay attention to alignment, approval, change control, version control,

traceability, and the use of requirements life cycle management tools on their

projects.

Strategy Analysis IT organizations focus their strategy analysis efforts on

technologies, systems, business units, business processes, and business

457

strategies that can be impacted by a proposed change. This involves

understanding the current state of the systems and processes within the

organization, as well as the desired future state that is targeted by the proposed

change. Defining the gap between the current and future state allows the

business analyst to develop and explore possible solution options.

Business analysts must also assess the risks and uncertainties relative to the

change scope and desired future state. Risks and potential benefits should be

identified and defined. Parameters for variance in known processes and

operations should be established. There may also be external vendor risks

present. Don’t forget to consider the systems and any technical risks. Solution

scalability should be evaluated along with any additional process or system

changes that may be required.

Requirements Analysis and Design Definition Remember that the term

design in this knowledge area refers to the business analyst’s point of view

versus a technical design from the development team. Business analysts

consider models of processes, user interface layouts, and report definitions to be

designs that fall within the business analysis realm.

During analysis and design definition, business analysts elicit, define, and

analyze business and stakeholder requirements, as well as define stakeholder

needs and identify the value to be realized by the proposed change and resulting

solution. They also define, analyze, and model solution designs.

The resulting requirements are documented using words and pictures. The

documented requirements should contain enough detail to allow the business

stakeholders to verify and validate the requirements. The developers should be

able to build a technical design using the documented requirements, and the

testers should be able to build test cases to show the solution performs as it

should.

Solution Evaluation According to the BABOK

Guide, solution evaluation

activities focus on the “solution components and the value they provide.” On IT

projects, the business analyst needs to also include the interfaces between

systems and processes.

Software testing is an important component of solution evaluation work on IT

projects. Testing assures that the solution performs as defined and meets the

business needs as defined by the requirements. At a minimum, business

analysts are involved with user acceptance testing activities on IT projects.

Remember that all of these knowledge area tasks and techniques can be

modified for IT projects before being used. Let’s move on and take a look at the

next perspective that business analysts need to be familiar with: looking at

business analysis work on a project from the business architecture point of view.

458

The Business Architecture Perspective

Practicing business analysis in the context of business architecture focuses on

modelling and understanding the entire enterprise. Business architecture

provides architectural views and descriptions, or blueprints, of an organization.

These blueprints are used to align strategic objectives with tactical demands.

Blueprints and architectural models enable organizations to see the big picture

of the domain that is under analysis and how all of the pieces and parts fit

together.

Business architecture blueprints follow a set of specific architectural principles.

Table 9.12 summarizes these four principles.

TABLE 9.12 Summary of architectural principles

Principle Description

Scope Scope of business architecture is the larger business context of the

enterprise.

Separation

concerns

Separate what the business does from the different architectural

components (such as what, how, who, why).

Scenario

driven

Each business scenario requires a different set of blueprints with a

different set of relationships and information.

Knowledge

based

Collect and catalog the different architectural components (such as

what, how, who, why) and their relationships to help answer

business questions.

Business architecture helps you keep systems and operations working well

together. Business analysts often use these models of the existing state to

analyze and assess the impacts of a proposed IT or non-IT change. The

architecture itself can also be used as a catalyst for change while staying aligned

with the enterprise’s vision, goals, and strategy.

Change Scope

Business architecture focuses both on and across the enterprise. This does not

mean that a business architecture initiative or project has to have the same

broad focus. There are many ways to construct a business architecture project in

an organization. Keep in mind that you should be aware of the entire enterprise

even if your project is addressing only a small piece of that enterprise. That’s

what business architecture is all about—keeping the entire enterprise in mind in

order to be consistent in your implementation.

There are five elements to consider as part of the business architecture

perspective and the scope of a proposed change. Let’s walk through each of

those elements now:

Breadth of Change Remember that business architecture may be done across

459

the whole enterprise, across a line of business within the enterprise, or across a

single functional division. Staying aligned with the enterprise’s strategic

objectives is an important part of any business architecture project.

Depth of Change Business architecture projects may be shallow or deep when

it comes to the different levels found within an organization. Typically, these

projects focus on the executive or management levels of the organization.

Executive level projects target executive decision-making capabilities, while

management-level projects target executing specific initiatives within the

organization.

Business architecture provides context to the operational decision

or process levels within an organization. Business architecture assesses

process at the level of the value stream versus actually operating at these

operational decision or process levels.

Value and Solutions Delivered Business architecture uses the separation of

concerns principle to develop models decomposing the business system,

solution, or organization into individual elements. Each element has specific

functions and interactions with other elements. Typical elements of these

models include the following:

Capabilities

Value

Processes

Information and data

Organization

Reporting and management

Stakeholders

Security strategies

Outcomes

Business architecture blueprints allow management to plan and execute

strategies for projects of all types. This includes strategic planning,

organizational redesign, and business remodelling efforts. Improving customer

retention can be achieved by performance measurement initiatives. Business

operations may be streamlined in some way and costs reduced as a result.

Delivery Approach The business architecture’s planning framework is

frequently used to identify required changes and make decisions about which

initiatives to perform. The insight and understanding of the organization’s

strategy alignment is the trigger for a change. For each blueprint, business

architecture may define the current state, the desired future state, and one or

more transition states between the current and future states.

460

A business architect familiar with the organization’s value streams, capabilities,

structures, processes, and data stores often performs business architecture

modelling. Business architects use blueprints and models to address needs

using the framework of the organization’s goals and strategy.

Successful business architecture work requires the support of the executive

team and integration with the governance processes of the organization. Any

new work must be integrated with ongoing initiatives and have access to senior

leadership within the enterprise.

Major Assumptions There are some assumptions that go along with the

business architecture perspective on projects. Remember that these projects can

be IT or non-IT projects. Assumptions include the following:

Business analysts have a view of the entire organization under analysis and

get full management team support.

Business owners and subject-matter experts (SMEs) participate.

An organizational strategy is in place.

There is a business imperative to be addressed.

Business Analysis Scope

Now let’s take a look at the specific elements of business analysis work as part of

the business architecture perspective. There are four elements to consider. We

will step through each of these elements now:

Change Sponsor The sponsor of a business architecture initiative should be a

senior executive, a business owner, or a line-of-business owner.

Change Targets Business architecture analysis typically targets changes to

business capabilities, value streams, or initiative plans. Investment and

portfolio decisions may also be involved. All management levels in the

organization can use the business architecture to guide changes within the

organization. Solution architects, project managers, and business analysts may

also rely on business architecture when dealing with a proposed change.

Business Analyst Position Business analysts working on business

architecture projects need to understand the enterprise context in order to

provide balanced insight into the elements and relationships that are part of

their projects. The models, or blueprints, of the organization come in handy as

the basis for strategic decisions regarding proposed changes. This strategic

alignment is very important as you support your projects through the

transitions between the current and future states.

The short list of skills and knowledge required of business analysts on business

intelligence projects is significant. The list includes knowledge of business

strategy and goals and conceptual business information. Knowledge of the

enterprise IT, process business performance, and intelligence architectures are

also required.

Business Analysis Outcomes General outcomes for business architecture

461

include the alignment of the organization to its strategy, planning change as

part of strategy execution, and ensuring that any implemented changes remain

aligned to that strategy. These strategy-focused outcomes provide the business

analyst with context for their activities.

Business capability, value stream, and organization maps are three key business

architecture deliverables. High-level process architecture, business motivation

models, and business information concept deliverables are also helpful. Let’s

move on and consider some specific reference models used as business

architecture templates.

Reference Models and Techniques

There are many approaches to business architecture projects and initiatives.

Table 9.13 summarizes business architecture reference models and the industry

where that model is used.

TABLE 9.13 Business architecture reference models

Reference Model Domain

Association for Cooperative

Operations Research and

Development (ACORD)

Insurance and financial industries

Business Motivation Model

(BMM)

Generic

Control Objectives for IT

(COBIT)

IT governance and management

eTOM and FRAMEWORX Communications sector

Federal Enterprise

Architecture Service

Reference Model (FEA

SRM)

Government (developed for the U.S. federal

government)

Information Technology

Infrastructure Library

(ITIL®)

IT service management

Process Classification

Framework (PCF)

Multiple sectors including aerospace, defense,

automotive, education, electric utilities,

petroleum, pharmaceutical, and

telecommunications

Supply Chain Operations

Reference (SCOR)

Supply chain management

Value Reference Model

(VRM)

Value chain and network management

There are many techniques used commonly for business architecture projects.

Table 9.14 lists these techniques and a brief description of how that technique

may be used in a business architecture project environment.

462

TABLE 9.14 Business architecture techniques

Technique Description

Archimate

An open-standard modelling language

Business

Motivation

Model (BMM)

Formalizes business motivation in terms of mission, vision,

strategies, tactics, goals, objectives, policies, rules, and

influences

Business

Process

Architecture

Models processes and interface points to provide a holistic view

of the processes existing within an organization

Capability

Map

Hierarchical catalog of business capabilities categorized as

strategic, core, or supporting capabilities

Customer

Journey Map

Depicting the journey of a customer and their user experience

through touch points and stakeholders in a service or

organization

Enterprise

Core Diagram

Models integration and standardizations of the organization

Information

Map

Catalogs important business concepts associated with business

capabilities and value delivery—a taxonomy of the business

Organizational

Map

Models relationships of business units to each other, to

external partners, and to capabilities and information. Focuses

on interaction between units

Project

Portfolio

Analysis

Models programs, projects, and portfolios to provide a view of

an organization’s initiatives

Roadmap Models actions, dependencies, and responsibilities required for

an organization to move from a current state through

transition states to a future state

Service-

Oriented

Analysis

Models analysis, design, and architecture of systems and

software to provide a view of an organization’s IT

infrastructure

The Open

Group

Architecture

Framework

(TOGAF

)

A method of developing enterprise architecture focusing on

business architecture

Value

Mapping

Represents the activity stream required to deliver value as an

end-to-end process

Zachman

Framework

Provides an ontology of enterprise primitive concepts based on

six interrogatives (what, how, where, who, when, why) and six

levels of abstraction (executive, business management,

architect, engineer, technician, enterprise)

463

Underlying Competencies

Business analysts working on business architecture projects must have a high

tolerance for ambiguity and uncertainty. You need to be comfortable and

capable when interacting with executives in your organization. The ability to put

things into a higher, strategic context is a key component of success. You will

find yourself delivering short-term tactical outcomes that provide immediate

value as well as contribute to achieving the long-term business strategy.

Knowledge Area Impacts

Knowledge area tasks and techniques in the BABOK

Guide may be modified

for business architecture projects before being applied as part of your business

analysis work. Other business architecture–specific techniques can also be

applied to the tasks and their elements within a knowledge area.

There are numerous BABOK

Guide techniques that are used during business

analysis activities on business architecture projects. Table 9.15 contains a

mapping of techniques by knowledge area for business architecture projects.

TABLE 9.15 Mapping BABOK

Guide techniques to knowledge areas for

business architecture projects

Technique BAPM EC RLCM SA RADD SE

Acceptance and evaluation criteria X X

Backlog management X

Balanced scorecard X X X X

Benchmarking and market analysis X X X X

Brainstorming X X X X X

Business capability analysis X X X X X

Business model canvas X X

Business rules analysis X X

Collaborative games X X X X

Data dictionary X

Data flow diagrams X

Data modelling X X X

Decision analysis X X X

Document analysis X X X

Estimation X X X X

Focus groups X X X X

Functional decomposition X X X

Glossary X X X

464

Interface analysis X X X

Interviews X X X

Item tacking X X X X X

Lessons learned X X X

Metrics and KPIs X X X X X

Nonfunctional requirements analysis X X

Observation X X X

Organizational modelling X X X X X

Process analysis X X X

Process modelling X X X X

Prototyping X X

Reviews X X X X

Risk analysis and management X X X X X

Roles and permissions matrix X X X X

Root-cause analysis X X X X

Scope modelling X X

Sequence diagrams X

Stakeholder list, map, or personas X X X X X X

State modelling X

Survey or questionnaire X X X X X

SWOT analysis X X X X

Use cases and scenarios X X

User stories X X

Vendor assessment X

Workshops X X X

Other business architecture–specific techniques can also be applied to the tasks

and their elements within a knowledge area. Table 9.16 contains a mapping of

these other techniques by knowledge area for Business Architecture projects.

TABLE 9.16 Mapping other techniques to knowledge areas for business

architecture projects

Other BA Techniques BAPM EC RLCM SA RADD SE

Archimate

X X X

Business motivation modelling X

Business process architecture X X X X X

Business value Modelling X

Capability map X X X X X

465

Customer journey map X X X

Enterprise core diagram X X X

Project portfolio analysis X X X X

Roadmap X X X

Service-oriented analysis X X X X X

Strategy map X

Value mapping X X X X

Please refer to and review these tables as you navigate and learn about the

business architecture–related variations on each knowledge area. Make sure

you know which techniques might apply to specific knowledge areas and

activities on your projects.

Let’s look at each knowledge area, looking at what might need to be done

differently on business architecture projects.

Business Analysis Planning and Monitoring When you are planning your

business analysis efforts, be sure to look at the context of the organization,

including strategy, direction, and current business and operational capabilities.

Plans and analysis for a proposed change take place within this organizational

culture and are impacted by the organization’s capacity for change. Within this

framework, you can evaluate the value proposition of your project and select the

relevant architectural viewpoints for your analysis efforts.

Governance planning and monitoring activities focus on selecting

projects that provide the most benefit relative to the business strategies. You

will also determine which business architecture models or frameworks exist

or are used in the organization.

Elicitation and Collaboration Business architecture requires inputs from

across the organization. Business analysts elicit business analysis information

from stakeholders regarding strategy, value, existing architectures, and

performance metrics. You will use both formal and informal approaches to

finding out what you need to know.

Business analysts advocate the proposed change they are analyzing and ensure

the approach and outcome supports the organization’s strategy. These tasks

require mastery of elicitation, communication, and collaboration skills.

Requirements Life Cycle Management Projects impact an organization’s

business architecture over time. Business analysts find themselves involved with

expanding, correcting, and improving that architecture. Executive support is an

essential component of business analysis success. A review board focusing on

portfolio management will make the decisions about what projects to invest in

and which projects to discard.

466

Strategy Analysis Business architecture and strategy analysis go hand in

hand. Business analysts use business architecture to get a view of the current

state of an organization and to define a desired future state. The organization’s

change strategies will drive decision making and direction.

There may be one or more transition states that are required to transition from

the current to that new future state. Business analysts must clearly define these

transition states and make sure that the organization can stay competitive

during the transition times. Be sure to consider cost, opportunity, and effort as

part of your strategy analysis work.

Requirements Analysis and Design Definition Business architecture

provides views into the organization using many types of models. According to

the BABOK

Guide, these “models provide context and information that result

in better requirements analysis and design.” Business analysts use models to

minimize risk and avoid duplication of systems, capabilities, or information.

Design work is typically done at the same time as requirements development.

Business analysts look at the strategic alignment and effects of a proposed

change. For both requirements and design development, business analysts focus

on keeping the organization working well and delivering business value.

Solution Evaluation Evaluating a solution involves assessing how well the

business is performing. Performance characteristics and measures need to be

defined and built into the solution being implemented. The outcomes must be

well defined and measurable. The information required to measure performance

needs to be available, collected, and reported. Performance measurement tends

to be done by the business owners versus the project’s business analysts.

All knowledge area tasks and techniques can be modified for business

architecture projects before being used. Now, let’s move on and take a look at

the next perspective that business analysts need to be familiar with: looking at

business analysis work on a project from the business process management

point of view.

467

The Business Process Management Perspective

Business process management (BPM) is a management discipline focused on

developing or improving an organization’s business processes and value

delivery. BPM projects implement improvements to the way an organization’s

work is done. This includes both manual and automated processes. In many

organizations, business process management is an ongoing effort.

Change Scope

Business analysts may find themselves working on a single process or all of the

processes within an organization. The business analyst’s focus in all cases is to

change processes in order to improve and meet an organization’s objectives.

Table 9.17 contains the four activities found in a business process management

life cycle.

TABLE 9.17 The BPM life cycle

Activity Description

Designing Identifying processes and defining the current “as-is” state to

determine the desired future “to-be” state, and analyzing the gap

between current and future states

Modelling Graphically representing the process to compare current and

future states, and providing inputs to requirements and solution

design specifications

Executing

and

Monitoring

Collecting data during the actual execution of the process to

analyze value and recommending design improvement alternatives

Optimizing Ongoing repetition and iteration of the other three phases to

modify models and designs, remove inefficiencies, and add more

value

There are five elements to consider as part of the BPM perspective and the scope

of a proposed change. Let’s step through each of those elements now in greater

detail:

Breadth of Change BPM initiatives can span the entire enterprise targeting

optimization of value delivery across end-to-end processes. Individual initiatives

focus on specific processes and subprocesses within an organization.

Depth of Change BPM frameworks are sets or descriptions of processes for

generic organizations, specific industries, or types of value streams. Business

analysts may use these frameworks to analyze an organization’s processes. BPM

frameworks can be high-level or very detailed in nature, such as analyzing an

organization’s supply chain by decomposing high-level processes into their

subcomponents and the individuals performing specific tasks.

Value and Solutions Delivered BPM’s goal is improving operational

468

performance and reducing costs and risks. Transparency into processes and

operations is also a common component of BPM projects. The business needs of

the customers are the BPM drivers, such as reducing costs, increasing quality,

or addressing risks.

According to the BABOK

Guide, operational performance

improvements address effectiveness, efficiency, adaptability, and quality.

Delivery Approach Delivery approaches for BPM projects range from tactical

methods of improving individual processes to management-centric methods

touching all processes in the organization. Table 9.18 describes the mechanisms

used to implement BPM.

TABLE 9.18 Methods used to implement BPM

Method Description

Business

process

reengineering

Aiming for major process redesign across the enterprise

Evolutionary

forms of

change

Setting overall objectives for the process and then individual

changes to bring the subprocesses in line

Substantial

discovery

Revealing and analyzing an organization’s actual processes

when they are undefined or very different from the

documentation that is available

Process

benchmarking

Comparing an organization’s processes and performance

metrics to industry best practices

Specialized

BPMS

applications

Applications supporting BPM initiatives that directly execute

process models and automate BPM activities

There are four process improvement approaches that may be used on BPM

projects or initiatives. They are categorized in terms of their point of origin and

whether their solutions are organizational/people-based or technological/IT-

based. Table 9.19 summarizes these four approaches for you.

TABLE 9.19 Four BPM process improvement approaches

Method Description

Top-

down

Initiatives orchestrated and controlled by senior management,

targeting end-to-end processes or major parts of the business

Bottom-

Tactical initiatives improving individual processes and department

workflows in smaller parts of the organization

People- Initiatives where the principal change is the activities and workflows

469

centric of an organization

IT-

centric

Initiatives where the principal change is process automation

Major Assumptions Here is a brief list of major BPM assumptions for you to

consider:

Processes are supported by IT systems, but developing these IT systems is

not part of most BPM methods.

BPM initiatives have senior management support.

BPM systems require tight integration with organizational strategy, although

strategy development is outside of the BPM perspective’s scope.

BPM initiatives are cross functional and typically span from end-to-end in an

organization.

Business Analysis Scope

Now let’s take a look at the specific elements of business analysis work as part of

the BPM perspective. There are four elements to consider.

Change Sponsor Executives tend to be the starting point for most BPM

initiatives as they link strategic objectives to business processes and try to

increase both value and outcomes. An external trigger often generates a

business need leading to a business analyst developing a business case to justify

a BPM initiative for executive management. Once the project or initiative is

underway, process or subprocess managers at different levels in the

organization manage the resulting BPM effort.

Change Targets Table 9.20 contains a list of primary change targets for a

BPM project or initiative and defines the responsibilities associated with each

change target role.

TABLE 9.20 BPM change targets

Role Responsibilities

Customer Key stakeholder validating effectiveness of the process change

and ensuring process delivery goals align to customer

expectations

Regulator Represent compliance and risk management for the initiative

Process owner Key stakeholder with the responsibility and authority to make

final decisions about changes to affected processes

Process

participants

Define activities of the process being evaluated.

Project

manager

Manages the BPM initiative and is accountable for delivery

decisions

Implementation

team

Converts BPM plans into functioning and integrated business

processes

470

Business Analysis Position Business analysts on BPM projects may assume

many roles. Process architects find themselves modelling, analyzing, deploying,

monitoring, and continuously improving business processes using a technology-

based BPM platform. Process analysts or designers are the experts in

documenting and understanding process design and performance trends using

various BPM frameworks. Process modellers capture and document as-is and

to-be business processes for implementation or support by an IT system.

Business Analysis Outcomes Table 9.21 summarizes the five typical

outcomes for business analysts on BPM projects.

TABLE 9.21 BPM business analysis outcomes

Outcome Description

Business process

models

Model the as-is, to-be, and transition processes from end to

end.

Business rules Guide business processes and assert business structure or

control business behavior.

Process

performance

measures

Parameters used to identify process improvement

opportunities to align processes to business

needs/objectives

Business

decisions

Determine which of a set of options will be acted upon by

the process.

Process

performance

assessment

Measures and monitors the performance of targeted

business processes in a static or dynamic fashion

Frameworks, Methodologies, and Techniques

There are many frameworks, methodologies, and techniques used for BPM

projects. Table 9.22 summarizes the common frameworks used as part of

business process management.

TABLE 9.22 BPM frameworks

Framework Description

ACCORD Methodological framework mapping current state

models and unstructured data to conceptual models

Enhanced

Telecommunciations

Operations Map

(eTOM)

Hierarchical framework used by the telecommunications

industry and other service-oriented industries

Governments

Strategic Reference

Model (GSRM)

Life cycle framework providing generic government

processes and patterns for each organizational maturity

stage

Model-based and

Integrated Process

Cyclical framework assessing process readiness,

outlining a process under review, detailing data

471

Improvement

(MIPI)

collection, modelling the current process, implementing

an improved process, and reviewing the process

Process

Classification

Framework (PCF)

Classification framework detailing processes for

benchmarking and performance measurement

In addition to the frameworks, a number of methodologies also come into play

as part of BPM projects. Table 9.23 lists them for you.

TABLE 9.23 BPM methodologies

Methodology Description

Adaptive Case

Management

(ACM)

Used when processes are not fixed or static with a lot of

human interaction

Business

Process

Reengineering

(BPR)

Rethinking and redesigning business processes to generate

improvements

Continuous

Improvement

(CI)

Ongoing monitoring and adjustment of existing processes to

bring them closer to goals or performance targets

Lean Eliminating waste, or work the customer will not pay for, in a

process

Six Sigma Statistically oriented way of eliminating variations in the

outcome of a process

Theory of

Constraints

(TOC)

Optimizing performance by managing three variables:

process throughout, operational expense to produce

throughout, and product inventory

Total Quality

Management

(TQM)

Processes provide customers with the highest quality

products/services that meet or exceed expectations.

There are many techniques used specifically in BPM projects. These techniques

are not found in the “Techniques” chapter of the BABOK

Guide. Table 9.24

lists these techniques and gives a brief description of how that technique may be

used.

TABLE 9.24 BPM techniques

Technique Description

Cost analysis Showing detailed cost of a process by listing the cost per

activity. Also known as activity-based costing

Critical to Quality

(CTQ)

Aligning process improvement efforts to customer

requirement by using tree diagrams

Cycle-time analysis Analyzing the time each activity takes within the process.

472

Also known as duration analysis

Define Measure

Analyze Design

Verify (DMADV)

Developing new or improving existing processes using a

data-driven, structured roadmap

Define Measure

Analyze Improve

Control (DMAIC)

Improving existing processes using a data-driven,

structured roadmap

Drum-Buffer-Rope

(DBR)

Ensuring that the system constraint always functions at

the maximum possible output by having a buffer of

materials to keep the system busy

Failure Mode and

Effect Analysis

(FMEA)

Investigating process failures and defects in the as-is

roadmap, identifying potential causes, and correcting

them in the to-be roadmap

House of Quality/

Voice of Customer

Relating customer desires and product characteristics to

organizational capabilities using a matrix

Inputs, Guide,

Outputs, Enablers

(IGOE)

Describing process content by listing inputs and outputs,

guides, and supporting tools/information

Kaizen Event Improving value delivery in a specific process or

subprocess in a focused, rapid effort

Process Simulation Modelling the process and a set of randomized variables

to allow for multiple process variations and estimate

performance

Suppliers Inputs

Process Outputs

Customer (SIPOC)

Summarizing inputs and outputs from multiple

processes in a table

Theory of

Constraints (TOC)

Thinking Processes

Diagnosing conflicts, identify causes of problems, and

defining future state using a logical cause-and-effect

model

Value Added

Analysis

Identifying improvement opportunities by looking at

customer benefits added at each step of a process

Value Stream

Analysis

Assessing value added by each functional area of a

business to a customer using an end-to-end process

Who What When

Where Why (5Ws)

Gathering information using a basic set of questions.

May also include “How”

Underlying Competencies

Business analysts on BPM projects are experts at challenging the status quo,

understanding the root causes of problems, assessing why things are done in a

particular way, and encouraging stakeholders to think differently in order to do

things better. According to the BABOK

Guide, the required competencies for

BPM business analysts also include the following:

473

Understanding/articulating internal/external process views

Interaction, facilitation, and negotiation skills

Conflict management skills

Communication skills across all levels of the organization

Executive Presence and Maintaining Professional Detachment

Working on BPM projects often involves interaction with executive

management. As part of a business analyst’s executive presence in these

situations, you need to master the art of professional detachment. Your

ability to remain in control of yourself when others become angry or

frustrated because of process changes, not getting their way, or personality

clashes will be tested. Professional detachment is about looking at the

events from a distance without being directly emotionally involved or taking

what happens outside as a personal matter. Here are a few examples:

Lack of Detachment

Horatio was assigned as a business analyst to a project that involved the

negotiation and implementation of a new national interface standard

between telecommunications companies.

Horatio’s team was invited to travel to a meeting to discuss the

implementation details with one of the major companies involved in the

effort. He and his teammates flew out, drove to the company’s headquarters,

and were ushered into a conference room to begin a two-day session of

discussions with the company’s executive management team and project

leaders.

The leader of the opposite team became increasingly frustrated as

discussions went through midmorning. Her own team repeatedly corrected

the leader as she misrepresented capabilities from their software application

systems and how the team would interface their capabilities.

In an explosive display of emotion, the leader stalked out of the conference

room. Both her team and Horatio’s team were stunned. The leader had not

told anyone present when or if she would return. The group waited silently

at the table for more than an hour before one of the team members went to

find her. The team member returned telling the group that the meeting was

over and would not be rescheduled. Ouch.

Too Much Detachment

474

A second major company on the same project came to meet Horatio’s team

at their headquarters. Discussions were lively, cordial, and productive. One

of their representatives, Horatio’s counterpart on the project, was both a

friendly and intelligent meeting participant.

In response to the representative’s friendliness, Horatio overcompensated

and became too detached during the meeting. Questions were answered

with to-the-point and factual responses. Any hint of other than professional

responses were belayed to the point of being curt.

It wasn’t until months later that Horatio allowed himself the freedom of

actually becoming friendly with his counterpart from the other organization.

Knowledge Area Impacts

Knowledge area tasks and techniques in the BABOK

Guide may be modified

for BPM projects before being applied as part of business analysis work.

Additional BPM-specific techniques may also be applied to the tasks and their

elements within a knowledge area in addition to or in place of the techniques

used on more traditional types of projects.

There are numerous BABOK

Guide techniques that are used during business

analysis activities on BPM projects. Table 9.25 contains a mapping of

techniques by knowledge area for BPM projects.

TABLE 9.25 Mapping BABOK

Guide techniques to knowledge areas for BPM

projects

Technique BAPM EC RLCM SA RADD SE

Acceptance and evaluation criteria X X

Backlog management X

Balanced scorecard X

Benchmarking and market analysis X X

Brainstorming X X X

Business capability analysis X

Business rules analysis X X X

Decision analysis X

Decision modelling X

Document analysis X X X

Estimation X X X

Focus groups X

Functional decomposition X X

Interface analysis X

475

Interviews X X X

Item tracking X

Lessons learned X

Metrics and KPIS X X X

Nonfunctional requirements analysis X

Observation X X

Organizational modelling X

Prioritization X X

Process analysis X X

Process modelling X X X X X

Prototyping X X X

Reviews X X X

Risk analysis and management X

Root-cause analysis X X

Scope modelling X X X

Stakeholder list, map, or personas X X X X

Survey or questionnaire X X

SWOT analysis X

Use cases and scenarios X

User stories X

Workshops X X X X

Other business analysis techniques were included in Table 9.24. Please refer to

and review this table as you navigate and learn about the BPM variations on

each knowledge area. Make sure you know which techniques might apply to

specific knowledge areas and activities on your projects. Let’s step through each

knowledge area and look at what might need to be done differently for BPM

projects.

Business Analysis Planning and Monitoring Planning business analysis

work on BPM projects is an exercise in progressive elaboration. Continuous

improvement activities are also heavily involved as part of this knowledge area.

Initially, business analysts focus on analyzing and improving the business

process before considering the technology and revised work procedures that are

actually required to improve that process.

A common cause of failure for BPM projects or initiatives is the

failure to plan for ongoing monitoring of the effects of changes on the

organization.

476

Elicitation and Collaboration Elicitation on BPM projects is effective when

it is performed within the defined scope of the project and any affected

processes. Process modelling, process maps, and stakeholder analysis are

commonly done during requirements elicitation. The business analyst looks at

changing and improving an existing process as they gather business analysis

information. Managing stakeholders relative to the resulting changes is another

aspect of the business analyst’s job during elicitation.

Requirements Life Cycle Management BPM and the requirements life

cycle may come into conflict during a BPM project. BPM looks at ways to deliver

value in a process-focused way, while the generic requirements life cycle is a bit

more linear and predictable in nature. Rework, revision, and new requirements

can result from BPM project activities. Business processes should be

documented so all stakeholders can review and understand them.

Strategy Analysis Strategy Analysis looks at the role of the process in the

enterprise value chain. This view may expand the scope of the business analyst’s

efforts, since any process interacting with the processes affected by the project

must be looked at and potentially included in that project’s scope. The current

state of the enterprise is defined in an as-is value chain before the future state

(to-be) value chain is defined.

Requirements Analysis and Design Definition This knowledge area

focuses on defining the to-be process model on BPM projects. The requirements

architecture will include the process model, associated business rules/decisions,

information requirements, and the organizational structure. Solution options on

BPM projects typically include any changes needed to support the new or

revised process.

Solution Evaluation Solution evaluation activities take place across BPM

project life cycles to assess business process performance. Over time, processes

are refined based upon the results of these evaluations. Business analysts may

find themselves process mining using audit trails and transaction logs. The

focus is on potential value versus actual value.

Remember that all of these knowledge area tasks and techniques can be

modified or left alone on your BPM projects.

477

Understanding How This Applies to Your Projects

Adjusting what you do and how you do it based upon the type of project you are

working on is an essential skill for successful business analysts. Your ability to

recognize your project’s context and use the correct tasks, techniques, methods,

and tools will help keep your business analysis efforts on target and in sync. The

five project types or perspectives in the BABOK

Guide are a great starting

point: agile, business intelligence, information technology, business

architecture, and business process management.

Remember that there are many other perspectives or types of projects. Many of

my projects included more than one of these perspectives. For example, a

project may have an information technology component but is focused on

mining and using business data better for decision making as part of the

organization’s business architecture. Some projects may use multiple

development approaches, with agile methods being applied to the web-based

aspect of a new system and a more traditional life cycle model being used for the

software applications that are “under the covers.”

Many perspectives require you to turn on or turn up specific business analysis

competencies, such as your collaboration or communication skills. These

competencies may be directed at senior management as you work with and for

your project sponsor to get things done.

Approaching your business analysis work in the correct context is a win for both

you and your project team. The knowledge areas, tasks, and techniques can be

customized or tailored to fit the perspectives being used on your project.

Remember too, each of the five perspectives includes methods, techniques,

tools, and frameworks to help you get the job done.

478

Summary

You covered a lot of content in this chapter. You learned that business analysis

is an essential part of every organization. Successful business analysts bring a

serious set of skills and knowledge to every project or initiative in order to liaise

among the stakeholders to address business needs and solve business problems.

Business analysis is more than just asking questions!

You looked at how the BABOK

Guide provides a business analysis framework

defining areas of knowledge, associated activities and tasks, and the skills

required to perform them. The scope of the BABOK

Guide covers pre-project

activities, the full project life cycle, and the final solution’s operational life. It is

also the basis for the CBAP® and CCBA™ certification exams, and it provides

the backbone of this book.

479

Exam Essentials

Be able to list and describe each perspective. The names and high-level

descriptions of each of the five perspectives are required knowledge for you as

you prepare to take your exam. The five perspectives are agile, business

intelligence, information technology, business architecture, and business

process management. Be sure you are familiar with how to perform business

analysis work on these five different types of projects and work from their

differing points of view.

Be able to elaborate on the approaches used with each of the five

perspectives. Each perspective offers up its own approach to performing

business analysis work. Be sure you know how the perspective can change how

things are done on a project. For example, agile approaches focus on interacting

with people, transparent communications, and ongoing delivery of value.

Be able to explain the knowledge-area impacts of each perspective.

Each perspective impacts how you use the knowledge area tasks and techniques.

Remember, different types of initiatives facilitate different types of changes to

the business. Make sure you have the right people, the right methods, and the

right approach to define what has to be done. Take time to get familiar with

these changes and customizations, at least at a high-level.

Be able to recognize the underlying competencies for each

perspective that every good business analyst should possess. Each of

the five high-level perspectives outlines specific skills that effective business

analysts should possess when they work on those types of projects. Be sure that

you are comfortable with what it means to be a business analyst and how to

successfully navigate the unique skill sets required for each perspective or point

of view on your projects.

480

Key Terms

This chapter introduced the five perspectives from the BABOK

Guide that you

might find yourself using as a business analyst on your projects and other

initiatives. You will need to understand how to add to, customize, and modify

the contents of the BABOK

Guide in order to be an effective business analyst

for these specific types of project. Additionally, you will need to know each

perspective by name and definition in order to be successful on the CBAP

CCBA™ exams.

You have learned many new key words in this chapter. The IIBA has worked

hard to develop and define standard business analysis terms that can be used

across many industries. Here is a list of some of the key terms that you

encountered in this chapter:

blueprints

BPM drivers

BPM frameworks

business intelligence

business process management (BPM)

iteration

process mining

professional detachment

progressive elaboration

separation of concerns principle

transparency

481

Review Questions

1. According to the BABOK

Guide, perspectives are used within business

analysis work to provide focus to tasks and techniques specific to the context

of the initiative. The five common perspectives include all of the following

except:

A. Business architecture

B. Information technology

C. Enterprise architecture

D. Business intelligence

2. All of the following statements about the five business analysis perspectives

are true except:

A. Perspectives are not mutually exclusive since a given initiative may use

more than one perspective.

B. Knowledge areas are applied the same way regardless of the perspective

being used.

C. Perspectives do not represent all possible ways to perform business

analysis.

D. Many methodologies, approaches, and techniques are unique to a

particular perspective.

3. Business analysis work is performed ____________ throughout an agile

initiative and relies heavily on ____________ skills.

A. Intermittently, technical

B. Continuously, technical

C. Intermittently, interpersonal

D. Continuously, interpersonal

4. During agile initiatives, scope is constantly evolving. Change and rapid

response to change are expected. What method is used to manage the

ongoing refinements and redefinition of the project scope?

A. Kanban backlog list

B. Retrospectives

C. Storyboarding

D. Planning workshops

5. You are a business analyst working on an agile project. Who is the key

stakeholder that you need to have involved with the project from the

beginning, providing continuous feedback to the team and adjusting the

product as needs change?

482

A. Agile team leader

B. Product owner

C. Project sponsor

D. Domain SME

6. Who can perform business analysis activities on agile teams?

A. Business analyst working on the team

B. Customer representative or product owner

C. Both of the above

D. None of the above

7. The focus of business intelligence is the transformation of data into

____________ information to support business decision making.

A. Value-added

B. Reliable

C. Tactical

D. Strategic

8. You are working on a business intelligence project targeting timely, accurate,

high value, and actionable information driving decision making across the

organization. One focus of your project is customer engagement. What level

of decision-making processes are you targeting?

A. Tactical

B. Strategic

C. Operational

D. External

9. What is the business analyst’s primary role on a business intelligence

initiative?

A. Designing ad hoc queries

B. Designing specialized presentations

C. Enterprise data or decision modelling

D. Liaison between stakeholders and solution providers

10. You are a business analyst capturing and documenting as-is and to-be

business processes for your business process management project. What role

are you performing?

A. Process modeller

B. Process analyst

C. Process designer

D. Process architect

483

11. You are a business analyst applying statistical analysis methods to historical

data to identify patterns and make predictions about future events. Your

focus is on pattern recognition through data mining, predictive modelling,

forecasting, and condition-driven alerts. What type of data analytics are you

developing requirements for?

A. Prescriptive analytics

B. Translation analytics

C. Predictive analytics

D. Descriptive analytics

12. Business analysts working in an information technology environment

consider their tasks in light of three factors. What are these three factors?

A. Solution scope, organizational structure, and change scope

B. Solution impact, organizational maturity, and design options

C. Solution scope, organizational maturity, and change scope

D. Solution impact, organizational maturity, and change scope

13. You are a business analyst working on an information technology project.

Your project is using a waterfall life cycle model to drive the development

efforts. What solution development methodology is being used?

A. Iterative

B. Adaptive

C. Predictive

D. Incremental

14. You are a business analyst working on a project with a predictive

development methodology focusing on established logical modelling and the

separation of requirements from solutions. Which of the four information

technology methodologies are you using?

A. Homegrown/organization specific

B. Requirements engineering (RE)

C. Structured systems and design method (SSADM)

D. Unified process (UP)

15. You are eliciting business requirements for an information technology

project using statistical methods and mockups to identify user needs. Which

method are you applying in your elicitation efforts?

A. Investigation

B. Simulation

C. Experimentation

D. Collaboration

484

16. Business architecture provides architectural descriptions and views to

provide a common understanding of the organization for the purpose of

aligning strategic objectives with tactical demands. What is another name for

these views?

A. Blueprints

B. Models

C. Structures

D. Concerns

17. For each blueprint you have created on your project, you are defining the

current state, the future state, and one or more transition states that are

used to transition to the future state. This provides insight and an

understanding of how well the organization aligns to its strategy and is a

____________ for change.

A. Baseline

B. Proposal

C. Request

D. Trigger

18. All of the listed factors are central to a successful business architecture

except:

A. Support of the executive business leadership team

B. Integration with clear, effective governance processes

C. View of the entire organization that is under analysis

D. Integration with ongoing organizational initiatives

19. Which of the five perspectives focuses on how the organization performs

work to deliver value across multiple functional areas to customers and

stakeholders?

A. Business intelligence perspective

B. Information technology perspective

C. Business process management perspective

D. Business architecture perspective

20. You are a business analyst on a business process management project

collecting data from the processes. Which life cycle activity are you

performing?

A. Designing

B. Modelling

C. Execution/Monitoring

D. Optimizing

485

Appendix A

Advice on Completing Your Exam Application

TOPICS COVERED IN THIS APPENDIX:

Describe the competency-based model for business analysis

certification.

Discuss experience requirements for the CBAP

and CCBA

™

exams.

Calculate your hours of business analysis experience.

Review additional exam eligibility requirements.

Navigate the steps of the exam application process.

This appendix steps you through the four-level competency-

based model for business analysis certification. It also helps you understand the

application requirements for the Certified Business Analysis Professional

(CBAP

) or Certification of Competency in Business Analysis

™

(CCBA

™

)

credentials. The focus of this appendix is on the CCBA

™

and CBAP

exams. It

provides suggestions for completing your application correctly to minimize the

chances of errors and application approval delays.

There are specific experience and eligibility requirements that will be used to

evaluate your fitness for taking the CBAP

or CCBA

™

exam. Both certifications

require work experience as a business analyst. Both certifications ask you to

meet or exceed the same non-work-related requirements, such as education and

professional development. In this appendix, you will look at the unique

experience requirements for each exam and then review the common set of four

eligibility requirements that apply for both exams.

486

The Competency-Based Certification Model

The multilevel, competency-based certification model offers four certifications

to business analysts. The model was designed to recognize the Business Analysis

(BA) professional through their career progression and to support more

opportunities for growth and development. CCBA

™

and CBAP

certifications

will map to levels 2 and 3, respectively, in this multilevel enhanced certification

program. These two levels are considered the global standard of practice for

business analysts.

Table A.1 summarizes each business analysis certification level.

TABLE A.1 Business analysis certification levels

Level Acronym Name Exam

Type

Description

1 ECBA™ Entry

Certificate

in Business

Analysis

Exam-based Recognizes a person’s entry into

the business analysis profession

2 CCBA

™

Certification

Capability

in Business

Analysis

Exam-based Requires 2 to 3 years of business

analysis experience and 3,000 to

4,500 hours of work experience

and is also exam based

3 CBAP

Certified

Business

Analysis

Professional

Exam-based Requires more than 5 years of

business analysis experience and

7,500 to 10,500 hours of work

experience

4 CBATL™ Certified

Business

Analysis

Thought

Leader

Assessment-

based

Requires more than 10 years of

business analysis experience.

Applicants are industry thought

leaders, give back to the BA

community, and contribute to

the evolution of the BA practice.

Level 4 requires a minimum of

15,000 hours, and is assessment

based.

Now let’s step through the detailed requirements for CBAP

and CCBA

™

certification, which are the focus of this book.

487

CBAP

Experience Requirements

The CBAP

designation is available to experienced business analysts.

Applicants who want to take the CBAP

certification exam must meet specific

experience and education requirements. During the application process, you

must demonstrate your competencies across the spectrum of business analysis

knowledge and skills. After your application has been reviewed and accepted,

you will be eligible to take and pass your certification exam. Table A.2

summarizes the experience-specific requirements for you.

TABLE A.2 Experience requirements for the CBAP® certification exam

Requirement Description

Work

experience

Minimum of 7,500 hours of business analysis work experience

aligned with the BABOK

Guide in the last 10 years

Knowledge

areas

Minimum of 900 hours of business analysis work in each of

four knowledge areas, totaling at least 3,600 hours

Let’s take a closer look at the experience requirements needed to qualify for

taking the CBAP

exam:

Work Experience You must possess a minimum of 7,500 hours of business

analysis work experience aligned with the BABOK

Guide in the last 10 years of

your work life. The timeframe is measured backward from the date of your

application. You can calculate that 7,500 hours of work equals about 5 full years

of business analysis work experience during that 10-year period, or doing

business analysis stuff about half of the time.

The work experience can be you directly performing the business analysis tasks

(hands on) or time you spent coaching or mentoring others in performing those

tasks. Conducting business analysis training and performing project

management activities on your projects are not acceptable experiences to

include in your application. Be careful to select and provide experiences in your

application that are aligned with the BABOK

Guide and that are specific

business analysis tasks.

Knowledge Areas You must demonstrate business analysis experience and

expertise in four of the six knowledge areas. You must show a minimum of 900

hours of business analysis experience and expertise in each knowledge area you

choose to document. This means that you engaged in tasks specifically related to

the BABOK

Guide knowledge areas, so make sure that you review them

carefully relative to the work you have performed. The 900 hours in each of four

knowledge areas make up 3,600 hours of your business analysis experience.

This is a minimum requirement; it is just fine if you have experience across all

six of the knowledge areas. Actually, the more experience you document in your

application, the better off you will be. This approach provides a buffer in case

some of your experience is disqualified during your application’s review cycle, so

488

your application process won’t be jeopardized.

If the contents of your application do not support compliance with both of the

two experience requirements, your application will be declined. If you don’t

meet the experience requirements for the CBAP

certification, you might want

to consider applying for the CCBA

™

credential.

489

CCBA

™

Experience Requirements

The CCBA

™

designation is available to less-experienced business analysts.

Although the experience requirements are less than those required for taking

the CBAP

certification exam, they are reviewed and enforced with equal vigor.

Applicants who want to take the CCBA

™

certification exam must meet specific

experience and education requirements. During the application process, you

must demonstrate your competencies across the spectrum of business analysis

knowledge and skills. After your application has been reviewed and accepted,

you will then be eligible to take your certification exam. Table A.3 summarizes

the exam eligibility requirements.

TABLE A.3 Experience requirements for the CCBA™ certification exam

Requirement Description

Work

experience

Minimum of 3,750 hours of business analysis work experience

aligned with the BABOK

Guide in the last 7 years

Knowledge

areas

Minimum of 900 hours of business analysis work in each of

two of knowledge areas, or 500 hours in each of four

knowledge areas

Let’s take a closer look at the work experience required to take the CCBA

™

exam.

Work Experience You must possess a minimum of 3,750 hours of business

analysis work experience aligned with the BABOK

Guide in the last 7 years of

your work life. The timeframe is measured backward from your application

date. Again, you can calculate that 3,750 hours of work equals about 2.5 full

years of business analysis work experience during that 7-year period, or doing

business analysis stuff close to one-third of the time.

Your work experience can be you directly performing the business analysis tasks

(hands on) or time you spent coaching or mentoring others in performing those

tasks. Conducting business analysis training and performing project

management activities on your projects are not acceptable experiences to

include in your application. Be careful to select and provide experiences in your

application that are aligned with the BABOK

Guide and that are specific

business analysis tasks.

Knowledge Areas You must demonstrate a minimum of 900 hours of

business analysis experience and expertise each in two of the six knowledge

areas or 500 hours each in four of the six knowledge areas. This means that you

engaged in tasks specifically related to the BABOK

Guide knowledge areas, so

make sure that you review them carefully relative to the work you have

performed. The 900 hours in each of two knowledge areas makes up 1,800

hours of your business analysis experience, while the 500 hours in each of four

areas accounts for 2,000 hours of the required 3,750 hours.

490

These are minimum requirements; it is just fine if you have experience across all

six knowledge areas. Actually, the more experience you document in your

application, the better off you will be. This approach will provide a buffer in case

some of your experience is disqualified during your application’s review cycle, so

your application process won’t be jeopardized.

If the contents of your application do not comply with both of the two

experience requirements, your application will be declined. In addition to the

work experience requirements for taking either exam, you must meet some

additional requirements to qualify to take either exam. Let’s review those

requirements now.

491

Calculate Your Experience Hours

The BABOK

Guide provides explicit instructions about how to calculate the

required hours of business analysis work experience for your application. You

should use your résumé as the basis for your listed projects, the business

analysis activities you performed, and the time you spent doing them. However,

you cannot submit your résumé to meet the experience requirement—you must

parse through its contents in detail and provide the International Institute of

Business Analysis (IIBA) with a detailed list of projects, work activities, and

hours spent. One helpful suggestion is to build a spreadsheet to track everything

by project, knowledge area, and time. Then you can use your spreadsheet

summary to complete the experience section of your application.

As previously mentioned, you need to document a minimum of 7,500

experience hours for your CBAP

application and 3,750 hours for your CCBA

™

application. These totals are the minimum experience requirements. It is a

really good idea to document additional hours above the minimum requirement

(if you have them). If the IIBA reviewers disapprove part of your experience

hours, the additional hours can prevent the disapproval from impacting your

application process.

You need to list your projects in chronological order, starting with the most

recent project you worked on or are working on as of your application date and

then working backward. If you performed business analysis activities on a

bunch of small projects during any particular year, combine them into one

project and make sure to point out that you did this in the description of the

large project that encompassed the smaller ones.

If you are completing an online application, you will be able to select from a set

of business analysis tasks that you performed to achieve the stated number of

work hours. Read the tasks you are selecting from carefully. Do not select tasks

from the lists that are project management tasks or general management work.

Everything you enter for work experience must be business analysis work and

align with the contents of version 3 of the BABOK

Guide. If you select tasks

that are not business analysis tasks within the scope of the BABOK

Guide,

those tasks and their associated hours will be deducted from your total hours.

CBAP

applicants must also meet the minimum requirement of 900 experience

hours each in four of the six knowledge areas. CCBA

™

applicants have a lesser

experience requirement, and they can slice and dice their business analysis

experience in one of two ways, showing either:

A minimum of 900 hours of business analysis work each in two of the six

knowledge areas

A minimum of 500 hours of business analysis work each in four of the six

knowledge areas

For each project, from the list of tasks in the table, check off the tasks you have

492

completed that are aligned with the BABOK

Guide 3.0. Do this for each of the

knowledge areas. You can select a task when you have either performed the task

yourself or coached/mentored another business analyst in performing the task.

For each knowledge area, indicate the percentage of the total business analysis

hours you spent on the tasks you selected. The percentages across all of the

knowledge areas must total 100 within a project.

Several steps need to be taken to calculate your experience hours for each of

your documented projects and each knowledge area. For each knowledge area

specified for a particular project, the percentage of time you say that you spent

on that knowledge area is multiplied by the total business analysis hours you

entered for the project. Likewise, the percentage of invalid experience you

selected from the list of tasks for your project is calculated and deducted. The

tasks you select from are provided by the IIBA for you in your application form.

Once the experience hours for each knowledge area are calculated for each

project, they are summarized in two ways.

By knowledge area across all of your projects to see whether you meet the

minimum knowledge area requirements for the exam

Total hours across all projects to see whether you meet the experience

minimum requirement to take the exam

Both the total experience hours and the knowledge area experience hours must

be met for your application to be considered. If one or both of these

requirements falls short, your application will be declined. You will not be

allowed to apply again for another three months.

493

Additional Exam Eligibility Requirements

To apply for and be approved to take either the CBAP

or CCBA

™

certification

exam, applicants must meet four additional requirements relating to education,

professional development, professional references, and code of conduct. Table

A.4 summarizes these additional requirements.

TABLE A.4 Additional exam eligibility requirements

Requirement Description

Education A high school or equivalent level of education

Professional

development

Minimum of 21 hours of professional development, such as

attending a training course, in the past four years

References Two references from a career manager, client (internal or

external), or a CBAP

recipient

Code of

conduct

A signed code of conduct

Education You must possess a high school education or its equivalent to take

the CBAP

or CCBA

™

exam. If you have one or more college or university

degrees, you can document them as well. Unlike other professional certification

exams, there is no reduction in your work experience requirements for any

additional post-secondary education.

Professional Development You also have a requirement to document 21

hours of professional development in the last four years. The professional

development must be directly related to business analysis, such as one or more

instructor-led training courses. Each hour of class time counts toward 1 hour of

professional development time. This professional development must be

completed prior to your application date, so if you are planning to take a

training course on business analysis as part of your exam preparations, finish

that course before you apply.

References As part of your application, you must provide two professional

references. One of those references needs to be current. These references might

be from a career manager, a client (internal or external), or a CBAP

recipient.

Be aware that a project manager can be used as a reference only if they were also

the career manager responsible for completing your annual performance review.

You must have known each of these individuals for a minimum of six months.

You will be asking your references to indicate that you are a suitable candidate

for the CBAP

or CCBA

™

certification. Each reference will receive an email

message containing a recipient-specific link for them to use to complete a

CBAP

or CCBA

™

candidate reference form online.

Signed Code of Conduct You will be asked to complete and sign a code of

conduct form in order to apply to take the CBAP

or CCBA

™

exam. This is the

494

same form you are asked to complete when you become a member of the IIBA

This form contains your agreement to act ethically, responsibly, and

professionally in your business analysis work.

Exam Spotlight

Review the current CBAP

or CCBA

™

handbooks located on the IIBA

website for complete and up-to-date information on application criteria,

fees, and specific details on how to apply. This information can change

without warning, and the data provided to you here may no longer be up-to-

date.

Review your application contents thoroughly before submitting your

application. Aligning your business analysis work experience with the contents

of the BABOK

Guide in your application is one small step in starting your

exam preparation. Completing the application can be quite time-consuming, so

plan to put your materials together in several sittings over a number of days.

You can complete your online application contents incrementally and save your

work as you go.

Prepare your application content as if your data is going to be audited—it just

might be. Many exam candidates are randomly audited to verify and validate

their work experience and any other information that they provided in their

application.

Now that you have reviewed the experience requirements for applying to sit the

CBAP

or CCBA

™

certification exams, let’s review the exam application process.

495

The Exam Application Process

There are three distinct steps for you to navigate as you apply for and seek

approval to take the CBAP

or CCBA

™

certification exam. Remember that you

must meet all of the requirements in either the CCBA

Handbook or CBAP

Handbook to be eligible for the exam. The following are the steps of the

application process:

1. Apply and pay for CBAP

or CCBA

™

certification.

2. Pay for the exam.

3. Register for the exam.

Let’s take a more detailed look at each of these steps right now.

Applying and Paying for Certification You will be asked to pay two fees to

the IIBA to complete the application process. The first fee is submitted with

your completed application and supporting information. Please check the IIBA

website for the latest application and examination fee information. The

application fee is the same for IIBA members and nonmembers. The fee will not

be refunded if your application is denied. Your certification application package

should contain the following items:

Your completed application form

Your two professional references

Your agreement to adhere to the Code of Ethical Conduct and Professional

Standards

Your certification application fee

After you submit everything, the IIBA will send you an email message indicating

your application has been successfully submitted. Your application will be

reviewed and either approved or denied within 21 business days of its receipt. If

your application is approved, you are eligible to take your exam within one year

from the date of exam eligibility approval.

Exam Spotlight

Remember to print a paper copy of your completed online application for

your own records.

If your application is denied, you are not eligible to take the exam at this time.

You will be notified of the reason why your application was declined. In many

cases, applicants have had work experience disallowed and have fallen below the

minimum experience requirement threshold. You may reapply to take the exam

after three months if your reason for denial can be remedied.

496

Paying for the Exam The exam fee pays for your initial exam sitting after

your application has been approved. This fee is not reimbursed if you fail the

exam. You can include your exam fee with your application package, or you can

wait until you receive the results of your application and pay at that time. Please

check the IIBA website for the latest examination fee information. To receive the

IIBA member rate for your exam fee, you must be a member at the time you

submit your exam fee.

Registering for the Exam Once your exam fee has been processed by the

IIBA, you can register to take your exam at a dedicated test center or as part of a

hosted group. Check the IIBA website for a current list of test center locations.

Castle Worldwide will send you an exam registration letter with instructions for

registering online for your exam. After you register for your selected location,

date, and time, you will receive a confirmation letter that is your admission

ticket to take the exam.

If you fail your exam on your first attempt, you may pay a retake fee and can

retake the exam after three months. This waiting period must fall within your

original year of exam eligibility. You may retake the exam twice during your

eligible testing year. If you fail both retake attempts or your eligibility expires,

you must reapply to take the exam and pay the full fee again.

497

Appendix B

Knowledge Areas, Tasks, and Elements

TOPICS COVERED IN THIS APPENDIX:

Define the terms knowledge area, task, and element.

Review the six knowledge areas.

Outline the tasks and elements of each knowledge area.

This appendix outlines the six BABOK

Guide knowledge

areas, their tasks, and the elements making up those tasks. This appendix is

intended to be used as an orientation device and a study aid as you prepare for

your CBAP

or CCBA

™

certification exam. This appendix also summarizes the

intent of each knowledge area so you can refresh your memory and practice

describing them.

498

Review the Six Knowledge Areas

Knowledge areas divide what business analysts need to know and how they

perform their tasks into six common buckets. The business analyst can dip into

one or more buckets at any time—in any order—to select a deliverable or

perform a necessary task. The knowledge areas are not a road map or a

methodology; they simply break business analysis materials and information

into common areas. The six knowledge areas defined in the BABOK

Guide are:

Business Analysis Planning and Monitoring

Elicitation and Collaboration

Requirements Life Cycle Management

Strategy Analysis

Requirements Analysis and Design Definition

Solution Evaluation

Each knowledge area is decomposed into the more-detailed tasks business

analysts perform. Each task has a particular purpose and adds value to the

overall business analysis effort on a project when a business analyst performs

the task.

Tasks are broken down further into elements. Elements are the detailed

concepts that are necessary to perform a particular task. For some tasks, the

elements are categories of things a business analyst must consider. For other

tasks, the elements are subtasks a business analyst performs.

Business Analysis Planning and Monitoring The Business Analysis

Planning and Monitoring knowledge area is where a business analyst plans how

to approach the business analysis effort. The approach is a set of processes,

templates, and activities used to perform business analysis in a specific context.

The tasks organize and coordinate the performance of all other business

analysis tasks. These planning and monitoring activities take place throughout

the project life cycle. The results of this knowledge area guide the tasks found in

the remaining five knowledge areas and set the performance metrics business

analysts use to evaluate all business analysis work.

Elicitation and Collaboration Elicitation and Collaboration defines how

business analysts work with stakeholders to identify and gather requirements

and understand stakeholder needs and concerns. It also addresses ongoing

collaboration and communication during all business analysis activities.

Requirements Life Cycle Management The Requirements Life Cycle

Management knowledge area defines how business analysts approach managing

and maintaining requirements and design information across the project or

product life cycle. Establishing traceability between requirements and designs

also takes place. It also describes tasks and techniques for communicating and

managing changes, conflicts, and issues related to requirements.

499

Strategy Analysis Strategy Analysis focuses on how a business analyst

identifies the business needs driving a project by performing problem definition

and analysis. In addition to defining and refining these strategic or tactical

needs, a business analyst is responsible for defining a feasible solution scope

that the business can implement. This work may also include developing a

business case or feasibility study for a proposed project. Typically, the tasks in

this knowledge area occur prior to or early in the project life cycle.

Requirements Analysis and Design Definition Requirements Analysis

and Design Definition describes how business analysts progressively elaborate

to define, refine, and prioritize requirements. In essence, a business analyst

takes the elicited information and makes sense of it to derive the real

requirements for the project. This knowledge area also focuses on graphically

modelling the requirements and resulting designs as well as documenting them.

When performing these tasks, a business analyst should ensure the feasibility of

the requirements while defining, describing, and refining the characteristics of

an acceptable solution.

Solution Evaluation The Solution Evaluation knowledge area focuses on

assessing and validating proposed, in-progress, and implemented solutions

before, during, and after the project life cycle. A business analyst’s attention is

on the solution’s value to the enterprise. While many tasks in this knowledge

area take place later in the project life cycle, some solution-focused activities

might occur quite early.

Let’s decompose each knowledge area into its tasks and elements. You can use

these outlines to help you prepare to take your certification exam. You will need

this level of knowledge to successfully prepare for and pass the certification

exams. You will also need this level of knowledge to be an effective business

analysis practitioner in your organization.

500

Knowledge Areas, Tasks, and Elements

The following outline decomposes each knowledge area into its pieces and parts

—the tasks and elements that provide you with more detailed direction as to

what you should be doing.

Business Analysis Planning and Monitoring

Plan business analysis approach

Planning approach

Formality and level of detail of business analysis deliverables

Business analysis activities

Timing of business analysis work

Complexity and risk

Acceptance

Plan stakeholder engagement

Perform stakeholder analysis

Define stakeholder collaboration

Stakeholder communication needs

Plan business analysis governance

Decision making

Change control process

Plan prioritization approach

Plan for approvals

Plan business analysis information management

Organization of business analysis information

Level of abstraction

Plan traceability approach

Plan for requirements reuse

Storage and access

Requirements attributes

Identify business analysis performance improvements

Performance analysis

Assessment measures

Analyze results

501

Recommend actions for improvement

Elicitation and Collaboration

Prepare for elicitation

Understand the scope for elicitation

Select elicitation techniques

Set up logistics

Secure supporting material

Prepare stakeholders

Conduct elicitation

Guide elicitation activity

Capture elicitation outcomes

Confirm elicitation results

Compare elicitation results against source information

Compare elicitation results against other elicitation results

Communicate business analysis information

Determine objectives and format of communication

Communicate business analysis package

Manage stakeholder collaboration

Gain agreement on commitments

Monitor stakeholder engagement

Collaboration

Requirements Life Cycle Management

Trace requirements

Level of formality

Relationships

Traceability repository

Maintain requirements

Maintain attributes

Reusing requirements

Prioritize requirements

Basis for prioritization

Challenges of prioritization

Continual prioritization

502

Assess requirements changes

Assessment formality

Impact analysis

Impact resolution

Approve requirements

Understand stakeholder roles

Conflict and issue management

Gain consensus

Track and communicate approval

Strategy Analysis

Analyze current state

Business needs

Organizational structure and culture

Capabilities and processes

Technology and infrastructure

Policies

Business architecture

Internal assets

External influencers

Define future state

Business goals and objectives

Scope of solution space

Constraints

Organizational structure and culture

Capabilities and processes

Technology and infrastructure

Policies

Business architecture

Internal assets

Identify assumptions

Potential value

Assess risks

Unknowns

Constraints, assumptions, and dependencies

503

Negative impact to value

Risk tolerance

Recommendation

Define change strategy

Solution scope

Gap analysis

Enterprise readiness assessment

Change strategy

Transition states and release planning

Requirements Analysis and Design Definition

Specify and model requirements

Model requirements

Analyze requirements

Represent requirements and attributes

Implement the appropriate levels of abstraction

Verify requirements

Characteristics of requirements and designs quality

Verification activities

Checklists

Validate requirements

Identify assumptions

Define measurable evaluation criteria

Evaluate alignment with solution scope

Define requirements architecture

Requirements viewpoints and views

Template architectures

Completeness

Relate and verify requirements relationships

Business analysis information architecture

Define design options

Define solution approaches

Identify improvement opportunities

Requirements allocation

Describe design options

504

Analyze potential value and recommend solution

Expected benefits

Expected costs

Determine value

Assess design options and recommended solutions

Solution Evaluation

Measure solution performance

Define solution performance measures

Validate performance measures

Collect performance measures

Analyze performance measures

Solution performance versus desired value

Risks

Trends

Accuracy

Performance variances

Assess solution limitations

Identify internal solution component dependencies

Investigate solution problems

Impact assessment

Assess enterprise limitations

Enterprise culture assessment

Stakeholder impact analysis

Organizational structure changes

Operational assessment

Recommend actions to increase solution value

Adjust solution performance measures

Recommendations

505

Appendix C

Mapping Techniques, Stakeholders, and Deliverables to

Knowledge Areas and Tasks

TOPICS COVERED IN THIS APPENDIX:

Mapping techniques to knowledge area tasks

Mapping stakeholders to knowledge area tasks

Mapping deliverables to knowledge area tasks

This appendix provides you with a coverage matrix that maps

the business analysis techniques, deliverables, and stakeholders to the

knowledge area tasks that use them in some way. You can use this matrix to

keep yourself oriented during your exam preparation studies as you work

through the knowledge areas and tasks. These relationships can also be used to

help you determine whether to use a specific deliverable or apply a certain

technique when performing a business analysis task at work.

506

Techniques

The tables in this section (Tables C.1 through C.7) list and then map the

business analysis techniques to the knowledge area tasks that might use them.

The references being used are the knowledge area chapter and the task section

numbers of the BABOK

Guide. An X indicates that a specific technique might

be used by a business analyst performing a particular task.

For example, column header 3.1 references the first task in Chapter 3, “Plan the

Business Analysis Approach (Section 1),” as part of the Business Analysis

Planning and Monitoring knowledge area (Chapter 3). The far-left column in the

table provides you with the chapter and section number for locating the details

about a specific technique.

For a more comprehensive view of this data, see the Techniques sheet in the

BABOKTechniquesMap.xlsx file, available for download at

www.wiley.com/go/Sybextestprep. For your reference, Table C.1 lists all the

techniques found in the BABOK

Guide.

TABLE C.1 Master list of BABOK

Guide techniques

10.1 Acceptance and Evaluation Criteria

10.2 Backlog Management

10.3 Balanced Scorecard

10.4 Benchmarking and Market Analysis

10.5 Brainstorming

10.6 Business Capability Analysis

10.7 Business Cases

10.8 Business Model Canvas

10.9 Business Rules Analysis

10.10 Collaborative Games

10.11 Concept Modelling

10.12 Data Dictionary

10.13 Data Flow Diagrams

10.14 Data Mining

10.15 Data Modelling

10.16 Decision Analysis

10.17 Decision Modelling

10.18 Document Analysis

10.19 Estimation

10.20 Financial Analysis

507

10.21 Focus Groups

10.22 Functional Decomposition

10.23 Glossary

10.24 Interface Analysis

10.25 Interviews

10.26 Item Tracking

10.27 Lessons Learned

10.28 Metrics and Key Performance Indicators (KPIs)

10.29 Mind Mapping

10.30 Nonfunctional Requirements Analysis

10.31 Observation

10.32 Organizational Modelling

10.33 Prioritization

10.34 Process Analysis

10.35 Process Modelling

10.36 Prototyping

10.37 Reviews

10.38 Risk Analysis and Management

10.39 Roles and Permissions Matrix

10.40 Root Cause Analysis

10.41 Scope Modelling

10.42 Sequence Diagrams

10.43 Stakeholder List, Map, or Personas

10.44 State Modelling

10.45 Survey or Questionnaire

10.46 SWOT Analysis

10.47 Use Cases and Scenarios

10.48 User Stories

10.49 Vendor Assessment

10.50 Workshops

TABLE C.2 Business Analysis Planning and Monitoring techniques

Section Technique 3.1 3.2 3.3 3.4 3.5

10.5 Brainstorming X X X X X

10.7 Business Cases X

10.9 Business Rules Analysis X

508

10.18 Document Analysis X X X

10.19 Estimation X

10.20 Financial Analysis X

10.22 Functional Decomposition X

10.25 Interviews X X X X X

10.26 Item Tracking X X X X

10.27 Lessons Learned X X X X X

10.28 Metrics and Key Performance Indicators

(KPIs)

10.29 Mind Mapping X X

10.31 Observation X

10.32 Organizational Modelling X X

10.34 Process Analysis X

10.35 Process Modelling X X X X X

10.36 Prototyping

10.37 Reviews X X X

10.38 Risk Analysis and Management X X X

10.40 Root Cause Analysis X

10.41 Scope Modelling X X

10.43 Stakeholder List, Map, or Personas X

10.45 Survey or Questionnaire X X X X X

10.50 Workshops X X X X X

TABLE C.3 Elicitation and Collaboration techniques

Section Technique 4.1 4.2 4.3 4.4 4.5

10.4 Benchmarking and Market Analysis X

10.5 Brainstorming X X

10.9 Business Rules Analysis X

10.10 Collaborative Games X X

10.11 Concept Modelling X

10.14 Data Mining X X

10.15 Data Modelling X

10.18 Document Analysis X X X

10.19 Estimation X

10.21 Focus Groups X

10.24 Interface Analysis X

509

10.25 Interviews X X X X

10.27 Lessons Learned X

10.29 Mind Mapping X X

10.31 Observation X

10.34 Process Analysis X

10.35 Process Modelling X

10.36 Prototyping X

10.37 Reviews X X

10.38 Risk Analysis and Management X X

10.43 Stakeholder List, Map, or Personas X X

10.45 Survey or Questionnaire X

10.50 Workshops X X X

TABLE C.4 Requirements Life Cycle Management techniques

Section Technique 5.1 5.2 5.3 5.4 5.5

10.1 Acceptance and Evaluation Criteria X

10.2 Backlog Management X

10.7 Business Cases X X

10.9 Business Rules Analysis X X X

10.13 Data Flow Diagrams X

10.15 Data Modelling X

10.16 Decision Analysis X X X

10.18 Document Analysis X X

10.19 Estimation X X

10.20 Financial Analysis X X

10.22 Functional Decomposition X X

10.24 Interface Analysis X

10.25 Interviews X X

10.26 Item Tracking X X X

10.33 Prioritization X

10.34 Process Analysis

10.35 Process Modelling X X

10.37 Reviews X

10.38 Risk Analysis and Management X X

10.41 Scope Modelling X

10.47 Use Cases and Scenarios X

510

10.48 User Stories X

10.50 Workshops X X X

TABLE C.5 Strategy Analysis techniques

Section Technique 6.1 6.2 6.3 6.4

10.1 Acceptance and Evaluation Criteria X

10.3 Balanced Scorecard X X

10.4 Benchmarking and Market Analysis X X X

10.5 Brainstorming X X X

10.6 Business Capability Analysis X X X

10.7 Business Cases X X X X

10.8 Business Model Canvas X X X

10.11 Concept Modelling X

10.14 Data Mining X

10.16 Decision Analysis X X X

10.17 Decision Modelling X

10.18 Document Analysis X X

10.19 Estimation X

10.20 Financial Analysis X X X X

10.21 Focus Groups X X

10.22 Functional Decomposition X X X

10.25 Interviews X X X X

10.26 Item Tracking X

10.27 Lessons Learned X X X X

10.28 Metrics and Key Performance Indicators (KPIs) X X

10.29 Mind Mapping X X X X

10.31 Observation X

10.32 Organizational Modelling X X X

10.34 Process Analysis X

10.35 Process Modelling X X X

10.36 Prototyping X

10.38 Risk Analysis and Management X X

10.40 Root Cause Analysis X X

10.41 Scope Modelling X X X

10.45 Survey or Questionnaire X X X

10.46 SWOT Analysis X X X

511

10.49 Vendor Assessment X X X

10.50 Workshops X X X X

TABLE C.6 Requirements Analysis and Design Definition techniques

Section Technique 7.1 7.2 7.3 7.4 7.5 7.6

10.1 Acceptance and Evaluation Criteria X X X X

10.2 Backlog Management X

10.4 Benchmarking and Market Analysis X

10.5 Brainstorming X X

10.6 Business Capability Analysis X

10.7 Business Cases X

10.8 Business Model Canvas X X

10.9 Business Rules Analysis X

10.11 Concept Modelling X

10.12 Data Dictionary X

10.13 Data Flow Diagrams X

10.15 Data Modelling X X

10.16 Decision Analysis X

10.17 Decision Modelling X

10.18 Document Analysis X X

10.19 Estimation X

10.20 Financial Analysis X X

10.21 Focus Groups X

10.22 Functional Decomposition X X

10.23 Glossary X

10.24 Interface Analysis X

10.25 Interviews X X X

10.26 Item Tracking X X

10.27 Lessons Learned X

10.28 Metrics and Key Performance Indicators

(KPIs)

X X X

10.29 Mind Mapping X

10.30 Nonfunctional Requirements Analysis X

10.32 Organizational Modelling X X

10.35 Process Modelling X

10.36 Prototyping X

512

10.37 Reviews X X

10.38 Risk Analysis and Management X X

10.39 Roles and Permissions Matrix X

10.40 Root Cause Analysis X X

10.41 Scope Modelling X X

10.42 Sequence Diagrams X

10.43 Stakeholder List, Map, or Personas X

10.44 State Modelling X

10.45 Survey or Questionnaire X X

10.46 SWOT Analysis X

10.47 Use Cases and Scenarios X

10.48 User Stories X

10.49 Vendor Assessment X

10.50 Workshops X X X

TABLE C.7 Solution Evaluation techniques

Section Technique 8.1 8.2 8.3 8.4 8.5

10.1 Acceptance and Evaluation Criteria X X X

10.4 Benchmarking and Market Analysis X X X X

10.5 Brainstorming X

10.7 Business Cases X

10.9 Business Rules Analysis X

10.14 Data Mining X X X X X

10.15 Data Modelling

10.16 Decision Analysis X X X X

10.18 Document Analysis X

10.20 Financial Analysis X

10.21 Focus Groups X X

10.25 Interviews X X X

10.26 Item Tracking X X

10.27 Lessons Learned X X

10.28 Metrics and Key Performance Indicators

(KPIs)

X X

10.30 Nonfunctional Requirements Analysis X

10.31 Observation X X X

10.32 Organizational Modelling X X

513

10.33 Prioritization X

10.34 Process Analysis X X

10.35 Process Modelling X

10.36 Prototyping X

10.38 Risk Analysis and Management X X X X

10.39 Roles and Permissions Matrix X

10.40 Root Cause Analysis X X X

10.45 Survey or Questionnaire X X X X X

10.46 SWOT Analysis X

10.47 Use Cases and Scenarios X

10.49 Vendor Assessment X

10.50 Workshops X

514

Stakeholders

The tables in this section (Tables C.8 through C.13) map the business analysis

stakeholders to the knowledge area tasks in which they might participate. The

references being used are the knowledge area chapter and the task section

numbers of the BABOK

Guide. An X indicates that a specific stakeholder role

may participate in a particular task.

The tables map the business analyst role to every business analysis task in the

BABOK

Guide. The business analysts’ level of involvement (whether formal or

informal) is not explicitly stated in the list of stakeholders for every task.

The task is identified by its chapter and section number. For example, the

column header 3.1 references the first task in Chapter 3, “Plan the Business

Analysis Approach (Section 1),” as part of the Business Analysis Planning and

Monitoring knowledge area (Chapter 3).

For a more comprehensive view, see the Stakeholders sheet in the

BABOKTechniquesMap.xlsx file, available for download at

www.wiley.com/go/Sybextestprep.

TABLE C.8 Business Analysis Planning and Monitoring stakeholders

Stakeholder 3.1 3.2 3.3 3.4 3.5

Business Analyst X X X X X

Customer X

Domain SME X X X X X

End User X

Project Manager X X X X

Regulator X X X X

Sponsor X X X X X

Supplier X

TABLE C.9 Elicitation and Collaboration stakeholders

Stakeholder 4.1 4.2 4.3 4.4 4.5

Business Analyst X X X X X

Customer X X

Domain SME X X X X

End User X X

Implementation SME X X

Project Manager X

Sponsor X X

515

Tester X

Any Stakeholder X X X

All Stakeholders X

TABLE C.10 Requirements Life Cycle Management stakeholders

Stakeholder 5.1 5.2 5.3 5.4 5.5

Business Analyst X X X X X

Customer X X X X

Domain SME X X X X

End User X X X X

Implementation SME X X X

Operational Support X X X X

Project Manager X X X X

Regulator X X X X

Sponsor X X X X

Supplier X

Tester X X X X

TABLE C.11 Strategy Analysis stakeholders

Stakeholder 6.1 6.2 6.3 6.4

Business Analyst X X X X

Customer X X X

Domain SME X X X X

End User X X X

Implementation SME X X X X

Operational Support X X X X

Project Manager X X X X

Regulator X X X X

Sponsor X X X X

Supplier X X X X

Tester X X X X

TABLE C.12 Requirements Analysis and Design Definition stakeholders

Stakeholder 7.1 7.2 7.3 7.4 7.5 7.6

Business Analyst X X X X X X

Customer X

Domain SME X X X

516

End User X

Implementation SME X X X

Operational Support X

Project Manager X X X

Regulator X

Sponsor X X

Supplier X

Tester X

Any Stakeholder X X

All Stakeholders X X

TABLE C.13 Solution Evaluation stakeholders

Stakeholder 8.1 8.2 8.3 8.4 8.5

Business Analyst X X X X X

Customer X X X X

Domain SME X X X X X

End User X X X X

Project Manager X X

Regulator X X X X

Sponsor X X X X X

Tester X

517

Deliverables

The tables in this section (Tables C.14 through C.19) map the business analysis

deliverables to the knowledge area tasks that use them as inputs or produce

them as outputs. Some of the deliverables are not part of the BABOK

Guide

and may be generated by the organization or by the project’s technical team

members during design and development. The references being used are the

knowledge area chapter and the task section numbers of the BABOK

Guide. An

I indicates that a specific deliverable is used by a particular task as an input. An

O indicates that a specific deliverable is produced as an output by a task. A GT

indicates that a deliverable is used as a guideline or tool when that deliverable is

an input to a particular task.

Each task is identified by its chapter and section number. For example, column

header 3.1 references the first task in Chapter 3 of the BABOK

Guide, “Plan the

Business Analysis Approach (Section 1),” as part of the Business Analysis

Planning and Monitoring knowledge area (Chapter 3).

For a more comprehensive view, see the Deliverables sheet in the

BABOKTechniquesMap.xlsx file, available for download at

www.wiley.com/go/Sybextestprep.

TABLE C.14 Business Analysis Planning and Monitoring inputs,

guidelines/tools, and outputs

BA Deliverables 3.1 3.2 3.3 3.4 3.5

Business Analysis Approach O I I I I

Business Analysis Performance Assessment GT GT GT GT O

Business Policies GT GT GT

Change Strategy GT

Current State Description GT GT

Expert Judgment GT

Governance Approach O I

Information Management Approach O

Information Management Tools GT

Legal/Regulatory Information GT GT

Methodologies and Frameworks GT

Needs I I

Organizational Performance Standards GT

Performance Objectives (external) I

Stakeholder Engagement Approach GT O I I

518

TABLE C.15 Elicitation and Collaboration inputs, guidelines/tools, and

outputs

BA Deliverables 4.1 4.2 4.3 4.4 4.5

Business Analysis Approach GT GT GT GT

Business Analysis Information I

Business Analysis Information (communicated) O

Business Analysis Performance Assessment I

Business Objectives GT GT

Elicitation Activity Plan O I GT

Elicitation Results (confirmed) O

Elicitation Results (unconfirmed) O I

Enterprise Limitation

Existing Business Analysis Information GT GT GT

Future State Description GT

Information Management Approach GT

Needs I

Potential Value GT

Recommended Actions GT

Risk Analysis Results GT

Stakeholder Engagement O

Stakeholder Engagement Approach I GT I I

Supporting Materials GT

TABLE C.16 Requirements Life Cycle Management inputs, guidelines/tools,

and outputs

BA Deliverables 5.1 5.2 5.3 5.4 5.5

Business Constraints GT

Change Strategy GT GT GT

Designs I I I I I

Designs (approved) O

Designs (maintained) O

Designs (prioritized) O

Designs (traced) O

Designs Change Assessment O

Domain Knowledge GT GT GT

Governance Approach GT GT GT

519

Information Management Approach GT GT

Legal/Regulatory Information GT GT GT

Proposed Change I

Requirements I I I I

Requirements (approved) O

Requirements (maintained) O

Requirements (prioritized) O

Requirements (traced) O

Requirements (verified) I

Requirements Architecture GT GT

Requirements Change Assessment O

Requirements Management Tools/Repository GT GT GT

Solution Scope GT GT GT

TABLE C.17 Strategy Analysis inputs, guidelines/tools, and outputs

BA Deliverables 6.1 6.2 6.3 6.4

Business Analysis Approach GT GT GT

Business Objectives O I

Business Policies GT

Business Requirements O I

Change Strategy GT O

Constraints

Current State Description O GT GT I

Design Options GT

Designs (prioritized) I

Elicitation Results (confirmed) I I

Enterprise Limitation GT

Future State Description O GT I

Identified Risks GT

Influences (internal and external) I

Metrics and KPIs GT

Needs I

Organizational Strategy GT GT

Potential Value O I

Requirements (prioritized) I

Risk Analysis Results O I

520

Solution Limitation GT

Solution Performance Goals GT

Solution Performance Measures GT

Solution Recommendations GT

Solution Scope O

Stakeholder Analysis Results GT

Stakeholder Engagement Approach GT I

TABLE C.18 Requirements Analysis and Design Definition inputs,

guidelines/tools, and outputs

BA Deliverables 7.1 7.2 7.3 7.4 7.5 7.6

Architecture Management Software GT

Business Objectives GT GT

Change Strategy I

Current State Description GT

Design Options O I

Elicitation Results (any state) I

Existing Solutions GT

Future State Description GT GT GT

Information Management Approach I

Legal/Regulatory Information GT

Methodologies and Frameworks GT

Modelling Notations/Standards GT

Modelling Tools GT

Potential Value GT I

Requirements (any state) I

Requirements (specified & modelled) O I I

Requirements (traced) GT

Requirements (validated & prioritized) I

Requirements (validated) O

Requirements (verified) O

Requirements Architecture GT O I

Requirements Life Cycle Management Tools GT GT

Risk Analysis Results GT

Solution Recommendation O

Solution Scope GT GT I GT GT

521

TABLE C.19 Solution Evaluation inputs, guidelines/tools, and outputs

BA Deliverables 8.1 8.2 8.3 8.4 8.5

Business Objectives I GT GT

Change Strategy GT GT GT GT

Current State Description I GT

Enterprise Limitation O I

Future State Description GT GT GT

Implemented Solution (external) I I I

Potential Value I

Recommended Actions O

Requirements (validated) GT

Risk Analysis Results GT GT GT

Solution Limitation O I

Solution Performance Analysis O I I

Solution Performance Measures O I

Solution Scope GT GT GT GT GT

522

Appendix D

Summary of Business Analysis Techniques

TOPICS COVERED IN THIS APPENDIX:

Define a business analysis technique.

Review brief descriptions of the BABOK

Guide techniques.

This appendix reviews the definition of a technique and

provides a table that describes each technique in the BABOK

Guide. This

should refresh your memory about the high-level descriptions of each business

analysis technique you might see on your certification exam or use at work.

523

Business Analysis Techniques

The BABOK

Guide has 50 business analysis techniques. These techniques are

the methods and best practices used by many business analysts to perform

business analysis work. These techniques offer you options for how business

analysis tasks might be performed.

Experienced business analysts are expected to be skilled in many of these

techniques. Although you are not expected to be proficient in all of them, you

should master a decent subset of business analysis techniques that work for you.

Remember to apply your own experience and judgment when selecting and

applying one or more techniques as part of your business analysis activities.

Quick Review of Techniques

Table D.1 defines the business analysis techniques in the BABOK

Guide. They

are defined for you in much more detail in Chapter 10 of the BABOK

Guide.

TABLE D.1 Business analysis techniques

Technique Description

Acceptance

and evaluation

criteria

Acceptance criteria define a set of requirements that must be

met for a new solution to be acceptable to its stakeholders.

Evaluation criteria are metrics and indicators used to assess

how an operational solution meets its objectives over time.

Backlog

management

Recording, tracking, and prioritizing the remaining work that

needs to be done. Prioritization of work in the managed

backlog is typically done based upon the business value of the

work activity.

Balanced

scorecard

Measures organizational performance and value creation

relative to the organization’s strategic plan as a framework of

objectives and performance measures

Benchmarking

and market

analysis

Comparing organizational practices or processes against best-

in-class practices or processes of peer organizations to identify

opportunities for improvement

Brainstorming Generating creative ideas and options to solve a problem or

meet a business need in a noncritical group environment

Business

capability

analysis

Describing the business capabilities of the enterprise relative to

achieving a business goal or objective

Business cases Justifying a course of action based upon the costs and business

benefits of a proposed solution

Business

model canvas

Uses nine building blocks to describe how an enterprise

creates, delivers, and captures value to and from its customers

524

Business rules

analysis

Modelling and analyzing the business principles and processes

that define, constrain, and/or enable business operations and

decision making

Collaborative

games

Used when eliciting business analysis information to encourage

participants to collaborate in building a joint understanding of

a problem or a solution

Concept

modelling

Developing the core concepts of a problem, defining the

structure of the core concepts, and specifying the vocabulary to

be used

Data

dictionary

Collections of definitions used to explain the terminology used

by the business and the data relevant to each business domain

Data flow

diagrams

Drawings used to visually represent how information moves

through a system by showing the external entities, processes,

data storage, and data flow

Data mining Using mathematical models to examine large amounts of data

to find useful patterns and relationships from the data

Data

modelling

Describing and diagramming the concepts relevant to a

business area, the relationships between these concepts, and

information associated with them

Decision

analysis

Examining and modelling the possible consequences of

different decisions to make the optimal decision under

uncertain conditions

Decision

modelling

Showing how repeatable decisions are made by combining data

and knowledge

Document

analysis

Eliciting the requirements for an existing system by studying

available documentation and identifying any other relevant

information

Estimation Developing the possible range of costs and effort associated

with business analysis work on your project

Financial

analysis

Assessing the financial viability, stability, and benefit

realization of a solution, solution approach, or investment

Focus groups Collections of people used to elicit ideas and attitudes about a

specific product, service, or opportunity in an interactive

environment

Functional

decomposition

Decomposing business processes, functional areas, or

deliverables into smaller parts in order to analyze the parts

independently

Glossary Defines key terms for stakeholders so everyone uses a common

business language to communicate and exchange ideas

Interface

analysis

Clarifying the boundaries and interfaces between solutions and

solution components and defining the requirements describing

how they will interact with one another

Interviews Systematic conversations used to elicit information from a

525

person or group of people in an informal or formal setting by

asking questions and documenting the responses

Item tracking Capturing, assigning, and managing the responsibility for

addressing the recorded stakeholder concerns and issues

Lessons

learned

Learning about and improving a project or process by

compiling and documenting successes, opportunities for

improvement, failures, and recommendations for improving

performance

Metrics and

key

performance

indicators

(KPIs)

Measurements used to indicate the performance of solutions,

solution components, and other matters of interest to your

stakeholders

Mind mapping Using a nonlinear diagram to articulate and capture thoughts,

ideas, and information about a problem or concept

Nonfunctional

requirements

analysis

Describing qualities and characteristics of a system or solution,

such as usability and performance

Observation Assessing needs and eliciting requirements by watching how

stakeholders work within their work environment

Organizational

modelling

Describing roles, responsibilities, and reporting structures that

exist within an organization

Prioritization Determining the relative importance of a set of things and

determining the order in which they will be addressed

Process

analysis

Assessing processes for efficiency and effectiveness and

recommending improvements or changes

Process

modelling

Visually modelling the sequential flow and control logic of a set

of related activities or actions

Prototyping Building a partial or preliminary version of a system or

solution as part of your requirements development activities

Reviews An organized peer review of a deliverable, looking for errors

and omissions

Risk analysis

and

management

Assessing an identified risk and deciding on a response to that

risk

Roles and

permissions

matrix

Using a matrix to identify roles, associate the roles with

activities, and define the levels of authority associated with

each role and activity

Root-cause

analysis

Performing a structured examination of an identified problem

to understand the underlying causes of that problem

Scope

modelling

Defining the boundaries of a business domain or solution

526

Sequence

diagrams

Drawings used to show how objects interact during a scenario

and the messages they exchange with one another

Stakeholder

list, map, or

personas

Analyzing stakeholders and their involvement with a project

using lists, matrices, or archetypes

State

modelling

Drawings used to show the life cycle of a data entity or class

Survey or

questionnaire

A set of written questions to stakeholders to collect responses

from a large group in a relatively short period of time

SWOT

analysis

An evaluation of influencing factors and how they affect a

project by looking at strengths, weaknesses, opportunities, and

threats

Use cases and

scenarios

Diagrammed and textual stories used to describe the tasks a

system or solution will perform for actors and the goals that

the system will achieve for those actors

User stories High-level, informal, and short descriptions of a solution

capability for a stakeholder in one or two sentences

Vendor

assessment

An evaluation of the ability of a potential vendor to meet

commitments regarding providing you with a product or

service

Workshops Structured and facilitated meetings for a carefully selected

group of stakeholders to collaborate and define/refine

requirements

527

Appendix E

Summary of Business Analysis Outputs

528

TOPICS COVERED IN THIS APPENDIX:

Define a business analysis output.

List and briefly describe the BABOK

Guide outputs.

Appendix E reviews the definition of a business analysis

output and provides a table briefly describing each output in the BABOK

Guide. This should refresh your memory about the high-level descriptions of

each business analysis output that you might see on your certification exam or

use back at work.

529

Business Analysis Outputs

The BABOK

Guide recommends and defines a set of outputs that you can

tailor and use when planning for, defining, and managing your project's

business analysis efforts. These outputs are not always documents; they can also

be information sets that you use to measure business analysis performance, take

action, and make the right decisions at the right time. These outputs evolve over

the project life cycle and are often reviewed and updated as the project and its

associated business analysis efforts progress.

Table E.1 through Table E.6 list and define the outputs produced by the tasks in

the BABOK

Guide knowledge areas. It also provides the knowledge area and

task where each output is produced. Outputs used as task inputs, guidelines, or

tools that are produced outside of the scope of the BABOK

Guide and its tasks

are not addressed here.

TABLE E.1 Summary of Business Analysis Planning and Monitoring outputs

Output Brief Description Task

Business

analysis

approach

Defines the set of processes, templates,

techniques, and activities used to perform

business analysis on a project or initiative

Plan business

analysis

approach.

Business

analysis

performance

assessment

Compares planned versus actual estimates for

business analysis activities to determine the

level of effort required to complete the work

Identify business

analysis

performance

improvements.

Governance

approach

Identifies stakeholder decision-making

responsibility and authority for business

analysis work

Plan business

analysis

governance.

Information

management

approach

Defines how business analysis information

will be stored, accessed, and used, both during

the project and after the proposed change is

complete

Plan business

analysis

information

management.

Stakeholder

engagement

approach

Lists stakeholders and their characteristics,

roles, and responsibilities for the project or

proposed change

Plan stakeholder

engagement.

TABLE E.2 Summary of Business Analysis Elicitation and Collaboration

outputs

Output Brief Description Task

Elicitation

activity plan

Contains planned elicitation activities,

any associated logistics, selected

techniques, and supporting materials

Prepare for

elicitation.

Elicitation results Captured business analysis information in Conduct

530

(unconfirmed) a format specified by the elicitation

activity

elicitation.

Elicitation results

(confirmed)

Integrated business analysis information

provided by the stakeholders and agreed

upon as correct

Confirm

elicitation

results.

Business analysis

information

(communicated)

Business analysis information that

stakeholders understand

Communicate

business analysis

information.

Stakeholder

engagement

Willingness from stakeholders to engage

in business analysis activities and interact

with the business analyst

Manage

stakeholder

collaboration.

TABLE E.3 Summary of Business Analysis Requirements Life Cycle

Management outputs

Output Brief Description Task

Requirements

(traced)

Requirements with clearly defined relationships

to other requirements or designs within the

solution scope

Trace

requirements.

Designs

(traced)

Designs with clearly defined relationships to

other requirements or designs within the

solution scope

Trace

requirements.

Requirements

(maintained)

Requirements formatted for long-term use by

the organization

Maintain

requirements.

Designs

(maintained)

Designs formatted for long-term use by the

organization

Maintain

requirements.

Requirements

(prioritized)

Requirements prioritized relative to one another

based on relative importance to stakeholders and

the organization

Prioritize

requirements.

Designs

(prioritized)

Designs prioritized relative to one another based

on relative importance to stakeholders and the

organization

Prioritize

requirements.

Requirements

change

assessment

Recommends whether or not to approve, modify,

or deny a proposed change to requirements

Assess

requirements

changes.

Designs

change

assessment

Recommends whether or not to approve, modify,

or deny a proposed change to one or more design

components

Assess

requirements

changes.

Requirements

(approved)

Requirements agreed to by stakeholders and

ready for use in subsequent business analysis

activities

Approve

requirements.

Designs

(approved)

Designs agreed to by stakeholders and ready for

use in subsequent business analysis activities

Approve

requirements.

531

TABLE E.4 Summary of Business Analysis Strategy Analysis outputs

Output Brief Description Task

Current state

description

Provides the “as is” state of the enterprise relative to

scope, capabilities, resources, performance,

dependencies, and infrastructure

Analyze

current

state.

Business

requirements

Defines the problem, opportunity, or constraint based

upon the current state

Analyze

current

state.

Business

objectives

Points to the desired direction the business will take to

achieve the future state

Define

future

state.

Future state

description

Defines the “to be” state of the enterprise and the

potential value expected from the future state

Define

future

state.

Potential

value

Value that may be realized when the future state is

implemented

Define

future

state.

Risk analysis

results

Contains identified risks associated with the future

state and strategies to address those risks

Assess

risks.

Change

strategy

Describes the approach the organization will follow to

guide change

Define

change

strategy.

Solution

scope

Defines the set of capabilities that must be delivered to

meet the business need and the effect the capabilities

will have on business and technology operations and

infrastructure

Define

change

strategy.

TABLE E.5 Summary of Business Analysis Requirements Analysis and Design

Definition outputs

Output Brief Description Task

Requirements

(specified and

modelled)

Contains any combination of requirements

and/or designs as text, matrices, and

diagrams

Specify and

model

requirements.

Requirements

(verified)

Requirements of sufficient quality to allow

further work

Verify

requirements.

Requirements

(validated)

Requirements that deliver value to

stakeholders and align with business goals

and objectives

Validate

requirements.

Requirements

architecture

Contains requirements, the

interrelationships between them, and

contextual information

Define

requirements

architecture.

Design options Describe various options for satisfying the

solution approach as well as potential

Define design

options.

532

improvement opportunities each option

provides

Solution

recommendation

Identifies the suggested solution with

maximum enterprise value based upon

evaluating all design options

Analyze

potential value

and recommend

solution.

TABLE E.6 Summary of Business Analysis Solution Evaluation outputs

Output Brief Description Task

Solution

performance

measures

Provide information on how well a solution is

performing or could perform

Measure

solution

performance.

Solution

performance

analysis

Contains analysis results of collected

measurements and recommendations to

solve performance gaps and leverage

opportunities

Analyze

performance

measures.

Solution

limitation

Describes current limitations of the solution

including constraints and defects

Assess solution

limitations.

Enterprise

limitation

Describes the current limitations of the

enterprise and how solution performance

impacts it

Assess

enterprise

limitations.

Recommended

actions

Recommendations that guide solution

improvements

Recommend

actions to

increase

solution value.

533

Appendix F

Answers to Review Questions

534

Chapter 1: Foundation Concepts

1. C. A solution is a set of changes to the current state of an organization made

in order to enable the organization to meet a business need, solve a problem,

or take advantage of an opportunity. It is the basis for the project scope that

implements the solution and its components.

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

assessing feasibility and building a business case for a potential business

initiative.

3. D. The business analyst is responsible for understanding the business

problems and opportunities in the context of the requirements.

4. B. One definition for a requirement is a condition or capability needed by a

stakeholder either to solve a problem or to achieve an objective.

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

facilitate transitioning from the current to the desired future state. They are

not needed once the transition is complete and cannot be created until both

the current and new solutions have been defined.

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

objectives.

7. D. Inputs represent information and preconditions necessary for a task to

begin. They are produced externally by a single task.

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

needs and determine solutions to business problems.

9. C. Knowledge areas define what a business analyst needs to understand and

the tasks they need to perform. They do not define a methodology or indicate

project phases as tasks may be done in any order as long as their inputs are

available.

10. D. The deliverables produced by the Strategy Analysis tasks that make up the

business requirements include the business need, the required capabilities,

the solution scope, and the business case.

11. B. Building a business case is typically done as part of Strategy Analysis

activities. The next most logical knowledge area applied after Strategy

Analysis is completed would be Business Analysis Planning and Monitoring

where requirements-related resources and tasks are defined.

12. B. Requirements Planning and Monitoring is not a knowledge area. The six

knowledge areas are Business Analysis Planning and Monitoring, Elicitation

and Collaboration, Requirements Life Cycle Management, Strategy Analysis,

Requirements Analysis and Design Definition, and Solution Evaluation.

13. D. The approved requirements are agreed to by stakeholders and ready for

use in subsequent business analysis or implementation efforts.

14. C. Business Analysis Planning and Monitoring defines requirement-related

535

resources and tasks throughout the requirements development process.

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

known as requirements elicitation.

16. B. Inputs are the information and preconditions necessary for a business

analysis task to begin. They may be generated outside of the scope of

business analysis or generated by a business analysis task.

17. A. Problem solving involves measuring alternatives against objectives and

identifying trade-offs to determine which possible solution is best.

18. D. The business analysis approach defines the methodology used for

business analysis work on the overall project and each of its phases. It

includes team roles, deliverables to be produced, how and when tasks are

performed, techniques to be used, and other aspects of the high-level

business analysis process.

19. B. The business analyst is responsible for ensuring the feasibility of proposed

requirements when defining, describing, and refining the characteristics of

an acceptable solution as part of Requirements Analysis and Design

Definition activities.

20. A. Solution requirements describe the capabilities and qualities of a solution

that meets the stakeholder requirements. Functional requirements, a subset

of the solution requirements, could also be a correct answer to this question,

although they were not one of the potential answers provided.

536

Chapter 2: Controlled Start: Business Analysis Planning

and Monitoring

1. B. The Business Analysis Planning and Monitoring knowledge area contains

tasks for planning and monitoring of business analysis activities throughout

the project, including reporting on and identifying performance

improvements.

2. A. Predictive business analysis approaches are used when most of the

business analysis work occurs at the beginning of the project or during one

single project phase.

3. D. The 15 techniques that can be used when determining the business

analysis approach are: brainstorming, business cases, document analysis,

estimation, financial analysis, functional decomposition, interviews, item

tracking, lessons learned, process modelling, reviews, risk analysis and

management, scope modelling, survey or questionnaire, and workshops.

4. B. The project manager is responsible for ensuring that the business analysis

plan is compatible with the project plan.

5. A. Needs, or more specifically business needs, are the key input used when

planning the business analysis approach for a project. The business need

defines the problem or opportunity faced by the organization.

6. C. The acronym RACI stands for Responsible, Accountable, Consulted, and

Informed. This is a technique used when conducting stakeholder analysis.

7. C. Urgency is the requirements attribute that indicates how soon the

requirement is needed. This attribute is usually specified separately from

priority when you have an implementation deadline to meet.

8. B. Stakeholder analysis is performed as soon as a business need is identified

and is an ongoing activity as long as business analysis work is being done on

a project. It is typically conducted prior to (not during) the project phase it

applies to because the business analysis team needs to know the key

stakeholders in order to plan effectively for that phase.

9. D. The tasks in the Business Analysis Planning and Monitoring knowledge

area are planning the business analysis approach, planning the stakeholder

engagement approach (which includes stakeholder analysis), planning

business analysis governance, planning business analysis information

management, and identifying business analysis performance improvements.

10. C. The business analyst is a key stakeholder for all business analysis tasks on

a project.

11. B. Metrics and key performance indicators (KPIs) is the technique that

allows you to determine the metrics used for measuring performance and

determining how those metrics may be tracked as part of identifying

business analysis process improvements.

537

12. B. The stakeholder engagement approach describes how, when, and why the

business analyst will work directly with stakeholders relative to any business

analysis task.

13. B. The six elements of planning business analysis information management

are as follows: organization of business analysis information, level of

abstraction, plan traceability, plan reuse, storage and access, and

requirements attributes.

14. B. A metric is a quantitative measure of a process or product describing what

is to be measured.

15. C. The business analysis performance assessment is an input or guideline for

all tasks found in the Business Analysis Planning and Monitoring knowledge

area.

16. B. The functional decomposition technique is used when planning business

analysis activities to decompose the products of your project (a solution

breakdown structure) or to decompose project tasks (a work breakdown

structure).

17. B. The BABOK® Guide recommends business analysts begin their planning

efforts by building their business analysis approach, defining the business

analysis methodology to be used across the project life cycle. Concurrently,

the business analysis team also identifies, analyzes, and categorizes the

business analysis stakeholders with which they will be working as part of the

stakeholder engagement approach.

18. B. The Business Analysis Approach deliverable that is built as part of the

Business Analysis Planning and Monitoring knowledge area defines the

project’s approach to traceability.

19. C. Requirements that are potential candidates for reuse include regulatory

requirements, contractual obligations, quality standards, service level

agreements, business rules or processes, and product requirements.

20. C. The business analysis governance approach defines the components of a

request for change, including the cost and time estimates of the requested

change, its associated benefits and risks, and the recommended course of

action for the change.

538

Chapter 3: Controlled Start: Strategy Analysis

1. B. All of the Strategy Analysis tasks are governed by the business analysis

approach created as part of the Business Analysis Planning and Monitoring

knowledge area.

2. B. The Strategy Analysis task “Define change strategy” produces the solution

scope as an output. Option D is a tempting choice, but “Define solution

scope” is not an actual task in the Strategy Analysis knowledge area.

3. D. Strategy Analysis tasks develop the business requirements for the project

by defining the business need, business case, solution scope, and required

capabilities.

4. A. The solution is the outcome of a change that allows an enterprise to satisfy

a need.

5. D. The business need defines the problem for which the business analyst is

trying to find a solution.

6. C. Industry structure might present constraints, dependencies, or drivers on

the current state of the enterprise. This area is a source of external

influencers found when analyzing the current state.

7. B. The change strategy contains the results of the business analyst assessing

the capability gaps between the existing and new capabilities of the

organization.

8. B. The five elements that are part of the assess risks task are unknowns,

constraints/assumptions/dependencies, negative impact to value, risk

tolerance, and recommendations.

9. D. The four dimensions of a balanced scorecard are learning and growth,

business process, customer, and financial.

10. C. When building a change strategy, decision analysis can be used to

compare the costs of implementing a proposed solution against the benefits

to be gained.

11. C. Analyzing the current state and its capabilities has eight elements:

business needs, organizational structure and culture, capabilities and

processes, technology and infrastructure, policies, business architecture,

internal assets, and external influences. The scope of decision making at

different levels in the organization is part of the policies element.

12. B. The sponsor typically approves the business case and authorizes funding

for the resulting project.

13. B. The document analysis technique allows the business analyst to leverage

existing materials to analyze the current state of the enterprise relative to a

business need during Strategy Analysis.

14. B. During Strategy Analysis, two tasks (analyzing the current state and

defining the future state) are usually completed before the business analyst

539

assesses the risks and builds the change strategy and defines the solution

scope.

15. A. The change strategy contains the preliminary analysis of solution

alternatives or options to determine how and whether each option can

provide an expected business benefit.

16. B. Business objectives describe the specific and measurable ends that an

organization is seeking to achieve.

17. B. Defining a business need from the bottom up occurs when you are looking

at the current state of an existing system and trying to figure out how to

improve the efficiency of that system.

18. D. When defining solution scope, the implementation SME participates in

allocating capabilities to solution components and determining what is

required to deliver these new capabilities.

19. C. During Strategy Analysis, functional decomposition is used to break down

business goals into achievable objectives and measures.

20. A. The solution scope and change strategy have been defined when the

Strategy Analysis knowledge area activities are complete. Other key

deliverables and outputs from this knowledge area include business

requirements and business objectives.

540

Chapter 4: Overarching Tasks: Requirements Life Cycle

Management

1. C. The approve requirements task may result in approval and sign-off on the

requirements or designs.

2. D. The governance approach determines how to communicate with

stakeholders and provides a basis for meeting and communication

expectations.

3. C. The project manager is responsible and accountable for the project scope,

assessing the solution scope in order to define the project scope as part of the

Requirements Life Cycle Management knowledge area.

4. C. The BACCM™ states that the business analyst is responsible for extending

value beyond the current initiative they are working on by maintaining

requirements and designs for reuse.

5. A. The solution and stakeholder requirements on a project must be traceable

to a business requirement.

6. D. The three business analysis deliverables are inputs to several

Requirements Life Cycle Management tasks used to influence and guide the

business analyst in managing requirements are the governance approach,

the change strategy, and the information management approach.

7. A. Making sure that the business analysis team traces the relationship

between functional requirements and the solution components that

implement those requirements is an example of the Satisfy traceability

relationship.

8. C. The tasks in the Requirements Life Cycle Management knowledge area are

performed to ensure that all stakeholders have a shared understanding of

the nature of a solution and to ensure that those stakeholders with approval

authority are in agreement as to the requirements that the solution shall

meet.

9. C. The four techniques that may be used when tracing requirements include

business rules analysis, functional decomposition, process modelling, or

scope modelling.

10. B. The requirements output from the Requirements Life Cycle Management

knowledge area include approved, prioritized, maintained, and traced

requirements.

11. A. Structured walkthroughs are organized peer-level or team reviews of

project deliverables, such as requirements. Attendees are looking for errors

or omissions in the requirements.

12. B. Requirements that are intended for reuse reflect the current state of the

organization.

541

13. C. The stability prioritization factor takes into account the likelihood that a

requirement will change, because either it needs further analysis or there is a

lack of stakeholder consensus.

14. D. The requirements architecture is used during requirements prioritization

to understand the relationship with other requirements and work products.

15. B. The business analyst typically receives input from the implementation

SME regarding the impacts of technical dependencies on a specific

stakeholder requirement.

16. C. Requirements tracing may be done at the individual requirement level, at

the model level, at the package level, or at the feature level.

17. A. The requirements life cycle begins with the representation of a business

need as a requirement and ends when a solution representing the

requirements is retired.

18. D. When assessing a proposed change to a set of project requirements for an

adaptive development approach with iterative and incremental

implementation techniques, the resulting impact analysis may be informal.

19. C. The solution scope is the basis for requirements management during a

project, ensuring that proposed requirements support business goals and

objectives.

20. A. The four elements of the approve requirements task are understand

stakeholder roles, conflict and issue management, gain consensus, and track

and communicate approval.

542

Chapter 5: Controlled Middle: Elicitation and

Collaboration

1. A. Elicitation knowledge area tasks include prepare for elicitation, conduct

elicitation activity, document elicitation results, and confirm elicitation

results.

2. D. Document analysis results in improved requirements coverage as long as

the documents being reviewed are up-to-date (current) and valid.

3. B. Brainstorming involves preparing, conducting, and wrapping up. This is

true for all 10 techniques used to elicit requirements.

4. C. When conducting an active observation, the business analyst or observer

should take detailed notes and ask probing questions about why certain

tasks are being done.

5. C. Evolutionary prototypes allow designers and developers to learn about

user interface needs and evolve the system requirements.

6. A. Any stakeholder can participate in requirements elicitation activities.

7. A. Closed-ended questions elicit a single response, such as yes or no.

8. B. Stakeholder engagement is defined as the willingness of stakeholders to

actively work and interact with the business analysis team.

9. B. Observation assesses the individual’s work environment to document

details about current processes.

10. A. Active, or visible, observation is when the business analyst observes the

individual performing their job and asks questions and talks with the worker

while they are performing the work.

11. C. The Elicitation knowledge area focuses on eliciting business, stakeholder,

solution, and transition requirements.

12. D. Brainstorming promotes creative thinking, producing a broad or diverse

set of options for a specific topic or problem.

13. A. Document analysis elicits requirements of existing systems by reviewing

available documentation and leveraging existing materials to discover or

confirm requirements. It is also used when SMEs for existing systems are no

longer available.

14. B. Heterogeneous individuals have diverse backgrounds and offer different

perspectives during a focus group.

15. B. Interface types include user interfaces, external application interfaces,

and interfaces with external hardware devices.

16. A. Prototyping for requirements elicitation targets uncovering and

visualizing the interface needs before an application is designed or

developed.

543

17. C. A survey or questionnaire provides an effective method for eliciting

requirements information from many people in a short period of time.

18. A. The nonjudgmental environment of a brainstorming session for

requirements elicitation enables creative thinking.

19. C. Unstructured interviews are where the business analyst has no predefined

questions but sits with the interviewee to discuss what the business expects

from the target system.

20. C. Affinity maps, fishbowls, and product boxes are all collaborative games

that may be used to encourage stakeholders to develop a joint view of a

problem or potential solution.

544

Chapter 6: Controlled Middle: Requirements Analysis and

Design Definition

1. C. Requirements analysis tools and techniques are used to develop the

stakeholder and solution requirements.

2. A. Requirements validation ensures that all requirements support the

delivery of value to the business by ensuring that stakeholder, solution, and

transition requirements align to the business requirements.

3. B. Consistent requirements do not contradict or conflict with one another.

4. D. Data flow diagrams show how information flows through the system.

5. D. A model serves as an abstraction representing some or all of the proposed

solution.

6. C. A process is defined as a sequence of repeatable activities executed in an

organization.

7. B. Decision modelling is an example of rationale-focused models used in

requirements analysis.

8. C. Entities in an entity-relationship diagram are the things about which data

is needed. They are contained in the labeled rectangle of the diagram.

9. A. The six tasks of requirements analysis are specify and model

requirements, verify requirements, validate requirements, define

requirements architecture, define design options, and analyze potential

value and recommend solution.

10. B. Activity flow models show how the system behaves over the course of time

through executing business processes or resulting from events that occur

inside the solution scope.

11. C. The requirements architecture is the structure for all of the requirements

of a proposed change.

12. B. Constraints impose limitations imposed on the solution that do not

support the business or stakeholder needs.

13. D. Improvement opportunities include increasing efficiency, providing better

access to information, and identifying capabilities beyond what is required.

14. B. Nonfunctional requirements define quality attributes, design, and

implementation constraints, and external interfaces the product must have.

They are a type of solution requirement.

15. D. Atomic requirements are self-contained and capable of being understood

independently of other requirements or designs.

16. C. Scope modelling organizes requirements based on the solution

components to which they are related.

545

17. A. Specified and modelled requirements are the output from the task

“specify and model requirements.”

18. C. The four main components of an entity relationship diagram are the

entities, their attributes, unique identifiers for each occurrence of an entity,

and relationships between the entities. Attributes are individual pieces of

information that describe an entity.

19. A. Verification is a quality check performed after a requirement is analyzed.

Verification activities are typically performed iteratively throughout the

requirements analysis process.

20. B. Assumptions and constraints are defined and clarified as requirements

are understood and documented with their associated attributes such as date

identified, owner, impact, and any associated risks.

546

Chapter 7: Controlled End: Solution Evaluation

1. C. Solution Evaluation tasks can be performed on solutions in different

stages of development. A pilot or beta release is the name given to a solution

component that is part of a limited implementation that is not fully released.

2. B. Business objectives provide you with the measurable result that the

enterprise wants to achieve.

3. B. The item tracking technique is used to ensure that issues identified by

assessing enterprise limitations are resolved.

4. D. According to the BACCM™, a business analyst may recommend a change

to either a solution or to the enterprise to realize the potential value of a

solution.

5. B. Determining the most appropriate response to identified problems in a

delivered solution is an element of the assessing solution limitations task.

6. C. “Do nothing” is the best recommendation to make when the value of a

change from a current state is low relative to the effort required to make that

change.

7. D. To evaluate solution performance, the solution must exist in some form

and be in use.

8. B. The project sponsor is responsible for approving the potential value of a

solution.

9. D. Allocated requirements are associated with a solution component that will

implement them.

10. A. You are making decisions about replacing or retiring a solution. One

factor you consider is the money/effort that has already been committed to

this current initiative, which is the sunk cost.

11. C. The implemented solution is a solution that exists in some way.

12. C. Requirements allocation typically begins early in the project life cycle (as

soon as the solution approach can be determined) and continues to be

performed until all valid requirements are allocated, typically through design

and construction of the solution.

13. B. Transition requirements are defined after the solution has been designed.

14. A. During solution validation, the root-cause analysis technique can be used

to ensure that the underlying reason for a defect is identified, rather than

simply correcting the output that may be a symptom of a deeper underlying

problem.

15. A. Investigating how a solution affects a particular stakeholder group (or

stakeholder assessment) is an element of the assessing enterprise limitations

task in the Solution Evaluation knowledge area.

16. B. When assessing enterprise limitations using the risk analysis and

547

management technique, be sure to address technology, financial, and

business risks.

17. B. Transition requirements define capabilities needed to support the

transition from the old system to the new solution, including employee

training, conversion of existing information, and user acceptance testing.

18. C. The BABOK

Guide recommends using metrics and KPIs when

measuring solution performance.

19. C. Inputs for the Analyze Performance Measures task include the solution

performance measures and the potential value. Additional guidelines and

tools used as inputs are the change strategy, future state description, risk

analysis results and solution scope, the deployed solution, any identified

defects, and the business requirements.

20. C. The business analyst knows the business environment and can assess how

each proposed solution would affect the environment. Business analysts are

also responsible for ensuring that the stakeholders fully understand the

solution requirements and that implementation decisions align with those

requirements.

548

Chapter 8: Underlying Competencies

1. B. Business principles are those characteristics that are common to all

organizations with a similar purpose and structure, whether or not they are

in the same industry. Examples include organizational functions such as HR

and finance.

2. D. Influence skills enable you to get things done.

3. A. Organization knowledge is the understanding of the business architecture

of an organization, including business models, organizational structure,

business unit relationships, and people in key stakeholder positions.

4. D. Visual methods involve providing learners with a visual representation,

such as a graphical model of a business process or a solution.

5. C. These are Tuckman’s four stages of group development in the order they

occur. You will not find this specific information in the standard. Several

business analysis tasks require you to manage teams, and this is a well-

known model for group development.

6. A. Confrontation is considered to be the best method for conflict resolution

with the highest likelihood of reaching a permanent solution. It involves

addressing the conflict using a problem-solving method by analyzing the

facts. You will not find this specific information in the standard.

7. A. The process of gaining knowledge or skills is also known as learning.

8. C. Organization and time management skills assist you in effectively

managing tasks and information. One measure of organization and time

management is effective use of your time, which requires prioritizing,

eliminating procrastination, and clarifying goals and objectives.

9. A. Problem solving involves measuring alternatives against objectives and

identifying trade-offs to determine which possible solution is best.

Evaluating trade-offs and measurements is part of decision making.

10. C. Diagramming tools support rapid drawing and documentation of a model

by providing a set of templates for a particular notation, and they are

generally low-cost and easy-to-use. The resulting diagrams can often be

integrated into a word-processing document.

11. B. Knowledge management and collaboration tools that may be used to

capture and distribute knowledge throughout an organization include

document repositories that link with office productivity software, wikis

allowing easy creation and linking of web pages, discussion forums, or other

web-based tools.

12. C. Cognitive conflicts are based on disagreements on matters of substantive

value or impact on the project or organization. Resolution of cognitive

conflict requires the team to focus on examining the premises, assumptions,

observations, and expectations of the team members.

549

13. B. Effective leadership requires that a business analyst be able to develop a

vision of a desired future state that people can be motivated to work toward

and the interpersonal skills needed to encourage them to do so.

14. A. Expectancy theory links the expectancy and likelihood of a reward to

behavior.

15. B. Analytical thinking and problem-solving skills are divided into five more

detailed areas: creative thinking, decision making, learning, problem solving,

and systems thinking.

16. D. Effective problem solving is a combination of problem definition,

alternatives identification, and decision making.

17. C. One aspect of effective verbal communications is your ability to use your

active listening skills. Active listeners maintain a focus on the speaker in

order to understand, interpret, and evaluate what is being said in a calm,

systematic fashion. Often, active listeners paraphrase statements to the

speaker to ensure that the listener understands what is being said.

18. B. Theory X says people are inherently lazy and need to be threatened in

order to be motivated. In contrast, Theory Y states that people seek out

responsibility and respond to proper expectations in the workplace.

19. A. Confronting a problem is considered to be the best method for conflict

resolution with the highest likelihood of a permanent solution. This involves

laying the problem and any related information out on the table and getting

the involved parties to discuss what is going on and reach a resolution.

20. C. The storming stage of the Tuckman model is characterized by

confrontations as team members vie for position and control within the

group. Everyone is jockeying for status within the group, and things can be a

bit chaotic.

550

Chapter 9: Five Perspectives on Business Analysis

1. C. The five common perspectives addressed by the BABOK

Guide include

agile, business intelligence, information technology, business architecture,

and business process management.

2. B. The false statement is “Knowledge areas are applied the same way

regardless of the perspective being used.” Knowledge areas are typically

modified and customized for each perspective. This can result in different

techniques, frameworks, and reference models being used as part of the

initiative.

3. D. Business analysis work is performed continuously throughout an agile

initiative and relies heavily on interpersonal skills.

4. A. On agile projects, a kanban backlog list is used to manage the ongoing

refinements and redefinition of the project scope. The backlog list is

continually reviewed and reprioritized.

5. C. The sponsor is the key stakeholder that you need to have involved with the

project from the beginning, providing continuous feedback to the team and

adjusting the product as needs change.

6. C. One or a combination of the following roles can perform business analysis

activities on agile teams: a business analyst working on the team, the

customer representative or product owner, or distributing the business

analysis activities throughout the team members.

7. A. The focus of business intelligence is the transformation of data into value-

added information to support business decision making.

8. B. One focus of a business intelligence project is customer engagement,

targeting a strategic process level of decision making. Other strategic process

examples include market analysis and product development.

9. D. The business analyst’s primary role on a business intelligence initiative is

as a liaison between business intelligence stakeholders and solution

providers. Additional activities may include designing ad hoc queries,

designing specialized presentations, and modelling decisions or enterprise

data.

10. A. A process modeller captures and documents as-is and to-be business

processes on business process management projects.

11. C. Predictive analytics applies statistical analysis methods to historical data

to identify patterns and make predictions about future events. The focus is

on pattern recognition through data mining, predictive modelling,

forecasting, and condition-driven alerts.

12. D. Business analysts working in an information technology environment

consider their tasks in light of three factors: solution impact, organizational

maturity, and change scope.

551

13. C. The waterfall life cycle model is an example of the predictive solution

development methodology where each phase of the process or sequence is

completed before advancing to the next phase.

14. C. The four information technology methodologies a business analyst may

encounter are homegrown/organization specific, requirements engineering

(RE), structured systems and design method (SSADM), and the unified

process (UP). SSADM is a predictive development methodology focusing on

established logical modelling and the separation of requirements from

solutions.

15. B. In addition to the techniques identified in the Elicitation and

Collaboration knowledge area, three methods can be of great benefit in the

information technology discipline. They are investigation, simulation, and

experimentation. Simulations use statistical methods and mockups as part of

the elicitation effort.

16. A. Business architecture provides architectural descriptions and views, called

blueprints, to provide a common understanding of the organization for the

purpose of aligning strategic objectives with tactical demands.

17. D. For each blueprint provided, business architecture may define the current

state, future state, and one or more transition states that are used to

transition to the future state. This provides insight and understanding of

how well the organization aligns to its strategy and is a trigger for change.

18. C. There are several factors central to successful business architecture. They

include support of the executive business leadership team, integration with

clear and effective governance processes, and integration with ongoing

initiatives and access to senior leadership.

19. C. The business process management perspective focuses on how the

organization performs work to deliver value across multiple functional areas

to customers and stakeholders.

20. C. The business process management life cycle generally includes the

following four activities: designing, modelling, execution/monitoring, and

optimizing. Execution/monitoring is where data is collected from the actual

business process flow.

552

Comprehensive Online Learning Environment

learning environment and test bank to help you study for your CBAP and CCBA

certifications.

The online test bank includes:

Assessment Test to help you focus your study to specific objectives

Chapter Tests to reinforce what you learned

Practice Exams to test your knowledge of the material

Digital Flashcards to reinforce your learning and provide last-minute test

prep before the exam

Searchable Glossary gives you instant access to the key terms you

’

ll need

to know for the exam

Go to http://www.wiley.com/go/sybextestprep to register and gain access to

this comprehensive study tool package.

553

30% off On-Demand IT Video Training from ITProTV

ITProTV and Sybex have partnered to provide 30% off a Premium annual or

monthly membership. ITProTV provides a unique, custom learning

environment for IT professionals and students alike, looking to validate their

skills through vendor certifications. On-demand courses provide over 1,000

hours of video training with new courses being added every month, while labs

and practice exams provide additional hands-on experience. For more

information on this offer and to start your membership today, visit

http://itpro.tv/sybex30/.

554

WILEY END USER LICENSE AGREEMENT

Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.

555