Business Analysis Quick Start Guide

Introduction to Business Analysis

DeEtta Jennings-Balthazar
 Copyright © 2020 DeEtta Jennings-Balthazar

All rights reserved. No part of this publication may be reproduced, distributed, or transmitted
in any form or by and means, including photocopying, recording, or other electronic or
mechanical methods, without the prior written permission of the publisher, except in the case of
brief quotations embodied in critical reviews and certain other noncommercial uses permitted
by copyright law.

ISBN 978-1-71675-600-9
Irving, TX 75063

First printing edition 2008

www.echoicesolutions.com

Page | iii
 Dedication

I would like to dedicate this book to my son James L. Balthazar Jr., who always stand by me and

have faith in everything I do. I would also like to dedicate it to those who inspired me and

motivated me when the writing got tough, and to those who read it to make sure it made sense:

Family, friends, and colleagues

Table Contents
Introduction..........................................................................................................................7
What is Business Analysis ....................................................................................................8
What is a Business Analyst (BA)? ........................................................................................9
Business Analyst Skillset ...................................................................................................10
Business Analyst Vs. Systems Analyst ...............................................................................11
Chapter 1: Getting Started .................................................................................................12
Managing Stakeholders ..................................................................................................12
Doing your homework....................................................................................................14
Assessing the current state “As Is” .................................................................................14
Defining the “Future State” ............................................................................................16
Process Modeling ...........................................................................................................17
Using Swim-land Activity diagram to document “As Is” and “Future State ....................18
Chapter 2: Project Engagement .........................................................................................19
What is a Project?...........................................................................................................19
Project Team Members...................................................................................................21
Pre-Project Documents ...................................................................................................23
Creating a Business Case Document ...........................................................................23
Creating a Project Scope Document? ..........................................................................25
Chapter 3: Eliciting Requirements .....................................................................................27
What are requirements? ..................................................................................................27
Requirement types for Business Analysis .......................................................................27
Requirement Gathering Techniques ................................................................................29
Focus Groups .............................................................................................................32
One-on-One Interviews ..............................................................................................34
Facilitated requirements work-shops ...........................................................................36
Prototyping .................................................................................................................38
Questionnaires/Survey ................................................................................................40
Documenting Project Requirements................................................................................42
Creating a Business Requirements Document (BRD)..................................................42
Chapter 4: Software Development Lifecycle (SDLC) ........................................................44
What is a Software Development Lifecycle? ..................................................................44
What is a SDLC Methodology? ......................................................................................46
Waterfall SDLC Methodology ....................................................................................46

Page | 5
 Business Analyst Role in a Waterfall environment......................................................47
Agile SDLC Methodology ..............................................................................................48
Key BA Role on Agile Projects ..................................................................................50
Waterfall Business Analyst Vs Agile Business Analyst ..................................................51
Chapter 5: Business Analyst Role in Testing .....................................................................52
What is User Acceptance Testing (UAT)? ......................................................................52
About the Author ...............................................................................................................55
Appendix ...........................................................................................................................56
Business Analyst Tools ..................................................................................................56
Business Analyst Resources ...........................................................................................57
Frequently Used Terms ..................................................................................................58
References .........................................................................................................................63
 Introduction
Who is this book for?

Before most technology or business process changes can be implemented, business analysis is

essential. Business analysis helps an organization to improve how it conducts its functions and

activities in order to better support customers. Business analysis focuses on identifying

requirements in the context of helping organizations to achieve strategic goals. This quick start

guide was developed as an introduction to business analysis. Written by a business analyst with

over 20 years of industry experience, this guide will help you gain a comprehensive

understanding of business analysis fundamentals and the value of a business analyst within an

organization. You will learn how to define the business needs and apply the most effective

tools and techniques to elicit, analyze and communicate requirements to business stakeholders

and project teams. In this guide I use a variety of graphical examples, templates and artifacts

based on real world work experience to provide step-by-step guide to conducting business

analysis. Learn how to:

▪ Define business analysis practice and the role of the business analyst within an information

technology environment

▪ Elicit and manage project requirements

▪ Create Business Analysis documents

▪ Gain an understanding of the different models & methodologies of Software Development

Life Cycle (SDLC), Agile and Waterfall

This quick start guide is the perfect reference to help you jump start your career as a business

analyst.

Page | 7
 What is Business Analysis

According to the International Institute of Business Analyst (IIBA), a nonprofit professional

association that sets the standards for conducting business analysis, defines business analysis as a

research process of identifying business needs, gathering business requirements, and determining

solutions to business problems. Solutions often include some type of a systems software

component. But can also include: Business process improvement, organizational changes, strategic

planning, and policy development. Generally speaking, business analysis refers to the practice of

identifying business needs and developing solutions to meet them. Business analysis techniques are

used to create an appropriate plan and put that plan into action. Conducting effective business

analysis involves carrying out the following key high-level steps:

1. The first step in the process is to identify a problem, an issue, or some other business need.

2. The next step is to identify and document the current business processes and capabilities. The

process of analyzing existing processes and defining new or improved ones takes place in

facilitated group sessions

3. Identify and communicate with Stakeholders - All Stakeholders have different needs, goals, and

knowledge of the business. So, it is the Business Analyst job to bring all this knowledge together,

analyze the information gathered, and provide a clear understanding and vision for everyone to

work with.

4. Capture Requirements - A requirement in the context of Business Analysis is simply a statement

provided by a stakeholder about what they believe they need in order to solve a

particular business problem or respond to a specific business need. As a business analyst it is

important to capture and document requirements in a clear and concise manner.

 What is a Business Analyst (BA)?

The International Institute of Business Analysis (IIBA), describes the Business Analyst as a liaison

among stakeholders to elicit, analyze, communicate, and validate requirements for changes to

business processes, policies, and information systems. The business analyst understands business

problems and opportunities in the context of the requirements and recommends solutions that

enable the organization to achieve its goals. Business analysts can serve in many functions in almost

any industry. Other job titles where an employee perform business analysis include systems analyst,

data analyst, requirements manager, researcher, product owner or product manager. As a BA you

will need to be able to:

▪ Demonstrate excellent understanding of the way the organization works and the sector it

operates in. You will be helping the organization to develop its functions, services, and products

to meet goals with internal and external stakeholders.

▪ Play lay a key role in communicating between internal departments and external parties and

project teams acting as a 'translator' where necessary to convey how technology can support the

organization’s needs.

Through the effective use of business analysis, you can ensure an organization realizes these

benefits, ultimately improving the way they do business. In simpler terms, the business analyst’s

primary objective is helping businesses implement technology solutions in a cost-effective way by

identifying business needs, determining the requirements to meet those needs, and communicating

them clearly to stakeholders, team members and partners.

Page | 9
 Business Analyst Skillset

Some qualities of a good business analyst include the following:

Communications Skills

Business analysts must be good communicators. This means they can facilitate working

meetings, ask good questions, listen to the answers, and absorb what is being said. In today’s world,

communication does not always happen face-to-face. The ability to be a strong communicator in a

virtual setting (via conference calls or web meetings) is equally important.

Software background

Although a Business Analyst is not required to have a technical background it is vital to possess the

ability to use basic office tools such as Word, Excel, and PowerPoint. Also, it is a plus to have

experience using common visual modeling tool such as Smart Draw and Microsoft Visio.

Analysis skills

Business analysts spend a large chunk of time analyzing problems and determining solutions.

Knowing how to interpret business, software and information workflows will help you advance in

your career.

Documenting and writing skills

As a BA you will be required to deliver a range of different types of documents (requirements

documents, reports, specifications, plans and analysis). You will need to ensure that your documents

are written in a clear and concise manner, and at a level that is appropriate for your stakeholders.

Problem Solving

A BA must first understand the problem from all the perspectives (i.e. business, technical and end-

user), analyze the available options and constraints and then, recommend possible solutions.
 Business Analyst Vs. Systems Analyst

There is a range of analysis activities that are performed in a project. Therefore, it is important to

place Business Analysis in its context by contrasting it from System Analysis. Business Analysis

identifies what it takes the business to evolve from its current state to its aspired one. System

Analysis on the other hand directly addresses the requirements of the system being developed. The

table below compares the Business Analyst (BA) to the Systems Analyst (SA).

Business Analyst (BA) Systems Analyst (SA)

A BA is a non-technical role. He/she is more The SA is a technical role. He/she is more

business focused
A BA is responsible for identifying a business
problem and states in business terms WHAT
the solution is.
A BA captures and documents business
requirements
The BA is viewed as the liaison between the
business stakeholders and technical team
focused on the system
The SA makes technical decisions on HOW the
system will be implemented.
The SA converts the business requirements
captured by the business analyst into technical
specifications
The SA acts as the liaison between the technical
team and vendors.

Business Systems Analyst (BSA) - Business Systems Analyst is a hybrid of Business and Systems

Analyst. Adding the word “system” to the title of business analyst moves the role into a more

technical realm. Even though the word “system” doesn’t mean technology, most businesses have

used the phrase “information systems” to mean software applications. So, a business systems analyst

knows more about application systems and how they support the business needs. A BSA will be able

to recommend changes to existing applications, identify impacted interfaces, and work with the

technical team to implement and test the changes. BSAs almost always report to the Information

Technology (IT) department, whereas BA’s in some organizations may report to a business unit.

Page | 11
 Chapter 1: Getting Started
Managing Stakeholders

In the very beginning of a project, a business analyst begins to work with the company’s key

stakeholders to communicate the project’s vision and elicit requirements. A Stakeholder is either an

individual, group or organization who is impacted by the outcome of a project. They have an

interest in the success of the project and can be within or outside the organization that is sponsoring

the project. The stakeholders on a project are the ones who make decisions and sign off on

requirements and priorities. Therefore, you need to work very closely with every identified

stakeholder throughout a project life cycle.

Stakeholder Management Process

Stakeholder management is the process of managing the expectations and the requirements of

these stakeholders. It involves identifying and analyzing stakeholders and systematically planning to

communicate and engaging with them. Below is a list of tips for managing Stakeholders:

1. Identify Stakeholders - Conduct a stakeholder analysis, or an assessment of a project’s key

participants, and how the project will affect their problems and needs. Stakeholders who you

should take into consideration are those who will be affected by the project. Additional

questions you may want to ask can include:

✓ Who has an interest in the project?

✓ Who has power over your project?

✓ Who will benefit from success of the project?

2. Next step is to assess influence - Measure the degree to which stakeholders can influence the

project. The more influential a stakeholder is, the more you will need their support.

3. Conduct needs assessment - Knowing what each stakeholder needs or wants from the project

will enable you to gauge his or her level of support.

4. Understand their expectations - Nail down stakeholders’ specific expectations. Ask for

clarification when needed to be sure they are completely understood.

5. Define “success” - Every stakeholder may have a different idea of what project success looks like.

Discovering this at the end of the project is a formula for failure. Gather definitions up front and

include them in the objectives to help ensure that all stakeholders will be supportive of the final

outcomes.

6. Keep stakeholders involved - Do not just report to stakeholders. Ask for their input. Get to

know them better by scheduling time for coffee, lunch, or quick meetings. Measure each

stakeholder’s capacity to participate and honor time constraints.

7. Keep stakeholders informed - Send regular status updates. Daily may be too much; monthly is

not enough. Depending on your audience, one update per week is usually about right. Hold

project meetings as required, but do not let too much time pass between meetings.

Creating a Stakeholder communication document

Now that you have an idea about how and how often you should communicate and engage with

your stakeholders, it is time to create a plan to deliver the right message to the right stakeholder in a

timely manner. I use a simple spreadsheet to capture this information.

Example template

Name / Role How much impact How could they How much interest Communication
do they have in the contribute to the do they have in the method
project? (H/M/L) project? project? (H/M/L)
Jane Smith, High Budget & High Emails
Sponsor resources
Bill Long, High Project Initiatives Medium Weekly status
Product meeting
Manager
Intranet Users Low Users of the Medium Emails
product

Page | 13
 Doing your homework

Assessing the current state “As Is”

Now that you have identified the Stakeholders you can start the process of capturing background

information on their existing processes. The first step you want to take is to conduct a current state

“As Is” analysis. An “As Is” business process analysis defines the current state of the business

process in an organization. The main purpose of the “As Is” analysis is to present the current state

(i.e. the existing business context, background information, business functions and existing business

processes, and also stakeholders involved in these business processes). An “As Is” Analysis also

captures the key pain points within the identified business processes and highlights the areas where a

change is expected. This process is called performing a Gap Analysis. Below are a few

recommended steps you can take when conducting an “As-Is” process analysis:

1. Research - For a full current state analysis of a business, you will need to get an overview of the

company’s main products and activities. Start by compiling a list of all products and services to

get a clear outline of the business’s value chain.

2. Identify all processes that the company uses to generate those products and services at each level

and order them chronologically. Be sure to note when each process starts and ends and identify

which teams or individuals are involved in (or responsible for) those processes.

3. Documentation - Once process information is collected; you will need to document it clearly.

You can use process maps, activity diagrams or textual documents to map out the process. See

example process flow diagram on the next page.

The main advantage of as-is process analysis is creating a foundation in an organization’s processes.

As-is analysis allows a business to evaluate the current state of its processes and identify

opportunities for improvement.

 Performing a gap analysis?

As mentioned above a gap analysis is an examination and assessment of your current performance

for the purpose of identifying the differences between your current state of business and where you

would like to be. Conducting a gap analysis can help you improve the business efficiency, the

product, and the profitability by allowing you to pinpoint “gaps” present in the company. Once it is

complete, you will be able to better focus your resources and energy on those identified areas in

order to improve them.

High-level steps in performing a gap analysis.

Step 1: Understand the current state – e.g. review business processes and discuss problems in the

current environment.

Step 2: Define the desired future state – The future state represents the ideal condition in which you

want your business to be.

Step 3: Identify and document the gap – A gap is a deficiency existing between what a business

would like to do, and what the business actually does.

Below is a pictorial view of a gap analysis process.

Page | 15
 Defining the “Future State”

Once you have completed your current state and identified gaps in the process you can now start

your “Future State”. A “Future State” business process defines the future state of a business

process in an organization. Typically, the analysis goal in putting together the future state process is

to clarify how the business process will work, at some point in the future once changes are made.

Those changes could be technology changes or business process changes. Below are a few steps you

can take when conducting a future state analysis:

1. Study your current state map to identify areas of concern that need to be improved; asks these

questions:

▪ Can tasks be eliminated?

▪ Can tasks be combined with others?

▪ Can tasks be performed in parallel with other tasks?

▪ Do tasks take too long? If so, why?

2. Determine improvement opportunities based on answers to the above questions

3. Identify obstacles or challenges in the transition from the current state to the future state

4. Document processes - Keeping records of both current and future state documents will help

everyone in the organization maintain process consistency and track progress and outcomes

more effectively. The goal is to meet several times to document the process together. These

meetings may be best scheduled after you conclude other research (e.g., interviews and

observation) because you can outline everything you have learned and then collaborate with

participants to identify any gaps and confirm your findings. Keeping records of both current

and future state documents will help everyone in the organization maintain process consistency

and track progress and outcomes more effectively.

 Process Modeling

Certain business problems require a more thorough approach to understand how a task/process

works or when it is triggered due to a complex workflow. This analysis can be challenging but this

can be mitigated with the aid of a Business Process Map. Business Process Mapping (BPM) is an

incredibly powerful tool to help an organization better understand what it does and how certain

tasks/processes are done. This is accomplished with the creation of a diagram using software like

Microsoft Visio that uses symbols to show the step by step sequence of important process steps, as

well as decision points and outputs from the process. There are multiple different types of Business

Process Maps. Each provide their own unique value. Below are a few examples:

▪ Basic Flowchart - These are graphic illustrations of your process

▪ Swimlane Diagrams - Also known as cross-functional maps, these detail the sub-process

responsibilities in a process

▪ Data Flow Diagram – Provides a visual representation of the flow of data in a process or system

Business Process Mapping can be used to document “Current State” workflows which can then be

analyzed for inefficiencies such as manual processes or redundant steps. These processes can be

updated using system automation to help reduced manual errors and provide a view of what the

“Future State” workflow will look like. Business Process Mapping can help to provide a visual

communication medium to ensure there are not gaps as well as ensure all aspects of a workflow are

accounted for. On the next page I will walk you through creating a swim-lane diagram.

Page | 17
Using Swim-land Activity diagram to document “As Is” and “Future State”

Start with a basic swim lane diagram showing your current process, then create a layer containing the

steps that might be added to your process in the future. Swim lanes divide your flowcharts into

meaningful sections. You can use swim lanes to sort responsibilities by person or to separate a

process into phases. To use swimlanes, you must arrange your activity diagrams into vertical

zones separated by lines. Each zone represents the responsibilities of a particular class.

Example swim lane diagram for order processing.

The gray boxes represent the “As Is” process and the green boxes represent the “Future State”.

Each lane is represented by classes (i.e. Warehouse, Card Processing, Sales and Customers)

A process flow diagrams gives you a visual look at the processes flow and pain points. I use this

diagram when I start facilitating meetings with project team members. It allows me to give the team

a visual overview of the existing and future processes. I use this diagram to drill down into more

details.
 Chapter 2: Project Engagement

What is a Project?

When an organization wants to bring a new product to the market, create a new service for a client,

improve a process or update an existing technology, a project must be executed. A project is a

temporary endeavor undertaken to create a unique product or service. It has organized activities

with a well-defined purpose and completed by a dedicated project team within a given timeframe.

Once it has achieved its purpose, the project is over.

Characteristics of a Project

The following is a few characteristics help to further define a project:

▪ A project has a unique purpose. Every project should have a well-defined objective. For

example, many people hire firms to design and build a new house, but each house, like each

person, is unique.

▪ A project is temporary. A project has a definite beginning and a definite end. For a home

construction project, owners usually have a date in mind when they would like to move into

their new home.

▪ A project is initiated to bring about a change in order to meet a need or desire. Its purpose is to

achieve a specific objective which changes the context from a current state to a more desired or

valued future state.

▪ A project requires resources, often from various areas. Resources include people, hardware,

software, or other assets. For example, many different types of people, skill sets, and resources

are needed to build a software application.

Page | 19
 Types of Projects

▪ IT-Focused Projects - If you want to improve business processes, it makes sense to improve the

Information Technology (IT) systems. The added challenge for a business analyst is

understanding not only the technology involved, but what problem the business faces and what

the ideal solution will be.

▪ Operations Focused Projects - These are people-oriented projects that include improving the

process flow, updating procedures, and/or moving the location where processes are currently

being done. Business analysts will start with a current state analysis, review options, and see the

project through to implementation.

▪ New Opportunity and Strategy Projects - These types of projects are often about changing the

way people perform their roles. They can also involve updating the current IT systems. Or they

can be a combination of both.

How a project is created

The beginning of planning a project starts with an idea. The ideas can be in response to addressing

existing gaps or resolving problems or completely innovative. As the idea is captured, developed,

and transformed into business cases the project is created.

Below are some examples of a project:

▪ Planning a large party or an event, that is a project. This is because, it was a specific party for a

specific reason, and It was held on a specific date and time. That means the party was unique,

temporary, and it had a defined beginning and end, and the party created a specific service.

▪ Consider a payroll system: If the payroll system of your company is replaced with a new payroll

system, then that is a project.

 Project Team Members

Project team members are mainly the people who work on various phases of the project. They carry

out the day to day technical work of the project and is responsible for the following:

▪ Contributing to overall project objectives

▪ Completing individual deliverables

▪ Providing expertise

▪ Working with users to determine and meet business needs

▪ Documenting the process

Team Composition

Project Sponsor(s) – The project sponsor is the driver and in-house champion of the project. He /

She has a vested interest in the successful outcome of the project. They are typically members of

senior management and is responsible for:

▪ Making key business decisions for the project

▪ Approving the project budget

▪ Ensuring availability of resources

▪ Communicating the project’s goals throughout the organization

Project Manager – A project manager is a person who has the overall responsibility for the

successful initiation, planning, design, execution, monitoring, controlling and closure of a project.

Duties include:

▪ Developing a project plan

▪ Managing deliverables according to the decided plan

▪ Leading and managing the project team

▪ Establishing a project schedule and determining each phase

▪ Assigning tasks to project team members

Page | 21
▪ Providing regular updates to upper management

When a project manager and a business analyst are present on a project, the usual split of

responsibilities includes the project manager emphasizing on project schedule, cost, and resource

management, while the business analyst works on product requirements identification and

management.

Business Analyst – The role of Business Analyst is an important part of any project team. Acting

as the key interface between the Stakeholders and team the business analyst is responsible for:

▪ Evaluating business processes, anticipating requirements, uncovering areas for improvement,

and developing and implementing solutions.

▪ Conducting meetings and presentations to share ideas and findings

▪ Performing requirements analysis

▪ Documenting and communicating the results of your efforts

▪ Prioritizing initiatives based on business needs and requirements

▪ Monitoring deliverables and ensuring timely completion of projects

Developers - A Developer is an individual who is responsible for creating or working on the

development of a product or service. Most developers utilize one or more programming languages.

Architects - An architect is someone who is responsible for making sure that a company's business

strategy uses proper technology systems architecture to achieve its goals.

Software Testers - Software testers are involved in the quality assurance stage

of software development and deployment. They conduct automated and manual tests to ensure

the software created by developers is fit for purpose and any bugs or issues are removed within a

product before it gets deployed to everyday users.

 Pre-Project Documents

Creating a Business Case Document

One of the first things you need to know when starting a new project are the benefits of the

proposed business change and how to communicate those benefits to the business. The business

case is developed prior to a project being created. The business case is needed when resource or

expenditure on a project has to be justified. It brings together the benefits, disadvantages, costs,

and risks of the current situation and future vision so that executive management can decide

if the project should move forward. The Sponsor owns the Business Case but will often delegate

its preparation. In some instances, the Business Analyst may be asked to participate in or physically

write the Business Case. Approval is usually sought from the project sponsor and other interested

parties.

How to develop a business case

1. Confirm the opportunity - This will include the background to the project, the investment

logic, and the high-level business requirements.

2. Analyze and develop a list of options - Gather information about each alternative, analyze

the options and develop the shortlisted options.

3. Evaluate Options - Evaluate how the alternatives will deliver on the business objectives

4. Implement a strategy - Create the implementation plan for the preferred option, detailing

how to achieve the business objectives.

5. Confirm the recommended option - Create the business case documents and present the

business case recommendation to the board and management team for approval to proceed.

Page | 23
 Example Business Case template

Purpose: In this section you want to describe the purpose of this document. For example,

the purpose of this business case document is to justify the undertaking of the project

Executive Summary section

The executive summary summarizes the business case and your recommendations. It is often best

written last when you are clear about your recommended course of action and why.

Statement of the problem section:

This section describes the business problem that this project was created to address. For example, a

problem statement can read as: Because of an expanding client base, ABC Consulting has moved to

a de-centralized business model over the last 2 years. As we continue to support more clients in

more locations, the administration of our workforce has become more difficult. As our workforce

expands in numbers and area, our existing legacy mainframe systems have become inadequate to

effectively manage these administrative activities.

Recommendations section:

This section of the business case summarizes the approach for how the project will address the

business problem. Example recommendation: The recommended Project will migrate the data and

functions of our current mainframe system to our new platform.

Justification section

This section justifies why the recommended project should be implemented and why it was selected

over other alternatives. Example of a justification: Implementation of a new platform will reduce

cost by 15%.

Cost Analysis section:

Many consider this one of the most important parts of a business case as it is often the costs or

savings a project yields which win final approval to go forward.

 Creating a Project Scope Document?

When you are kicking off a new initiative, the project scope document is a critical piece of

information for your whole team. It defines the end product to be delivered to the customer, when

it must be delivered, and at what cost. Essentially, this document defines the boundaries of the

work, so that each team member and the customer all understand what the project entails. A project

scope statement once shared with every member of the team and the project's customers, is an

integral part of the project. Among benefits:

▪ A common understanding among all involved of the expected features, quality, and timing of the

project

▪ A means of communicating with other stakeholders in the project to gain their support and

involvement

▪ A tool to focus the team's efforts on the work required to meet the customer's needs

What is included in a Scope Document?

Business goals section

Every project has goals, and this is where you will define them. This section typically includes the

reasons the project is being supported (or funded), along with a set of business goals or intended

project outcomes for your team to keep in mind while executing the project.

Project description and deliverables section

This one is simple: a plain language overview of the project’s deliverables. In this section you want

to clearly outline what will be delivered for approval through the course of the project, as well as the

final deliverable. For instance, if you are creating a television ad for a client, you might say

something like: Company Name will produce and deliver one 60-second video advertisement in AVI

format to be used on television.

Page | 25
Acceptance criteria section

Your scope should help you come to an agreement on what will be delivered and leave no question

when the project is complete. Acceptance criteria can be measured, achieved, and used to prove that

work is complete.

Limitations section

Every project has its limits, and you need to be sure you are not exceeding those limits to complete a

project on time and under budget. Limitations can come in many forms, but one example would be

technology. For instance, if you are building an application that depends on a specific technology, be

sure to mention that. There may be several ways to create that website, but if you are boxed into a

complicated technology, you can cover yourself by specifying those limitations in your scope.

Assumptions section

In this section you want to list out all the assumptions you have thought about that will affect the

work you will do or the outcomes of that work.

Exclusions section

You have already listed out the deliverables you will provide, but sometimes it is just as important to

itemize what you will NOT deliver. This is sometimes referred to as out of scope items.

Costs

This is an optional portion of your project SOW, depending on the type of organization you work

in.

Agreement

Scope documents create agreement by nature, but sometimes you need proof. You want to include a

signature field in your scope document and have your lead stakeholder or project sponsor sign the

document.
 Chapter 3: Eliciting Requirements
Organizations spend a lot of money on key projects to ensure continued viability in a rapidly

changing world. They invest in projects to solve a business problem, take advantage of an

opportunity, or implement a strategic solution that furthers business goals. Capturing and managing

the right requirements ensures avoidance of costly missteps and is key to delivering successful

projects with measurable value. The Business Analyst must be able to provide the project team with clear

customer requirements for the product, service, or system that the project will deliver. And these

requirements must translate into measurable business requirements and project deliverables.

What are requirements?

According to the worldwide acknowledged Business Analysis Body of Knowledge (BABOK) a

requirement is:

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.

2. A condition or capability that must be met or possessed by a solution or solution component to
satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in [1] or [2].
In simpler terms, requirements are simply a capability needed by a stakeholder (person) to deliver a
product and/or service.
Requirement types for Business Analysis

Since there are different points of view about a solution, there are also different kinds of

requirements. Each kind describes a different aspect of a solution. The Business Analysis Body of

Knowledge (BABOK) defines the following kinds of requirements captured by the Business

Analyst.

▪ Business requirements (BR) - Business requirements describe the characteristics of a proposed

system from the viewpoint of the system's end user. It defines WHAT the business is trying to

achieve. Note: Business requirements are the critical activities of an enterprise that must be

performed to meet the organizational objective(s) while remaining solution independent.

Page | 27
 Example of a Business Requirement - Send out a notification to the Employee when a timesheet

is due.

▪ Stakeholder / User requirements (UR) – User Requirements define the requirements that the

user expects from the system. It typically starts with the phrase “The user shall”. Example of a

Stakeholder / User Requirement – The User shall be able to enter a timesheet.

▪ Functional requirements (FR) - Functional Requirements defines the function of a system or its

component. It describes what the system or the process must do in order to satisfy a business

need. Most of these requirements start with the phrase “The system shall”. An example of a

Functional Requirement - The system shall” generate an automated email to the customer.

▪ Non-functional requirements (NFR) – Non-functional requirements define requirements related

to availability, scalability, performance, security, usability, or quality. Example of a non-

functional requirement: The system must process a customer order in less than 100 milliseconds.

Gathering Requirements

Every Software project goes through a phase called Requirements Gathering. A successful project

begins with a difficult set of discussions on what should be done. It is the major responsibility of the

Business Analyst to gather the Requirements from the clients. When gathering requirements,

Business Analysts need to capture information within the context of the organization and in support

of operational needs to satisfying stakeholder goals. The process of gathering and eliciting

requirements begins with an understanding of how an organization operates. Understanding the

high-level process flow of a business highlights the ‘big picture’ and serves as a foundation for

planning the requirements gathering and management efforts. For Business Analyst, it is necessary

to pick methods which work best for gathering requirements.

 Requirement Gathering Techniques

Requirements Gathering Techniques involves interacting with the stakeholders to understand the

project needs. That means you probe the stakeholders to tell you the issues that the project is

expected to solve. At times, stakeholders do not know what they want. Therefore, requirements

gathering techniques helps you to obtain all the requirements from relevant stakeholders. you will

more than likely sit with the stakeholder either by one-to-one discussions or through group

discussions.

What to know about requirements gathering techniques?

▪ The process of requirements gathering include identifying and documenting the necessary

requirements of customers, users, and stakeholders related to the project. This knowledge will be

used to develop solutions in the form of products, services, or software.

▪ Requirements gathering techniques provide project team members with a choice of methods for

eliciting and validating requirements from stakeholders. Methods used to gather this data may

include techniques such as interviewing, brainstorming, focus groups, questionnaires etc.

▪ There are many techniques available for gathering the requirements. Each technique has value in

certain scenarios. Most of the time, it becomes necessary for Business Analyst to use multiple

techniques to gather complete and correct requirements from clients and stakeholders.

▪ Being good at Requirement Gathering Techniques is one of the biggest and most important

tasks to try and get the most out of when engaging with stakeholders. You will do a mix of the

techniques described on the next several pages and the mix will be different for every project.

Think about what suits the project best and have a read of the top tips associated with each of

the requirement gathering techniques.

Page | 29
 Brainstorming Sessions

Brainstorming is a group creativity technique by which efforts are made to find a conclusion for a

specific problem by gathering a list of ideas spontaneously contributed by its members. For

example, after you have defined your problem and are looking for the different solution options, you

gather a few folks from your project team (mostly the development team) and ask them about what

they think a solution could be. Brainstorming is a way to generate ideas within a group setting. It

provides a quick means for tapping the creativity of a limited number of people for many ideas.

When to use Brainstorming:

▪ It is usually used in the beginning stages of a project, where the possibilities for the project are

not clearly understood or defined

▪ When a broad range of options is needed

▪ When creative, original ideas are needed

▪ When participation of the entire group is needed

Notes:
 Facilitating a brainstorming session

Preparing for your session

1. Select your participants - According to BABOK, six to eight participants are ideal. Try to choose

representatives from each stakeholder group.

2. Set expectations - Set expectations about the format and objective—explain that in

brainstorming no idea is off the table, and there is no such thing as too many ideas.

3. Timebox - You may want to give participants a small amount of time to brainstorm (about 5

minutes each).

To run a group brainstorming session effectively, below is a list of recommended steps:

Step 1: Prepare the Group -First, set up a comfortable setting for the session. Make sure that the

room is well-lit and that you have the tools, resources, and refreshments that you need. Consider

who will attend the meeting. A room full of like-minded people will not generate as many creative

ideas as a diverse group, so try to include people from a wide range of disciplines and include people

who have a variety of different thinking styles.

Step 2: Present the Problem - Clearly define the problem that you want to solve and lay out any

criteria that you must meet. Make it clear that that the meeting's objective is to generate as many

ideas as possible. Give people plenty of quiet time at the start of the session to write down as many

of their own ideas as they can. Then, ask them to share their ideas, while giving everyone a fair

opportunity to contribute.

Step 3: Guide the Discussion- Once everyone has shared their ideas, start a group discussion to

develop other people's ideas, and use them to create new ideas. Building on others' ideas is one of

the most valuable aspects of group brainstorming. Encourage everyone to contribute and to

develop ideas.

Page | 31
 Focus Groups

Focus groups like brainstorming sessions can also be used to gather ideas; however, focus group

goes a bit further. For example, a focus group is used after the development of a prototype, in order

to get an idea of how the market will respond to certain features of the solution. During a focus

group, you are looking to gather the attitudes about an idea, a solution or even a process. The

participants of this meeting should be outsiders; meaning folks who are most likely to use/consume

to product. The result of a focus group would be the answers or feedback you have gathered during

the meeting. This feedback can be compiled and organized by themes to present to the stakeholders.

The main purpose of focus group research is to draw upon respondents’ attitudes, feelings, beliefs,

experiences, and reactions in a way where other methods are not applicable.

When to use a Focus Group

▪ When you need to gather more information in a shorter period of time - generally two hours

▪ When you need insight into complicated topics where opinions or areas of concerns as it relates

to behavior or motivations.

Notes:
 Facilitating your Focus Group session

Preparing the room

1. Arrive an hour early to set up the room. This allows time to deal with unexpected room

scheduling, and to set up materials and refreshments.

2. Post plenty of signs so participants can find their way to the space. This helps participants feel

welcome when they arrive.

3. Test your recording equipment or other electronic equipment to be sure it works

During the session

4. Introduce yourself and the purpose of the focus group. Explain to participants that they have

been invited to share their opinions and that you will guide the discussion by asking the group to

reflect on specific questions. Tell them what time the session will conclude.

5. Explain the ground rules for the focus group discussion. These will set the tone and

expectations for behavior so that everyone will feel safe and willing to participate. Here are

some examples of ground rules:

▪ Participation in the focus group is voluntary

▪ All responses are valid—there are no right or wrong answers

▪ Please respect the opinions of others even if you do not agree

▪ Try to stay on topic

6. Allow time for questions, and then ask participants to introduce themselves

7. End the discussion by summarizing the main points. If there is time, invite participants to reflect

on the main ideas, and ask if they have any additional thoughts to share.

Page | 33
 One-on-One Interviews

Interviews are one of the easiest yet most powerful techniques available for gathering

requirements. As a business analyst, you should use interviews to give you a deeper insight into

stakeholders’ concerns and using these insights will help you design a system that is well-suited

to stakeholder needs. A one-on-one interview is a focused interview with a key stakeholder or

subject matter expert designed to elicit a specific set of requirements. Once you have set the

scene for the interview, you should highlight the scope of your requirement gathering questions.

Tell them for example that you have some questions about the overall purpose of their

department, then you would like to talk about their most important business processes and

finally if they could discuss their current system with you.

When to use one-on-one interviews

▪ Interviews allow the interviewee to respond freely and openly to questions, especially when

the location is private.

▪ Interviews provide an opportunity for the analyst to ask follow-up questions or re-word the

question to get instant feedback from the interviewee.

Notes:
 Preparing for your one-on-one Interview Session

1. First aim to get the basic facts about the stakeholder and his or her organization (whether that is

just one department or the entire company). Ask one or two colleagues to review the interview

questions you are planning to ask.

2. Evaluate your User environment by asking some questions. For example:

▪ Who will be the users of the system?

▪ What computer skills do the users have?

▪ What technical platforms do they use today?

▪ What training needs do you expect for the future system?

▪ Plan for follow-up questions - do not be afraid to ask them if they occur to you during the

interview.

3. Design the interview form – design in a way that makes it easy for you to write down the

answers or enter them into a computer or use recording equipment.

Conducting your one-on-one interview

1. Select the Stakeholders you want to interview – You want to identify Stakeholders who have

knowledge of the business and processes

2. Prepare for your interview – Determine what information you need, set time limits for the

interview, and have a list of questions

3. Conduct the interview – Allocate enough time and insure there are no interruptions. Explain

why you are conducting the interview and explain how the input will be used.

4. Follow up – Of action items are defined, make sure you close them as soon as possible in order

to keep stakeholders actively involved.

Page | 35
 Facilitated requirements work-shops

Facilitated workshops are also like Focus groups, as they are a discussion forum with group of

selected stakeholders. However, the difference lies in the topic and stakeholders that they have in

Facilitated workshops. Unlike in focus groups, facilitated workshops primarily focus on a broad

topic associated with cross functional areas. The advantage in facilitated workshops are, the

stakeholder belongs to multiple cross functional areas are sitting as a group. Hence, if there are any

conflicting opinions from the SMEs, they can resolve the conflicts at once in the forum.

What happens in a typical workshop?

▪ Participants may be split into multiple teams to get the discussion going with each team

representing a mix of different interests

▪ Participants may be given a problem statement to discuss/objective(s) to achieve. They may also

be asked to identify requirements or review existing ones or assign

▪ Once you have a list of requirements you can prioritize

Notes:
 Facilitating your workshop

▪ Select the right participants—SMEs, stakeholders, users, etc. If you leave someone necessary

out, the results of the workshop may have to be completely overhauled. Think about this

carefully before inviting your group. As BABOK notes, “Requirements workshops that involve

too many participants can slow down the workshop process. Conversely, collecting input from

too few participants can lead to overlooking requirements.”

▪ Preparing for your workshop – do your homework (gather documentation), create and agenda

and timebox the session

▪ Before going into your workshop, prepare your notes document to reflect your agenda so

organizing the action items and points will be easier.

▪ Get everyone on the same page regarding the purpose of the workshop ahead of time.

▪ Conduct the workshop like an interview, with open-ended questions presented to the room.

▪ Document everything. Get a recorder or get someone besides you (or whomever will be busy

facilitating) to write everything down.

▪ After any session, schedule 15-30 minutes for yourself to review your notes, digest what was

discussed, prioritize action items, identify challenges/red flags, and needs for clarification or

additional meetings.

▪ Send your notes to your internal project team. Have them review and verify what you have

identified as action items, red flags, etc.

▪ Follow-up – Any action items identified during the workshop session should be tracked until

completed.

Page | 37
 Prototyping

Prototyping to model and evaluate what works and is fit for purpose in helping users achieve their

goals when using your product. In this process, you create what can be seen as a real working

mockup (as opposed to a static one). You share it with the clients and prospective users to collect

feedback as well as evaluate its functioning. From feedback and evaluation, you make improvements

and iterate the process until you get the final design that is aesthetically pleasing while at the same

time intuitive and effective enough for users to be able to achieve their objectives. The advantage of

building a design prototype is that it helps you keep cost low while saving you time and effort. In

other words, a prototype lets you analyze the “behavior” of your design and evaluate and implement

changes required to make it even better.

When to use Prototypes

▪ When the Stakeholder is not sure what they are needing

▪ Prototypes should be used for eliciting details of requirements, triggering discussions, and

identifying hidden requirements

▪ Help you iterate quickly on design concepts

▪ Prototypes can be used to validate requirements

Notes:
 Facilitating your prototyping session

The main purpose of a prototype is to gather and document requirements. After you build an initial

prototype you should show it to the clients to validate the work done so far looks okay. You then

use the prototype to gather additional requirements. As you receive requirements, you should

document them in the same way you would document the additional requirements you are gathering

though other means.

Benefits of Prototyping:

▪ Prototypes give users something tangible to review. Many people are interested in seeing what

something looks like, and the prototype fits this bill.

▪ Better understanding of the design intent: Prototyping not only presents a strong visualization of

the design to understand the look and feel of the final product but it also helps the team to

comprehend better why they are designing, what they are designing and for whom they are

designing.

▪ Early feedback - With prototyping you can collect reviews at every stage of developing the

product.

Preparing for your prototyping

1. Define your main goal - Start your initial brainstorming with your team. You may know your

design obstacles and need to research solutions.

2. Stick with 1 or 2 features to begin with. Remember this version will be refined along the way

3. Create your design on paper - Discuss with appropriate partners or stakeholders knowing there

will be improvements

4. Create your design on your computer

5. Get approval

Page | 39
 Questionnaires/Survey

When gathering information from many people: too many to interview with time constraints and

less budget: a questionnaire survey can be used. The survey insists the users to choose from the

given options agree / disagree or rate something. Do not think that you can make a survey on your

own but try to add meaningful insight in it. A well-designed survey must give qualitative guidance

for characterizing the market. It should not be utilized for prioritizing of requirements or features.

When to use Questionnaires / Surveys

▪ Questionnaires can also be effective in cases where the respondents are based in various

geographical locations

▪ Identifying customer requirements or preferences

▪ Assessing customer or employee satisfaction, such as identifying or prioritizing problems to

address

▪ Evaluating proposed changes

▪ Assessing whether a change was successful

▪ Monitoring changes in customer or employee satisfaction over time

Notes:
 Steps for preparing for surveys

1. Review Survey goals - It is necessary to verify the survey goals and objectives first

before preparing the survey questionnaire. The survey goals determine whether survey

questionnaire is the best method of data collection for this particular survey or not.

2. Define purpose, and objective of survey – The objective of the survey and the further action

from the survey results analysis must be determined.

3. Identify target groups to be surveyed – Identify the group which must be interviewed for the

survey

4. Choose appropriate survey types – Choose the survey type whether its open /close ended

5. Test the survey with a small group. Collect feedback

6. Select distribution, and collection methods – You can consider the various communication

options, such as hardcopy mail, email, or web-based survey tools

7. Design questions in consultation with key stakeholders

8. Finalize survey questions which clearly indicates the purpose and objective of the survey

9. If the group demography is diverse then it can be divided to several small groups and questions

can be customized as per the group dynamics

10. Focus on requirements - All questions must be directed towards the stated objectives.

11. Collate responses - Analyze the responses for closed ended questions as per no of responses for

each category and for ‘open-ended’ questions, for opinions expressed by participants.

12. Present results effectively. The point of conducting a survey is to make sure that results are

translated into action that benefits customers, employees, or constituencies.

Page | 41
 Documenting Project Requirements

Creating a Business Requirements Document (BRD)

Although there are several ways to document requirements that do not include a formal document

for the purpose this book, I will cover developing a business requirements document. Organizing is

the process where requirements are organized in a readable document. This is normally the process

in which the Business Requirements document is created. A Business Requirement Document

(BRD) focuses on the business perspective as it holds the details of the business solution for a

project. Business requirements document also emphasizes on the needs and expectations of the

customer. In simpler terms, BRD indicates what the business wants to achieve.

The BRD indicates all the project deliverable and the inputs and outputs associated with each

process function. Benefits of a BRD:

▪ Gain agreement with Stakeholders

▪ Communicate with the technical team

▪ To provide an appropriate solution to meet the customer/business needs.

▪ To provide input between the phases of the project

A Business Requirements Document (BRD) includes the planning strategies to ensure a formal

contract that involves understandable project phases. A well-structured BRD improves

collaboration between large-functional teams and creates a positive consensus. It also implements

business strategies with the aim of transitioning from one stage to another in a controlled way so

that stakeholders are satisfied, and their needs are met. Business Requirement Document will help

you throughout the project lifecycle to keep the deliverable in line with the business and customer

needs.
 Example Business Requirements Document Template

Executive Summary

The executive summary sets the stage for the entire document. So, make sure you hold their

attention and quickly convey all the necessary information. Detail the purpose of your BRD, the

objectives and goals and provide context for why you are undertaking the project.

Project Summary

Provide an overview of the project. This is the first part of the requirements document and it is

where you give your readers an overview of the project. This information can be captured from the

Scope document or Business Case.

As Is and Future State Processes

Describe how the current process(es) work, including the interactions between systems and various

business units. Include visual process flow diagrams to further illustrate the processes the new

product will replace or enhance.

Business Requirements

The specific business requirements elicited from stakeholders should be listed, categorized by both

priority and area of functionality to smooth the process of reading, and tracking them.

Functional Requirements

The functional requirements section should describe “what” the system is to accomplish rather than

the “how.”

None-Functional Requirements

Some specific types of requirements you may want to mention include: Security, Performance,

Availability, etc.

Glossary

Use this section to define any terms

Page | 43
 Chapter 4: Software Development Lifecycle (SDLC)
What is a Software Development Lifecycle?

Software Development Life Cycle is a framework that defines the steps involved in the development

of software at each phase. It covers the detailed plan for building, deploying, and maintaining the

software. Software Development Life Cycle defines the complete cycle of development i.e. all the

tasks involved in planning, creating, testing, and deploying a Software Product. Every phase of the

SDLC life cycle has its own process and deliverables that feed into the next phase.

A typical SDLC consists of the following phases.

Plan Analyze Design Develop Test Deploy

How SDLC Works

SDLC works by lowering the cost of software development while simultaneously improving quality

and shortening production time. That plan starts by evaluating existing systems for deficiencies.

Next, it defines the requirements of the new system. It then creates the software through the stages

of Planning, analysis, design, development, testing, and deployment. By anticipating costly mistakes

like failing to ask the end user for suggestions, a software development lifecycle can eliminate

redundant rework and after-the-fact fixes.

Planning Phase

The Planning phase is the most crucial step in creating a successful system. During this phase you

decide exactly what you want to do by: defining the problems, identifying the objectives and the

resources, and identifying proposed solutions.

Analysis Phase

During this phase, all the relevant information is collected from the customer to develop a product

as per their expectation. The Business analyst will set up a meeting with the customer to gather all

the information about what the customer wants to build, who will be the end-users, and what is the

purpose of the product.

Design Phase

Based on the user requirements and the detailed analysis of a new system, the new system must be

designed. This is the phase of system designing. It is the most crucial phase in the development of a

system. The logical system design arrived at as a result of system analysis and is converted into

physical system design.

Development phase

During the Development phase the software engineers start writing the code according to the

client's requirements.

Testing Phase

Testing starts once the coding is complete and the modules are released for testing. In this phase,

the developed software is tested thoroughly, and any defects found are assigned to developers to get

them fixed.

Deployment Phase

The deployment phase is the final phase of the software development life cycle (SDLC) and puts the

product into production. This means that the product is ready to be used in a real environment by

all end users of the product. The maintenance phase occurs after the product is in full

operation. Maintenance of software can include software upgrades, repairs, and fixes of the software

if it breaks. It is often necessary to provide additional testing of the software or version upgrades.

Page | 45
 What is a SDLC Methodology?

A methodology is a formalized approach to implementing the Software Development Lifecycle.

This book will cover the two most popular methodologies: Waterfall and Agile.

Waterfall SDLC Methodology

The Waterfall model follows a straightforward approach, which is a desirable quality for many

software developments teams. In this model, the outcome of one phase is the input for the next

phase. For example, all requirements need to be defined at the very start of a project. Only then can

the design and development stages begin.

Pictorial view of waterfall methodology

Plan

Analyze

Design

Develop

Test

Deploy

Benefits

▪ Each stage of the model has a well-defined starting and ending point, making it easy to

manage and monitor

▪ Quite easy to understand as technical documentation is an essential aspect of the initial

requirements gathering stage

 Business Analyst Role in a Waterfall environment

Planning phase activities

Identify Stakeholders - The key role of the BA is to understand and define the problem. However,

before getting to that stage, the BA will need to identify our stakeholders and users.

Analysis phase activities

The requirements analysis process kicks off the SDLC. BA’s must work with business owners and

users to determine the requirements that the solution must address. This phase should be

technology free.

Design phase activities

Once the requirements are complete, there needs to be a design in order to properly code the

software. BA’s may need to facilitate design sessions that bring together business experts and

technical staff to iron out details.

Development phase activities

This is the point in which developers get to work. Software developers will often work with BA’s to

ensure they fully understand the business requirements they are coding.

Testing phase activities

Once the code is complete, it must go through several levels of testing by Developer and Testing

(QA) team. The BA will provide the User Acceptance criteria and work with developers and testers

to ensure that all the criteria are met.

Deployment phase activities

After deployment, the BA play’s a key role in capturing the enhancements and fixes necessary for

future versions of the software solution and begin iteration of the SDLC again.

Page | 47
 Agile SDLC Methodology

There are as many different definitions of agile. For the sake of this book, agile is defined as

collaboration among stakeholders to deliver value to customers in frequent increments with

consistent reflection and adaptation. This definition focuses on the characteristics that exist in all

agile environments, namely:

▪ Collaboration – how the people involved in the effort work together which includes both the

delivery team and project stakeholders

▪ Deliver value – the true purpose of efforts is to provide value to customers, whether that is

through new software, more efficient processes, or new products.

▪ Frequent increments – the team delivers values every few days, weeks, or months rather than

once at the end of a project

▪ Consistent reflection and adaptation – the project team reflects on their approach and the

product on a regular basis and adjusts accordingly.

Agile approaches allow teams to focus on delivering the highest value as set by the business in the

shortest time. Teams using agile approaches self-organize to inspect actual working software rapidly

and repeatedly in iterations ranging from one week to one month in duration. In agile iterations are

termed as sprints. Each sprint lasts for 2-4 weeks. At the end of each sprint, the product owner

verifies the product and after his approval, it is delivered to the customer. The biggest impact of

iterations on business analysts is the lack of an analysis phase. Instead of performing all analysis

work to develop detailed requirements at the beginning of the project, business analysis occurs

throughout the project with an initial high-level picture of the overall scope, followed by more detail

on specific features when they are delivered.

Combined with the preference for face-to-face communication, agile methods produce little written

documentation relative to waterfall methodology. Below is a pictorial view of Agile Methodology

Lifecycle.

Sprint 1 Sprint 2

Plan Plan

Deploy Analyze Deploy Analyze

Test Design Test Design

Product Backlog

There are four primary roles included in an agile project.

1. The Product Owner is the ultimate decision maker for the product. This role is responsible for

defining the product vision, prioritizing features according to business value, and answering

team questions.

2. The Scrum Master is the guardian of the team’s process. This role is responsible for ensuring the

team has the appropriate environment to succeed, removing obstacles, and enabling close

cooperation across all roles.

3. The Team is a group of 5 – 9 people dedicated to the project full time who are responsible for

self-organizing to deliver value to the customer in each iteration.

4. Stakeholder(s) - A Stakeholder is anyone who can impact the project and provide input to the

business objectives of the product.

Page | 49
 Key BA Role on Agile Projects

Most agile approaches have a specific role to represent the ultimate business decision maker, such as

the role titled product owner. The product owner sets the product vision and is responsible for

understanding and representing the needs of the business and user stakeholders. The product owner

determines which requirements are most important prior to the start of each iteration and

determines how to release value incrementally to best satisfy the needs of the product stakeholders.

A business analyst does not always have the decision-making authority necessary to be an effective

product owner, but they can become indispensable by supplementing a product owner’s lack of time

or business analysis skill sets.

▪ Managing Product backlog - A business analyst supports a product owner by helping them

analyze the business domain, stocking the product backlog, and grooming the product backlog.

Stocking the product backlog means to establish a list of user stories that represent the overall

scope of the project. A user story briefly describes functionality or a feature valuable to either a

user or customer of a system or software solution.

▪ Analyzing Business Domain - The business analyst helps the team and product owner

understand and describe the business domain and problem to be solved by facilitating the

discussions that explore the following questions:

1. What business processes need to be revised, created, or eliminated?

2. What information do we want to know about and track about various entities?

3. What stakeholders (such as customers, suppliers, vendors) and systems are involved in the

effort?

▪ Business analysts facilitate collaboration through helping with stakeholder analysis and acting as

a language coach.
 Waterfall Business Analyst Vs Agile Business Analyst

From Direct Interaction with Multiple End Users to Product Owners

With the traditional/waterfall methodology, BAs are expected and encouraged to interact with

stakeholders from multiple domains. There is no official “Business Analyst” role in the scrum guide

however, as scrum identifies only the Product Owner, Scrum Master, and the Development Team.

From Business Requirements Documents (BRD) to Product Backlogs

BRD’s have their merit in the traditional software development lifecycle. These often lengthy and

detailed documents or descriptions provide an avenue for BAs to describe in detail what is required

in terms of system functionality. In the Agile however, user stories are defined via a collaborative

process (refinement) that involves the product owner and the development team. User stories are

expected to be defined by the Product Owner, with the BA.

From Status Updates to Daily Stand-ups

Typical waterfall approaches require the BA to provide updates on tasks accomplished either to the

project manager or to management directly. This may be in the form of weekly or monthly status

reports depending on the organization. BAs in addition to any obligations they have under the

project management umbrella may be required to participate in scrum ceremonies, one of which is

daily stand-ups.

From Communication to Collaboration

Unlike Waterfall, an important aspect of Agile is constant collaboration between the product owner

and the team. Constant collaboration can reduce wait time for sending and receiving information,

improve the quality of your requirements backlog, and can reduce misunderstand between what is

delivered and what is required.

Page | 51
 Chapter 5: Business Analyst Role in Testing
What is User Acceptance Testing (UAT)?

Before the criteria which the software is considered to be “working” needs to be assembled. These

are likely to be collated from the requirements, use cases or user stories. Next, a set of User

Acceptance Testing (UAT) test must be created. UAT test cases can be defined as a set of test steps,

execution conditions and expected results developed for a particular objective. Each case covers a

specific usage scenario of the software. It is normally a set of actions which the user can carry out

and be able to verify if the software worked as intended. With this in place, the test then has to run,

and the results are recorded. Finally, assuming that everything is working as expected, a sigh-off

needs to be completed by the business stakeholders. You need to consider the following factors

when planning and conducting UAT:

▪ Identify User Roles - Users and user roles vary for every system. The first thing you need to do

for UAT is to identify users and their roles in the system. Every user role has a different set of

privileges in the system, if there are more than one role in the system. Your UAT shall contain

test cases of how the system should behave when a particular user role performs a specific

action.

▪ Use User Stories or Use Cases as test cases - Understanding business requirements is a

prerequisite for testing. Clients can use numerous channels to describe their requirements. They

can convey their requirements through email, meetings, understanding sessions and through user

stories or use cases.

▪ Use business language - ser acceptance testing is not performed by professional testers, but

actual users. This difference is seen in the way user acceptance testing is performed. UAT is
 comparatively less organized and uses more business language. It would be unfair to expect from

users that they can execute test cases and report the issues like our professional testers.

▪ Create UAT Template - Create a user acceptance testing template and give it to the users who

are performing UAT testing. In the later section, we will see what information is required from

the user in user acceptance testing.

▪ Test cases are efficient when there is a clear purpose stated, and the user is able to understand

what they should do to complete it.

Making it easier for the end user to read and perform a test case may look like this:

1. Open the application

2. Add any product to a shopping cart

3. Authentication is not needed

4. Proceed to the shopping cart

5. Check out

You may also include expected results in the test case, so the user is aware of what is going to

happen:

1. The product will appear in a shopping cart

2. The system will ask you to authorize as a registered user

Testing your product with real users before launching is a good practice to reduce the number of

overall defects. While end-user testing will not give actual solutions to the problem, it will help to

reveal the problems your developers or QAs could not think of. More importantly, the defects

found before the production stage save your budget, as the product goes to market in a close-to-

perfect form.

Page | 53
Obtaining feedback from Users

Users give their feedback after performing user acceptance testing. This feedback might contain

positive and appreciative comments, bug reports or defects, change requests and new functionalities.

Types of feedback can include:

▪ Bugs / Issues - Users might report any bugs after performing UAT testing. These issues are of

high priority and need to be fixed asap, especially if the bugs are critical in nature.

▪ Change request - Sometimes the user becomes clearer about his requirements, after he has

actually used the application in UAT. They might request you a minor change in system

behavior. Note that change request is not the same as bug. You can negotiate with client and

buy more time to implement change requests.

▪ New functionality - Users might also request for new functionalities. The difference between

change request and new functionality is that change requests occur for functionalities which

have already been implemented but requires some tweaking.

Summary

UAT is performed by users to verify that the application is capable to handle their real-world

problems. It is not performed with the aim of finding maximum defects rather UAT testing is

focused to see how system is behaving as a response to user actions. Although user acceptance

testing has the term ‘Testing’ in it, but it is not performed in the way of professional testers. It is

‘user-oriented’ so the person who conducts UAT needs to understand certain factors that are

essential to smoothly conduct UAT testing. After user acceptance testing is performed, you will

receive UAT testing feedback i.e. bug, change request or new feature request. You take appropriate

actions according to the feedback before the software is deployed on production.

 About the Author

DeEtta Jennings- Balthazar

www.echoicesolutions.com
deettaj@msn.com

Background

DeEtta Balthazar has over 20 years of experience in the Information Technology field. She has an

extensive background in planning and managing cross-functional business operations and

technology projects. Her background includes Project and Product Management, Business/Systems

Analysis and Business Intelligence. DeEtta has managed a broad array of projects in industries

ranging from financial, airline, healthcare, retail, and education. She is the CEO of E-Choice

Solutions Technology Consulting and Training. In addition, she is a published Author of a series of

Business Analysis quick start guides that is currently published on Amazon, Lulu, Barnes & Noble

and iTunes. She holds a master’s degree, Adult Learning Theory, and a Dual bachelor’s degree in

Information Systems / Marketing. She is certified in Agile, Scrum and Business Analysis (CBAP).

Published books: https://echoicesolutions.com/book-store

▪ Introduction to Business Analysis

▪ How to write User Stories

▪ Introduction to Use Cases

Page | 55
 Appendix

Business Analyst Tools

Fundamentally, a business analyst needs the best business analysis tools to perform the following

functions:

1. To track requirements

2. Business process diagram –To model requirements diagrammatically wherever feasible such as

Business Process diagram

3. To collaborate with teams and stakeholders

Below is a list of tools most commonly used for Business Analysis.

Microsoft Office Suite - Microsoft Word or Microsoft Excel can be used for requirement

management like tracking requirements and describing those requirements. Also, Microsoft

PowerPoint to create presentations.

Microsoft Visio - MS Visio is a modelling tool that business analysts use to effectively capture and

present stakeholders’ ideas in the form of business functions and user interactions.

Balsamiq – Many projects require wireframing applications to showcase mockups of a proposed

system. Balsamiq is among top business analysis tools used for creating wireframes.

Google Docs - Sharing project documents come under the collaboration, and nowadays Google

docs prove itself a particularly useful tool for sharing documents online with project members and

stakeholders.

JIRA is a bug tracking and agile project management tool. You can create stories. You can prioritize

the tasks as well.

Zoom - Zoom is a communication tool. It is used for training, webinars, conferencing etc.
 Business Analyst Resources

IIBA (International Institute of Business Analysts)

▪ The International Institute of Business Analysts is the hub for certification, learning and

everything you ever wanted to know about BABOK. While there is no blog in strict terms,

the website is full of resources, quick tips, insights, and news. Website: iiba.org

BA Times

▪ The granddaddy of all business analysis blogs, www.batimes.com is chock full of real-world

advice, methodologies, problem solving posts and career boosting tips. The site also runs

webinars on everything BA-related, provides editable resources ranging from Use Case

documents to Action Plan templates.

Bridging the Gap

▪ Another respected BA publication, www.bridging-the-gap.com is a must-know for anyone

looking to begin, or progress, their Business Analysis career. Blog owner Laura

Brandenburg provides a great mix of content: blog posts, video tutorials, downloadable

resources, and courses.

Modern Analyst

▪ www.modernanalyst.com is aimed at BAs, Systems Analysts, Requirements Engineers and

even the curious Product Manager. It contains a wealth of informative posts on just about

everything related to software prototyping, working with Agile, requirements and

implementation.

Page | 57
 Frequently Used Terms

Acceptance Criteria - Conditions that a software product must satisfy to be accepted by a user,
customer, or other stakeholder

Activity Diagram - is a diagram that shows activities and actions to describe workflows. In the
Unified Modeling Language an activity diagram represents the business and operational step-by-
step workflows of components in a system. An activity diagram shows the overall flow of
control

Actor - Someone or something, outside the system that interacts with the system
Actor class - Defines a set of actor instances, in which each actor instance plays the same role in
relation to the system.

Agile Modeling - Agile Modeling (AM) is a practice-based methodology for effective modeling
and documentation of software-based systems. Simply put, Agile Modeling (AM) is a
collection of values, principles, and practices for modeling software that can be applied on a
software development project in an effective and light-weight manner.

Alternative flow - A scenario in a use case that leads to success (accomplishing the actor’s goal)
but involves a variation from the normal course in the specifics of the task or of the actor’s
interaction with the system.

Analyst - Member of the project team who is responsible for eliciting and interpreting the
stakeholder needs and communicating those needs to the entire team.

Architecture - The structure of a software-containing system, including the software and

hardware components that make up the system, the interfaces and relationships between those
components, and the component behaviors that are visible to other components.

Artifact - A piece of information that (1) is produced, modified, or used by a process, (2)
defines an area of responsibility, and (3) is subject to version control.

Assumption - A statement that is believed to be true in the absence of proof or definitive

knowledge.

BA - Short for Business Analyst. A role in software development, which requires the person to
analyze the business and document or model it such that it may be authenticated and shared
amongst the team for a common understanding.

Baseline, Requirements - A snapshot in time representing the current agreed-upon, reviewed,

and approved set of requirements for a specific product release.

Business Actor - class - Class that defines a set of business actor instances, where each instance
plays the same role in the business.
Business Use Case - class - A Business Use Case Class defines a set of instances which each
deliver an observable result which has value to the business actor.

Business Requirement - Business Requirements - is higher-level statements of the goals,

objectives, or needs of the enterprise. They

Business Rule - A policy, guideline, standard, or regulation that defines or constrains some
aspect of the business.

Change management - The activity of controlling and tracking changes to artifacts

Class - A description of a set of objects that share the same attributes operations, methods,
relationships, and semantics. A class may use a set of interfaces to specify collections of
operations it provides to its environment.

Class diagram - A diagram that shows a collection of declarative (static) model elements, such as
classes, types, and their contents and relationships.

Constraint - A restriction that is imposed on the choices available to the developer for the
design and construction of a product.

Context Diagram - An analysis model that depicts a system at a high level of abstraction. The
context diagram identifies objects outside the system that interact with it, but it shows nothing
about the system’s internal structure or behavior.

Class Model - A Model is a complete set of class diagrams and modeling objects that make up a
meaningful set of pictures which describe what the author is trying to convey.

Design - The part of the software development processes whose primary purpose is to decide
how the system will be implemented.

Event - A trigger or stimulus that takes place in a system’s environment that leads to a system
response such as a functional behavior or a change in state.

Exception - A condition that prevents a use case from successfully concluding. The use case’s
post conditions are not reached, and the actor’s goal is not satisfied.

Extends relationship - A construct in which an alternative course in a use case interrupts the
normal sequence of steps. The steps that the actor follows when executing the alternative
course can be packaged into an extension use case that is invoked to complete the alternative.

Facilitator - A person who is responsible for planning and leading a group activity, such as a
requirements elicitation workshop.

Feature - A set of logically related functional requirements that provides a capability to the user
and enables the satisfaction of a business objective.

Page | 59
Functional Requirement – is a statement of a piece of required functionality or a behavior that a
system will exhibit under specific conditions.

Iteration - A distinct sequence of activities with a base-lined plan and valuation criteria resulting
in a release (internal or external).

Methodology - A methodology is a formalized approach to implementing the Software

Development Lifecycle (SDLC).

Modeling Elements – is an element that is an abstraction of the item being modeled. It is

depicted in a standard diagram notation such as UML. An example of this could be an Actor.
This represents a person or thing outside the system being modeled.

Modeling language - is any artificial language that can be used to express information or
knowledge or systems in a structure that is defined by a consistent set of rules. The rules are
used for interpretation of the meaning of components in the structure.

Non-functional requirement - A description of a property or characteristic that a software

system must exhibit or a constraint that it must respect, other than an observable system
behavior.

Object - an allocated region of storage. An object is a representation of a real-life entity or

abstraction. For example, objects in a flight reservation system might include: an airplane, an
airline flight, an icon on a screen, or even a full screen with which a travel agent interacts.

Object-oriented analysis (OOA) - specifies the structure and the behavior of the object- these
comprise the requirements of that object. Different types of models are required to specify the
requirements of the objects. The information or object model contains the definition of objects
in the system, which includes: the object name, the object attributes, and objects relationships
to other objects.

Objects Oriented Design OOD – is concerned with developing an object-oriented model of a

software system to implement the identified requirements.

Object Oriented Programming OOP –- is a programming paradigm that uses "objects" and
their interactions to design applications and computer programs.
PM - Project manager - A project manager is the person accountable for accomplishing the
stated project objectives. Key project management responsibilities include creating clear and
attainable project objectives, building the project requirements, and managing the triple
constraint for projects, which is cost, time, and scope.
Post condition - A condition that describes the state of a system after a use case is successfully
completed.

Precondition - A Condition that must be satisfied before a use case may begin.

Process -A sequence of activities performed for a given purpose. A process description is a

documented definition of those activities.
Product champion - A designated representative of a specific user class who supplies the user
requirements for the group that he or she represents.

QA - Quality Assurance.

Requirements - A statement of a customer need or objective, or of a condition or capability that

a product must possess to satisfy such a need or objective. A property that a product must have
to provide value to a stakeholder.

Requirement attribute - Descriptive information about a requirement that enriches its definition
beyond the statement of intended functionality. Examples include origin, rationale, priority,
owner, release number, and version number.

Requirements traceability matrix - A table that illustrates logical links between individual
functional requirements and other types of system artifacts, including other functional
requirements, use cases, architecture and design elements, code modules, test cases, and
business rules.

Risk - A condition that could cause some loss or otherwise threaten the success of a project.

RUP - Rational Unified Process - RUP promotes iterative development and organizes the
development of software and systems into four phases, each consisting of one or more
executable iterations of the software at that stage of development.

Scenario - A description of a specific interaction between a user and a system to accomplish

some goal. An instance of usage of the system. Often presented in the form of a story.

Scope - The portion of the ultimate product vision that the current project will address. The
scope draws the boundary between what is in and what is out for the project.

Sequence diagram - An analysis model that shows the order in which messages pass in a system
or the chronological sequence of steps that take place in an activity and the entities or classes
involved in the activity.

Software development Life Cycle (SDLC) - A sequence of activities by which a software

product is defined, designed, built, and verified.

Software requirements specification - A collection of the functional and nonfunctional

requirements for a software product.

Stakeholder - A person, group, or organization that is actively involved in a project, is affected

by its outcome, or can influence its outcome.

State chart diagram - An analysis model that shows the sequence of states that an object in a
system goes through during its lifetime in response to specific events that take place. Similar to
a state-transition diagram.

Page | 61
SME - subject matter expert - An individual who has extensive experience and knowledge in a
domain and who is recognized as an authoritative source of information about the domain.

System Analyst - are responsible for designing computer information systems, modifying
systems to improve production or workflow, or expanding systems to serve new purposes.

Template - A pattern to be used as a guide for producing a complete document or other item.

Terminator - A description of system behavior, in terms of sequences of actions. A use case

should yield an observable result of value to an Actor. A use case contains all alternate flows of
events related to producing the "observable result of value".

Unified Modeling Language (UML) - is a standardized general-purpose modeling language in

the field software engineering. UML includes a set of graphical notation techniques to create
abstract models of specific systems, referred to as UML model.

Use-case diagram - A diagram that shows the relationships among Actors and Use Cases within
a system.

Use-case instance - The performance of a sequence of actions being specified in a use case. An
instance of a use case. A use-case instance is more specific than a use case – Actor is replaced
by specific persons or actor instances, and only one path is taken through the possible alternate
flows of the use case.

Use-case model - A model that describes a system’s functional requirements in terms of use
cases.

User requirement - User goals or tasks that users must be able to perform with a system, or
statements of the user’s expectations of system quality.

Vision - A long-term strategic concept of the ultimate purpose and form of a new system.

Vision and scope document - A document that presents the business requirements for a new
system, including a product vision statement and a project scope description.

Workflow - is a depiction of a sequence of operations, declared as work of a person, work of a

simple or complex mechanism, work of a group of
 References
Heumann, Jim (2003): Introduction to business modeling using the Unified Modeling Language
(UML), developer Works
Gottesdiener, Helen (2005), Software Requirements Memory Jogger
Cohn, Mike, (2019), User Stories Applied: For Agile Software Development, Addison Wesley.
Cohn, Mike. (2005), Agile Estimating and Planning, Addison-Wesley Professional. Cohn, Mike
(2009), Succeeding with Agile: Software Development Using Scrum, Addison-Wesley
Professional. Cohen, Greg (2010), Agile Excellence for Product Managers: A Guide to Creating
Winning Products with Agile Development Teams, Super Star Press. Pichler, Roman (2010),
Agile Product Management with Scrum: Creating Products that Customers Love, Addison-
Wesley Professional. Pixton, Pollyanna, Niel Nickolaisen, Todd Little and Kent Commented [DJ1]:

Websites
https://www.iiba.org/globalassets/standards-and-resources/reports--research/bcs-iiba-
whitepaper.pdf
https://www.batimes.com/
https://www.projectmanagementdocs.com/#axzz6P4QePiZO

Page | 63