Вы находитесь на странице: 1из 60

Introduction to Business Analysis

Who is a Business Analyst?

Business Analysts have emerged to have a key role in recent business scenarios. Some people think that
the role of a Business Analyst is to make money for the organization, which may not be true in direct
context. But indirectly, the action and decision taken by Business Analysts do leave an impact on
the financial prospects of the organization.
A primary job responsibility of Business Analyst is to communicate with all stakeholders & to elicit, analyze
and validate the requirements for changes to business processes, information systems, and policies.
A professional business analyst plays a big role in moving an organization toward efficiency, productivity,
and profitability.
Before we jump into the tutorial, we will see some basic perspective of a Business Analyst to help the
organization succeed. The foremost priority for any business analyst will be to try understanding following

Understand what business does and how it does

Determine how to improve existing business processes
Identify the steps or tasks to support the implementation of new features
Design the new features to implement
Analyze the impact of implementing new features
Implement the new features
Different Business Analyst Role
Business Analyst can be from any sector, and the role differs based on the sector. Business Analyst are
classified into various categories like

Business Analyst
Business Process Analyst
IT Business Analyst
Business System Analyst
System Analyst
Data Analyst
Functional Architect
Usability or UX Analyst
Characteristics of a good Business Analyst
Basically, a good business analyst is judged on these four attributes

Typical Qualities of a Good Business Analyst:

Analytical skills- An outstanding analytical skills will separate out a good business analyst. A good
part of BA role includes analyzing data, workflow, user or stakeholders inputs, documents, etc.
Leadership skills- directing team members, forecasting budget, helping team members with the
problem, etc.
Business process and planning- Planning the project scope, understanding and implementing
requirement of project, identifying resources required for the project and so on
Technical skill- If a business analyst is in the IT sector, few technical aspect are expected to know
like operating systems, hardware capabilities, database concepts, networking, SDLC methodology, etc.
Tools of the Trade
To make their work easier, the business analyst often depends on tools like

TopTeam Analyst: This tool helps in providing a complete solution for requirements gathering and
SmartDraw: It is a graphic diagramming tool that use stencils for organizational charts, swim lanes,
data flow diagram, etc.
Blueprint: This tool produces a blue print of the project artifacts like development models, test
scenarios, use cases, flow charts, etc. to ensure that everything is falling in line and as per expectation
Survey Monkey: It allows you to send survey to stakeholders, capture their feedback, rank and
prioritize their view and turn them into requirements
There are many other tools like iServer, Meetingsense,Ravenflow,AnalystPro, which could be used by
Business Analyst during the project.
As per the International Institute of Business Analysis (IIBA), CBAP (Certified Business Analysis Professional)
certification is a recognized certificate for a professional Business Analyst. They provide two types of
certifications. The certification exam is computer based and consists of multiple choice questions.

Certification of Competency in Business Analysis: Pre-requisite for this certification is atleast 3750
hours of work experience
Certified Business Analysis Profession (senior level): Pre-requisite for this certification is atleast
7500 hours of work experience
For off-shore students, they can appear certification exam online. For more information, you can visit

Job prospectus for Business Analyst rises every year, especially for the IT sector. The average salary of
business analyst is estimated around $80,000 - $130, 000, even at entry level.
International Institute of Business Analysis (IIBA) is growing exponentially indicating increasing demand of
Business Analyst. Business Analyst always remain an organization priority since they have to work in a
close proximity to top executives, clients, and stakeholders.
According to U.S Bureau of Labor Statistics, the BA job are predicted to increase by 19% between 2012 and
The business analyst role is promising and has to deal with different layers of an organization. Business
analyst are classified into various categories like Business Process Analyst, IT Business Analyst and so on.


A good business analyst should encompass skills like

Analytical skills
Leadership skills
Business process and Planning
Technical Skills
Various tools that can help Business Analyst are TopTeam Analyst, SmartDraw, Blueprint, etc.
Online certification course for BA available by recognized institute IIBA
According to U.S Bureau of Labor Statistics, the BA job is predicted to increase by 19% between
2012 and 2022.

Stakeholder Needs Analysis

Stakeholder Analysis is done to map the interest of your stakeholders. It is a process of systematically
analyzing and gathering qualitative information to determine whose interest should be taken into account.
Stakeholder Analysis is important because it helps project leaders and managers to access a stakeholder's
interest, positions, alliances and knowledge related to the project.
When Stakeholder Analysis need to be done?
Stakeholder analysis should always be done at the beginning of a project. Such analysis is helpful in the
drafting of a log frame. Log frame is nothing but a general approach to project planning, monitoring, and
evaluation in the form of a 'logframe matrix'. Whenever log frames are reconsidered during the life cycle of
a project, a stakeholder analysis will be useful. Which means whenever mid-term reviews or annual
monitoring is handled, stakeholder analysis should be the part of it.
Stakeholders Categorization
Stakeholders are categorized into two categories

Internal stakeholders

External stakeholders

Within the organization:




Outside the organization: Government & Trade


Process for Stakeholder Analysis

Following are the primary aspect needs to be considered for stakeholder analysis
Step 1) Identify your stakeholders: Your boss, your team, senior executives, prospective customers, your
family, etc.
Step 2) Assess how those stakeholders could be impacted or have an effect on the organization
Step 3) Prioritize your Stakeholders-

StakeHolder Type


High power, interested people

- Keep satisfied




- Manage closely

Low power, interested people

- Monitor with minimum effort

Low power, less interested people

- Keep informed

Step 4) Identify areas of conflicts (organization vs. stakeholder, stakeholder vs. stakeholder)
Step 5) Prioritize, reconcile and balance stakeholders
Step 6) Align significant stakeholder needs with organizations strategies and actions
Things to take care while dealing with stakeholders

Could you eliminate processes, which do not add stakeholder value?

How would you communicate with stakeholders?
Do your communications encourage stakeholder exchange?
Do you communicate the stakeholder the value of the deal?
Important questions to ask for Stakeholder Analysis

Different attribute check

for stakeholder

Question to ask your stakeholders


Who is paying for the project?

Who will receive the deliverables or profits from the project?
Both from your organization and client organization who will
work with you to implement the project?
Identify the expert for the project domain in the organization.



What direct benefit do stakeholders expect to get from the

What outcomes do stakeholders expect as a result of the
What changes do stakeholders need to make as a result of the
Are there any conflicts of interest amongst the stakeholders?


What legitimate authority do stakeholders have in the

Who controls the project assets and resources?
What degree of influence or negotiation power do your
identified stakeholders carry in the organization?


How much impact stakeholder could have on the project and

does this going to affect the success of the project

Also, you need to figure out when stakeholders will become involved in the following

Project Vision
Project Scope Definition
Business Process Analysis
Needs Elicitation
Requirement Validation
Design reviews
User acceptance testing
You can create a "Participation Matrix Table" for the stakeholders as given below

Participation Type

Needs Assessment







Monitoring & Evaluation

Tips to manage your Stakeholders

Do not complain. Accept stakeholders as they are

For guaranteed success, get the key leadership involved.
Make sure, you involve your stakeholders early in the business analysis process
In case of a sensitive issue, ensure full confidentiality to all stakeholders to win their trust.
To avoid conflicts, help all stakeholders in realizing their personal gains from the project.
Guide to SDLC , STLC & V-Model
This tutorial explains in detail the Software/System Development Life Cycle (SDLC) like the Waterfall
cycle & Iterative cycle like RAID & Agile. And further, it proceeds to explain the V-Model of testing and
STLC (Software Test Life Cycle).
Please be patient. The Video will load in some time. If you still face issue viewing video click here
Video Transcript with Key Takeaways Highlighted:

Suppose, you are assigned a task, to develop a custom software for a client. Now, irrespective of your
technical background, try and make an educated guess about the sequence of steps you will follow, to
achieve the task.

The correct sequence would be.




Activities performed in each stage



Requirement Gathering

Gather as much information as possible about the details &

specifications of the desired software from the client. This is nothing
but the Requirements gathering stage.

Design Stage

Plan the programming language like Java, PHP, .net; database

like Oracle, MySQL, etc. Which would be suited for the project, also
some high-level functions & architecture.

Built Stage

After design stage, it is built stage, that is nothing but actually

code the software

Test Stage

Next, you test the software to verify that it is built as per the
specifications given by the client.

Deployment stage
Maintenance stage

Deploy the application in the respective environment

Once your system is ready to use, you may require to change
the code later on as per customer request

All these levels constitute the waterfall method of software development lifecycle. As you may observe,
thattesting in the model starts only after implementation is done.
But if you are working in the large project, where the systems are complex, it's easy to miss out the key
details in the requirements phase itself. In such cases, an entirely wrong product will be delivered to the
client and you might have to start afresh with the project OR if you manage to note the requirements
correctly but make serious mistakes in design and architecture of your software you will have to redesign
the entire software to correct the error.
Assessments of thousands of projects have shown that defects introduced during requirements &
design make up close to half of the total number of defects.
Also, the costs of fixing a defect increases across the development life cycle. The earlier in life
cycle a defect is detected, the cheaper it is to fix it. As the say, "A stitch in time saves a nine."
To address this concern, the V model of testing was developed where for every phase, in the
Development life cycle there is a corresponding Testing phase

The left side of the model is Software Development Life Cycle - SDLC

The right side of the model is Software Test Life Cycle - STLC
The entire figure looks like a V, hence the name V - model
Apart from V model, there are iterative development models, where development is carried in phases, with
each phase adding a functionality to the software. Each phase comprises of its independent set of
development and testing activities.
Good examples of Development lifecycles following iterative method are Rapid Application
Development, Agile Development
There are numerous development life cycle models. Development model selected for a project
depends on the aims and goals of that project.

Testing is not a stand-alone activity, and it has to adapt the development model chosen for the
In any model, testing should performed at all levels i.e. right from requirements until maintenance.
Lifecycle of a Requirement
Requirement lifecycle involves a number of phases and at times it can be a complicated process. The
nature of the process depends on the methodology you choose for your software development like Agile,
Waterfall, Incremental, etc. Each phase may involve a lot of paperwork and approval procedure. It also
deals with the project documents like a project proposal, project management plan, project scope, and the
business case. Let see some of the common requirement lifecycle required to know for a Business Analyst.

Requirement Definition
It is one of the primary phases of the requirement gathering process commonly known as Requirement
Once the requirement is gathered, it can be organized in folders logically as per product release or sprint.
These requirements are analyzed further to prepare facts and figures for a business analyst to track
possible result based on analysis. This procedure is referred as Impact Assessment.
Requirement Validation
The requirement validation phase includes analyzing the needs or conditions required to meet a new or
altered product considering needs of the various stakeholders.
For the success of any project, validating requirements is very important. Requirement validation includes
checking the specification, wireframe, High Fidelity Simulation, Traceability Analysis, etc.
There are requirement validation tools that do validation with very less human intervention.
Requirement Documentation

Requirement documents should cover following things

Project stakeholders requirement

Business analysis plan
Current state analysis
Scope statement specification
Requirement Management
Requirement Management process includes planning, monitoring, analyzing, communicating and
managing of those requirements. If the requirement is not managed well, the end product will get affected
adversely. There are requirement management tool available online which help you to manage the
requirement with minimum
What is SDLC or Waterfall Model?
Waterfall Model or SDLC, introduced in 1970 by Winston Royce, is a sequential model divided into
different phases of software development activity. Each phase is designed for performing specific activity
during SDLC phase.

Different Phases of Water-Fall Models





Design Stage

Activities performed in each stage

During this phase, detailed requirements of the software

system to be developed are gathered from client
Plan the programming language like Java, PHP, .net
or database like Oracle, MySQL, etc.
Or other high-level technical details of the project

Built Stage

After design stage, it is built stage, that is nothing but

coding the software

Test Stage

In this phase, you test the software to verify that it is built

as per the specifications given by the client.

Deployment stage

Deploy the application in the respective environment

Maintenance stage

Once your system is ready to use, you may later require

change the code as per customer request

When to use SDLC Waterfall Model

Waterfall model can be used when

Requirements are not changing frequently

Application is not complicated and big
Project is short
Requirement is clear
Environment is stable
Technology and tools used are not dynamic and is stable
Resources are available and trained

Advantages and Disadvantages of Waterfall-Model



Before the next phase of development,

each phase must be completed
requirements are well defined


Error can be fixed only during the phase


It is not desirable for complex project where

requirement changes frequently

They should perform quality assurance test

(Verification and Validation) before completing
each stage

Testing period comes quite late in the

developmental process

Elaborate documentation is done at every

phase of the software's development cycle

Documentation occupies a lot of time of

developers and testers

Project is completely dependent on project

team with minimum client intervention

Clients valuable feedback cannot

included with ongoing development phase

Any changes in software is made during the

process of the development

Small changes or errors that arise in the

completed software may cause a lot of problems


What is RAD (Rapid Software Development) Model? Advantages & Disadvantages

RAD or Rapid Software Development process is an adoption of the waterfall model; it targets at developing
software in a short span of time. RAD follow the iterative

RAD model has following phases

Business Modeling
Data Modeling
Process Modeling
Application Generation
Testing and Turnover

It focuses on input-output source and destination of the information. It emphasizes on delivering projects in
small pieces; the larger projects are divided into a series of smaller projects. The main features of RAD
model are that it focuses on the reuse of templates, tools, processes and code.

Different phases of RAD model includes





Data Modeling

Activities performed in RAD Model

On basis of flow of information and distribution between various business

channels, the product is designed

The information collected from business modeling is refined into a set of

data objects that are significant for the business

The data object that is declared in the data modeling phase is transformed
to achieve the information flow necessary to implement a business function


Automated tools are used for the construction of the software, to convert
process and data models into prototypes




As prototypes are individually tested during every iteration, the overall

testing time is reduced in RAD.

When to use RAD model


When system needs to be produced in a short span of time (2-3 months)

When the requirements are known
When the user will be involved all through the life cycle
When technical risk is less
When there is a necessity to create a system that can be modularized in 2-3 months of time
When budget is high enough to afford designers for modeling along with the cost of automated
tools for code generation
Advantages and Disadvantages of RAD
Flexible and adaptable to changes
It is useful when you have to reduce the
overall project risk
It is adaptable and flexible to changes

It can't be used for smaller projects
Not all application is compatible with RAD

When technical risk is high, it is not suitable

It is easier to transfer deliverables as

scripts, high-level abstractions and intermediate
codes are used

If developers are not committed to

delivering software on time, RAD projects can fail

Due to code generators and code reuse,

there is a reduction of manual coding

Reduced features due to time boxing,

where features are pushed to later version to finish
a release in short period

Due to prototyping in nature, there is a

possibility of lesser defects

Reduced scalability occurs because an RAD

developed application begins as a prototype and
evolves into a finished application

Each phase in RAD delivers highest priority

Progress and problems accustomed are

functionality to client

With less people,

increased in short time

hard to track as such there is no documentation to

demonstrate what has been done








What is Incremental model in SDLC? Advantages & Disadvantages

Incremental model are broken down into multiple standalone modules of software development cycle.
These cycles are further divided into smaller and more manageable iterations.

Each iteration passes through the requirements, design, coding and testing phases. And each
subsequent release of the system adds function to the previous release until all designed functionality has
been implemented.

The system is put into production when the first increment is delivered. The first increment is often a core
product where the basic requirements are addressed, and supplementary features are added in the next
increments. Once the core product is analyzed by the client, there is plan development for the next
Characteristics of Incremental module includes

System development is broken down into many mini development projects

Partial systems are successively built to produce a final total system
Highest priority requirement is tackled first
Once the incremented portion id developed, requirements for that increment are frozen

Incremental Phases

Activities performed in incremental phases

Requirement and specification of the software are collected

Requirement Analysis

Some high-end function are designed during this stage


Coding of software is done during this stage


Once the system is deployed, it goes through the testing



When to use Incremental models?

Requirements of the system are clearly understood

When demand for early release of product arises
When team resources are not very well skilled or trained
When high-risk features and goals are involved
Such model is more in use for web application and product based companies
Advantages and Disadvantages of Incremental Model



Software will be generated quickly during

the software life cycle

It requires a good planning designing

It is flexible and less expensive to change

requirements and scope

Problems might cause due to system

architecture as such not all requirements collected
up front for the entire software life cycle

Thought the development stages changes

can be done

Each iteration phase is rigid and does not

overlap each other

This model is less costly compared to

Rectifying a problem in one unit requires

correction in all the units and consumes a lot of


Customer can respond to each built

Errors are easy to be identified

What is Spiral Model? When to Use? Advantages & Disadvantages

The spiral model was first mentioned by Barry Boehm in his 1986paper. It is a combination of a
waterfall model and iterative model. Each phase in spiral model begins with a design goal and ends with
the client reviewing the progress.
The development team in Spiral-SDLC model starts with a small set of requirement and goes through each
development phase for those set of requirements. The development team adds functionality for the
additional requirement in every-increasing spirals until the application is ready for the production phase.

Spiral Model of SDLC spans into four phases:



Activities performed during phase


It includes estimating the cost, schedule and resources for the iteration. It
also involves understanding the system requirements for continuous
communication between the system analyst and the customer

Risk Analysis

Identification of potential risk is done while risk mitigation strategy is

planned and finalized


It includes testing, coding and deploying software at the customer site

Evaluation of software by the customer. Also, includes identifying and
monitoring risks such as schedule slippage and cost overrun

When to use Spiral-SDLC Model?

When project is large

When releases are required to be frequent
When creation of a prototype is applicable
When risk and costs evaluation is important
For medium to high-risk projects
When requirements are unclear and complex
When changes may require at any time
When long term project commitment is not feasible due to changes in economic priorities
Advantages and Disadvantages of Spiral Model



Additional functionality or changes can be

done at a later stage
Cost estimation becomes easy as
prototype building is done in small fragments


Risk of not meeting the schedule or budget

It works best for large projects only also

demands risk assessment expertise

Continuous or repeated development helps

in risk management

For its smooth operation spiral

protocol needs to be followed strictly

Development is fast and features are added

in a systematic way

intermediate phases

There is always a space for customer


It is not advisable for smaller project, it

might cost them a lot







Agile Model and Methodologies: Guide for Developers and Testers

To understand the concept of agile testing, first let's understandWhat is Agile?
AGILE is a methodology that promotes continuous iteration of development and testing throughout the
software development life cycle of the project. Both development and testing activities are concurrent
unlike the Waterfall model
I hope we got an idea of Agile!!! Now, we can step on to Agile Testing.

The agile software development emphasizes on four core values.


Individual and team interactions over processes and tools


Working software over comprehensive documentation


Customer collaboration over contract negotiation


Responding to change over following a plan

Agile versus Waterfall Method

Agile and Waterfall model are two different methods for software development process. Though they are
different in their approach, both methods are useful at times, depending on the requirement and the type
of the project.

Agile Model

Waterfall Model

incremental and iterative approach to
software design

sequentially from start point to end point.

The agile process is broken

into individual models that designers
work on

The design process is not broken into an

individual models

The customer has early and

frequent opportunities to look at the
product and make decision and
changes to the project

The customer can only see the product at the

end of the project

Agile model is considered

waterfall model

Waterfall model are more secure because they

are so plan oriented

implemented very quickly. For large
projects, it is difficult to estimate the
development time.

All sorts of project can be estimated and


Error can be
middle of the project.


Only at the end, the whole product is tested. If

the requirement error is found or any changes have to
be made, the project has to start from the beginning

iterative, and the project is executed
in short (2-4) weeks iterations.
Planning is very less.

The development process is phased, and the

phase is much bigger than iteration. Every phase
ends with the detailed description of the next phase.

Documentation attends less

priority than software development

Documentation is a top priority and can even

use for training staff and upgrade the software with
another team

Every iteration has its own

testing phase. It allows implementing
regression testing every time new
functions or logic are released.

Only after the development phase, the testing

phase is executed because separate parts are not
fully functional.

In agile testing when an

iteration end, shippable features of
the product is delivered to the
customer. New features are usable
right after shipment. It is useful when

All features developed are delivered at once

after the long implementation phase.








Testers and developers work


Testers work separately from developers

At the end of every sprint,

user acceptance is performed

User acceptance is performed at the end of

the project.

communication with developers and
together analyse requirements and

Developer does not involve in requirement and

planning process. Usually, time delays between tests
and coding

Methodologies of Agile Testing

There are various methods present in agile testing, and those are listed below:
SCRUM is an agile development method which concentrates specifically on how to manage tasks within a
team based development environment. Basically, Scrum is derived from activity that occurs during a rugby
match. Scrum believes in empowering the development team and advocates working in small teams (say7 to 9 members). It consists of three roles, and their responsibilities are explained as follows:

Scrum Master
Master is responsible for setting up the team, sprint meeting and removes obstacles to

Product owner
The Product Owner creates product backlog, prioritizes the backlog and is responsible for the
delivery of the functionality at each iteration
Scrum Team
Team manages its own work and organizes the work to complete the sprint or cycle
Product Backlog
This is a repository where requirements are tracked with details on the no of requirements to be completed
for each release. It should be maintained and prioritized by product owner, and it should be distributed to
the scrum team. Team can also request for a new requirement addition or modification or deletion
Scrum Practices
Practices are described in detailed:

Process flow of Scrum:

Process flow of scrum testing is as follows:

Each iteration of a scrum is known as Sprint

Product backlog is a list where all details are entered to get end product
During each Sprint, top items of Product backlog are selected and turned into Sprint backlog
Team works on the defined sprint backlog
Team checks for the daily work
At the end of the sprint, team delivers product functionality
eXtreme Programming (XP)
Extreme Programming technique is very helpful when there is constantly changing demands or
requirements from the customers or when they are not sure about the functionality of the system. It
advocates frequent "releases" of the product in short development cycles, which inherently improves the
productivity of the system and also introduces a checkpoint where any customer requirements can be
easily implemented. The XP develops software keeping customer in the target.

Business requirements are gathered in terms of stories. All those stories are stored in a place called the
parking lot.
In this type of methodology, releases are based on the shorter cycles called Iterations with span of 14 days
time period. Each iteration includes phases like coding, unit testing and system testing where at each
phase some minor or major functionality will be built in the application.
Phases of eXtreme programming:
There are 6 phases available in Agile XP method, and those are explained as follows:

Identification of stakeholders and sponsors

Infrastructure Requirements
Security related information and gathering
Service Level Agreements and its conditions

Capturing of Stories in Parking lot

Prioritize stories in Parking lot
Scrubbing of stories for estimation
Define Iteration SPAN(Time)
Resource planning for both Development and QA teams

Break down of tasks

Test Scenario preparation for each task
Regression Automation Framework

Unit Testing
Execution of Manual test scenarios
Defect Report generation
Conversion of Manual to Automation regression test cases

Mid Iteration review

End of Iteration review

Small Releases
Regression Testing
Demos and reviews
Develop new stories based on the need
Process Improvements based on end of iteration review comments

Pilot Launch
Production Launch
SLA Guarantee assurance
Review SOA strategy
Production Support
There are two storyboards available to track the work on a daily basis, and those are listed below for

Story Cardboard
This is a traditional way of collecting all the stories in a board in the form of stick notes to
track daily XP activities. As this manual activity involves more effort and time, it is better to switch to an
online form.

Online Storyboard
Online tool Storyboard can be used to store the stories. Several teams can use it for
different purposes.
Crystal Methodologies
Crystal Methodology is based on three concepts


Chartering: Various activities involved in this phase are creating a development team, performing
a preliminary feasibility analysis, developing an initial plan and fine-tuning the development methodology


Cyclic delivery: The main development phase consists of two or more delivery cycles, during
which the


Team updates and refines the release plan


Implements a subset of the requirements through one or more program test integrate


Integrated product is delivered to real users


Review of the project plan and adopted development methodology


Wrap Up: The activities performed in this phase are deployment into the user environment, postdeployment reviews and reflections are performed.
Dynamic Software Development Method (DSDM)
DSDM is a Rapid Application Development (RAD) approach to software development and provides an agile
project delivery framework. The important aspect of DSDM is that the users are required to be involved
actively, and the teams are given the power to make decisions. Frequent delivery of product becomes the
active focus with DSDM. The techniques used in DSDM are


Time Boxing


MoSCoW Rules


The DSDM project consists of 7 phases




Feasibility Study


Business Study


Functional Model Iteration


Design and build Iteration




Feature Driven Development (FDD)
This method is focused around "designing & building" features. Unlike other agile methods, FDD describes
very specific and short phases of work that has to be accomplished separately per feature. It includes
domain walkthrough, design inspection, promote to build, code inspection and design. FDD develops
product keeping following things in the target


Domain object Modeling


Development by feature


Component/ Class Ownership


Feature Teams




Configuration Management


Regular Builds


Visibility of progress and results

Lean Software Development
Lean software development method is based on the principle "Just in time production". It aims at
increasing speed of software development and decreasing cost. Lean development can be summarized in
seven steps.


Eliminating Waste


Amplifying learning


Defer commitment (deciding as late as possible)


Early delivery


Empowering the team


Building Integrity


Optimize the whole

Kanban originally emerged from Japanese word that means, a card containing all the information
needed> to be done on the product at each stage along its path to completion. This framework or method
is quite adopted in software testing method especially in agile testing.

Difference between Scrum and Kanban



In scrum technique, test must be broken

down so that they can be completed within one
Prescribes a prioritized product backlog
Scrum team commits to a particular
amount of work for the iteration
Burndown chart is prescribed
Between each sprint, a scrum board is

No particular item size is prescribed

Prioritization is optional
Commitment is optional

No particular item size is prescribed

A Kanban board is persistent. It limits the
number of items in workflow state

It cannot add items to ongoing iteration

It can add items whenever capacity is available

WIP limited indirectly

WIP limited directly

Timeboxed iterations prescribed

Timeboxed iterations optional

Agile metrics:
Metrics that can be collected for effective usage of Agile is:


Drag Factor
Effort in hours which do not contribute to sprint goal
Drag factor can be improved by reducing number of shared resources, reducing the amount
of non-contributing work
New estimates can be increased by percentage of drag factor -New estimate = (Old
estimate+drag factor)
Amount of backlog converted to shippable functionality of sprint
No of Unit Tests added
Time taken to complete daily build
Bugs detected in an iteration or in previous iterations
Production defect leakage

Learn Software Requirements Analysis with Case Study

Software requirement is a functional or non-functional need to be implemented in the system. Functional
means providing particular service to the user.
For example, in context to banking application the functional requirement will be when customer selects
"View Balance" they must be able to look at their latest account balance.
Software requirement can also be a non-functional, it can be a performance requirement. For example, a
non-functional requirement is where every page of the system should be visible to the users within 5

So, basically software requirement is a

Functional or
need that has to be implemented into the system. Software requirement are usually expressed as a
Types of Requirements


Business requirements: They are high-level requirements that are taken from the business case
from the projects.
For example, a mobile banking service system provides banking services to Southeast Asia. The business
requirement that is decided for India is account summary and fund transfer while for China account
summary and bill payment is decided as a business requirement



Company providing Banking Functionalities or services


Account Summary and Fund Transfer


Account Summary and Bill Payment

Architectural and Design requirements: These requirements are more detailed than business
requirements. It determines the overall design required to implement the business requirement.
For our educational organization the architectural and design use cases would be login, course detail, etc.
The requirement would be as shown below.

Banking use case


Bill Payment

This use case describes how a customer can login into net banking and
use the Bill Payment Facility.
The customer will can see a dashboard of outstanding bills of registered
billers. He can add, modify, and delete a biller detail. The customer can
configure SMS, email alerts for different billing actions. He can see
history of past paid bills.
The actors starting this use case are bank customers or support


System and Integration requirements: At the lowest level, we have system and integration
requirements. It is detailed description of each and every requirement. It can be in form of user stories
which is really describing everyday business language. The requirements are in abundant details so that
developers can begin coding.
Here in example of Bill Payment module where requirement will be mentioned for adding a Biller

Bill Payment

Add Billers


Utility Provider Name

Relationship/Customer Number
Auto Payments Yes/No
Pay Entire Bill Yes/No
Auto Payment Limit Do not pay if Bill is over specified amount

Sometimes for some project you might not receive any requirements or documents to work with. But still
there are other sources of requirements that you can consider for the requirement or information, so that
you can base your software or test design on these requirements. So the other sources for requirement
you can rely on are
Other Sources of Requirements

Knowledge transfer from colleagues or employees already working on that project

Talk about project to business analyst, product manager, project lead and developers
Analyze previous system version that is already implemented into the system
Analyze the older requirement document of the project
Look into the past Bug reports, some of the bug reports are turned into enhancement request which
may be implemented into current version
Look into installation guide if it is available to see what are the installation required
Analyze the domain or industry knowledge that team is trying to implement
Whatever source of requirement you get make sure to document them in some form, get them reviewed
from other experienced and knowledgeable team members.
How to Analyze Requirements
Consider example of an educational software system where a student can register for different courses.
Lets study how to analyze the requirements. The requirements must maintain a standard quality of its
requirement, different types of requirement quality includes

Uniquely identified
Consistent and unambiguous

Let understand this with an example, there are three columns in the table shown here,

The first column indicates- "requirement quality"


The second column indicates- "bad requirement with some problem"


The third column is same as second column but "converted into a good requirement".

t Quality

Example of bad requirement

Example of good requirement


Students will be able to enroll to

undergraduate and post graduate courses

Students will be able to enroll to

undergraduate courses
Students will be able to enroll to postgraduate courses


1- Students will be able to enroll to
undergraduate courses
1- Students will be able to enroll to postgraduate courses


A professor user will log into the system

by providing his username, password, and
other relevant information

Course Enrolment
Students will be
undergraduate courses





Students will be able to enroll to postgraduate courses

A professor user will log into the system by

department code


A student will have either undergraduate

courses or post-graduate courses but not

A student will have either under-graduate or

post graduates but not both

Some courses will be open to both undergraduate and post-graduate


Maintain student information-mapped to

BRD req.ID?

Maintain student information-Mapped to BRD

req ID 4.1


Registered student-Priority 1

Register Student-Priority 1

Maintain User Information-Priority 1

Maintain User Information-Priority 2

Enroll courses-Priority 1

Enroll courses-Priority 1

View Report Card-Priority 1

View Report Card-Priority3

Each page of the system will load in an

acceptable time-frame

Register student and enrol courses pages of the

system will load within 5 seconds


Now let's understand each of these requirement in details starting with Atomic.

So each and every requirement you have should be atomic, which means it should be at very low level of
details it should not be possible to separated out into components. Here we will see the two examples for
requirements, at Atomic and uniquely identified requirements levels.
So let us continue with example of system build for education domain. Here, the bad requirement is
"Students will be able to enroll to undergraduate and post graduate courses" . This is a bad requirement
because it is not atomic because it talks about two different entities undergraduates and post-graduates
courses. So obviously it is not a good requirement but bad requirement, so correspondence good
requirement would be to separate it out into two requirements. So one talks about the enrolment to
undergraduate courses while the other talks about the enrolment to the post-graduate courses.

Uniquely Identified

Similarly the next requirement quality is to check for uniquely identified, here we have two separate
requirement but they both have same ID#1. So, if we are referring our requirement with reference to ID#,
but it is not clear which exact requirement we are referring to document or other part of the system as
both have same ID#1. So separating out with unique id's, so good requirement will be re-return as section
1- course enrolments, and it has two requirements 1.1 id is enrolment to undergraduate courses while 1.2
id is enrolment to postgraduate courses.

Also, each and every requirement should be complete. For example, here the bad requirement says a
"professor user will log into the system by providing his username, password and other relevant
information". Here the other relevant information is not clear, so the other relevant information should be
spelt out in good requirement to make the requirement complete.
Consistent and Unambiguous

Next each and every requirement should be consistent and unambiguous, so here for instance we have
requirements "A student will have either undergraduate courses or post-graduate courses but not both"
this is one requirement there is some other requirement that says "Some courses will be open to both
under-graduate and post-graduate students".
The problem in this requirement is that from the first requirement it seems that the courses are divided
into two categories under graduate courses and post graduate courses and student can opt either of two
but not both. But when you read other requirement it conflicts with the first requirement and it tells that
some courses will open to both post-graduate and under-graduate.
So it is obvious to convert this bad requirement into good requirement which is "A student will have either
under-graduate courses or post-graduate courses but not both". Which means that every course will be
marked either being as under-graduate course or post-graduate course


Each and every requirement should be traceable because there are already different levels of requirement,
we already saw that at the top we had business requirements, and then we have an architectural and
design requirements followed by system integration requirements.
Now when we convert business requirement into architectural and design requirements or we convert
architectural and design requirements to system integration requirements there has to be traceability.
Which means that we should be able to take each and every business requirements and map it to the
corresponding one or more software architectural and design requirement. So here is an example of bad
requirement that says "Maintain student information mapped to BRD req ID?" the requirement id is not
given over here.
So converting it to a good requirement it says same thing but it is mapped with the requirement id 4.1. So
mapping should be there for each and every requirement. Same way we have high level and low level
mapping requirement, the mapping is also there between system and integration requirement to the code
that implements that requirement and also there is a mapping between the system and integration
requirement to the test case which test that particular requirement.
So this traceability is all across entire project


Registered student-Priority 1

Register Student-Priority 1

Maintain User Information-Priority 1

Priority 2



Enroll courses-Priority 1
Enroll courses-Priority 1
View Report Card-Priority 1
View Report Card-Priority3

Then each and every requirement must be prioritized, so the team has guideline so which requirement
that able to implement first and which can be done later on. Here you can see the bad priority has register
student, maintain user information and each and every requirement has given priority-1. Everything
cannot be at same priority, so requirement can be prioritized. So the example of good requirement over
here is the register student and enroll courses is given the highest priority 1, while maintain user
information comes below at priority 2 and then we have view report card at priority-3


Each page of the system will load in an

acceptable time-frame

Register student and enrol courses pages of

the system will load within 5 seconds

Each and every requirement should be testable, here the bad requirement is "each page of the system will
load in an acceptable time frame". Now there are two problems with this requirement first is that each
page meaning that there can be many pages, which going to blow up the testing efforts. The other
problem is that it say the page is going to load in acceptable time frame, now what is acceptable time
frame? Acceptable to whom. So we have to convert the non-testable argument into a testable argument,
which specifically tells about which page we are talking about "register student and enroll courses pages"
and the acceptable time frame is also given which is 5 seconds.
So this is how we have to look at each and every requirement at appropriate level. For example, if we are
going to build a software with regards to system and integration requirements. We have to look in system
and integration requirements given in the software requirement specifications or user stories and apply to
each and every requirement quality. Then check whether each and every requirement is atomic, uniquely
identified, and complete and so on.
Requirements Analysis and Transformation Techniques
As a Business Analyst, requirement analysis is the most important part of your Job. It will help you
determining the actual needs of stakeholders. At the same time, enable you to communicate with
the stakeholders in a language they understand (like charts, models, flow-charts,) instead of complex text.
A requirement analysis has a

Specific Goal
Specific Input
Specific Output
Uses resources
Has a number of activities to be performed in some order
May affect more than one organization unit
Creates value of some kind for the customer
Requirement Analysis Techniques
Requirement analysis techniques are mainly used to map the business workflow so that you can analyze,
understand and make required changes to that workflow or process.
There are various requirement analyzing techniques that can be used as per the software development
process like


Business process modeling notation (BPMN)

BPMN (Business Process Modeling & Notation) is a graphical representation of your business process using
simple objects, which helps the organization to communicate in a standard manner. Various objects used in
BPMN includes

Flow objects
Connecting objects
Swim lanes
A well design BPMN model should be able to give the detail about the activities carried out during the
process like,
Who is performing these activities?


What data elements are required for these activities?

The biggest benefit of using BPMN is that it is easier to share, and most modeling tools support BPMN.

UML (Unified Modeling Language)

UML is a modelling standard primarily used for specification, development, visualization and documenting
of software system. To capture important business process and artifacts UML provides objects like


Class diagram
There are 14 UML diagrams that help with modelling like the use case diagram, interaction diagram, class
diagram, component diagram, sequence diagram, etc. UML models are important in the IT segment as it
becomes the medium of communication between all stakeholders. A UML-based business model can be a
direct input to a requirements tool. A UML diagram can be of two type's Behavioral model and Structural
model. A behavioral model tries to give information about what the system do while a structural model will
give what is the system consist of.

Flow chart technique

A flowchart is a visual representation of the sequential flow and control logic of a set of related activities or
actions. There are different formats for flowcharts which include Linear, Top-down and cross-functional

(swim lanes). A flow chart can be used for different activities like representing data flows, system
interactions, etc. The advantage of using Flowchart is that it can be easy to read and write even for nontechnical team members, and can show the parallel process by function, critical attributes of a process,


Data flow diagram

Data flow diagrams show how data is processed by a system in terms of inputs and outputs. Components
of data flow diagram includes


A logical data flow diagram shows system's activities while a physical data flow diagram shows a system's
infrastructure. A data flow diagram can be designed early in the requirement elicitation process of the
analysis phase within the SDLC (System Development Life Cycle) to define the project scope. For easy
analyzing a data flow diagram can be drilled down into its sub-processes known as "levelled DFD".

Role Activity Diagrams- (RAD)

Role activity diagram is similar to flowchart type notation. In Role Activity Diagram, role instances are
process participants, which has start and end state. RAD requires a deep knowledge of process or
organization to identify roles. The components of RAD includes

External events

Roles group activities together into units of responsibility, according to the set of responsibility they are
carrying out. An activity can be carried out in isolation with a role, or it may require coordination with
activities in other roles.
External events are the points at which state changes occur.
States are useful to map activities of a role as it progresses from state to state. When a particular state is
reached, it indicates that a certain goal has been achieved.
RAD is helpful in supporting communication as it is easy to read and present a detailed view of the process
and permitting activities in parallel.

Gantt Charts
A Gantt chart is a graphical representation of a schedule that helps to coordinate, plan and track specific
tasks in a project. It represents the total time span of the object, broken down into increments. A Gantt
chart represents the list of all task to be performed on the vertical axis while, on the horizontal axis, it list
the estimate activity duration or the name of the person allocated to the activity. One chart can
demonstrate many activities.


IDEF (Integrated Definition for Function Modeling)

IDEF or Integrated Definition for Function Modeling is a common name referred to classes of enterprise
modeling languages. It is used for modeling activities necessary to support system analysis, design or
integration. There are about 16 methods for IDEF, the most useful versions of IDEF are IDEF3 and IDEF0.


Colored Petri Nets (CPN)

CPN or colored petri nets are graphically oriented language for specification, verification, design and
simulation of systems. Colored Petri Nets is a combination of graphics and text. Its main components
arePlaces, Transitions, and Arcs.

Petri nets objects have specific inscription like for

Places: It has inscription like .Name, .Color Set, .Initial marking etc. While
Transition : lt has inscription like .Name (for identification) and .Guard (Boolean expression consist
of some of the variables)

Arcs: It has inscription like .Arc. When the arc expression is assessed, it yields multi-set of token
Workflow Technique
Workflow technique is a visual diagram that represent one or more business processes to clarify
understanding of the process or to make process improvement recommendations. Just like other diagrams
like flowcharting, UML activity and process map, the workflow technique is the oldest and popular
technique. It is even used by BA for taking notes during requirements elicitation. The process comprises of
four stages


Information Gathering
Workflow Modeling
Business process Modeling
Implementation, Verification & Execution
Object oriented methods
Object-oriented modeling method uses object oriented paradigm and modeling language for designing a
system. It emphasis on finding and describing the object in the problem domain. The purpose of object
oriented method is

To help characterizing the system

To know what are the different relevant objects
How do they relate to each other
How to specify or model a problem to create effective design
To analyze requirements and their implications
This method is applicable to the system which has dynamic requirements (changes frequently). It is a
process of deriving use cases, activity flow, and events flow for the system. Object oriented analysis can
be done through textual needs, communication with system stakeholder and vision document.
The object has a state, and state changes are represented by behavior. So, when the object receives a
message, state changes through behavior.


Gap Analysis
Gap Analysis is the technique used to determine the difference between the proposed state and current
state for any business and its functionalities. It answers questions like what is the current state of the
project? Where do we want to be? etc. Various stages of Gap Analysis include

Review System
Development Requirements
How to Present Requirements as a Business Analyst
A business requirement is a formal document that addresses the need of the stakeholders for the project
or product. There is no standard format to present the business requirement. However, it should cover the
product or project description in enough detail to discuss, analyze, document and validate.
A business requirement can be presented in any of the following ways

A table or a spreadsheet
A diagram (workflow)
A graph
A model ( entity-relationship diagram)
A prototype or simulation
A structured sentence or text template
How to organize and present a business requirement
Step 1) Categorize the requirements

Place specific requirement to its relevant categories

For technical stakeholders there should be technical requirement category, for non-technical
stakeholders there should be generic requirement category
Each organization should figure out which category suits their standards
Categorization can also be done based on their types (functional versus business). Though this is
not applicable to all cases
Step 2) Gather and arrange requirements in a logical order. So when stakeholders review the
requirements, it is easy to navigate and also identify missing items.
Step 3) Prepare a list of the requirements that is meant to be reviewed by specific stakeholders.
For example, if a stakeholder is from technical background then he would like to know only the technical
aspect of the product
Step 4) If tracing requirement to each other is difficult then use unique identifiers, ease in traceability.
Step 5) In certain scenarios, you might have to present same requirement in different ways for different
stakeholders. For example, one stakeholder prefers a graphical format while other prefers a structured
sentence format
Step 6) Prepare a table of content for all the requirements, it helps stakeholder to easily track
Step 7) Use tools that help in presenting and categorizing the requirements
Step 8) In your requirement document, remove all unnecessary requirements, and organize requirement
documents by process flow
Step 9) Map the requirements you have gathered to a particular step in a process flow, this will help
reviewers to relate requirement to process flow
Step 10) Use a table for presenting complex requirement. Use bullet points to highlight the key aspect of
Useful tips for presenting requirements
For better presentation and tracking of requirements for stakeholder, here are some tips that might be
helpful to BA.

Categorizing requirement is time-consuming and may not be feasible for every organization to
create new category each time. For best practice, it is recommended that there should be a standard set of
categories which can be commonly used by BAs, stakeholders, subject experts and technical teams
Your requirement should be prepared in context to your audience. Understand who are the key
players, influencers and decision makers. (Stakeholders, technical staff, developers, etc.)
Define one requirement at a time. Each requirement should be atomic
Avoid ambiguity by avoiding acronyms like etc., approx., and so on
Do not refer to a requirement that is yet to be defined
Avoid duplicate and contradictory statements
Break complex requirement into manageable and reviewable points
Avoid describing how the system will do something only mention what system will do
Change Control for IT Business Analyst
What is Change Control?

Change Control is the process that a company uses to document, identify and authorize changes to
an IT environment. It reduces the chances of unauthorized alterations, disruption and errors in the system.
Why require Change Control?
Whenever any new or different changes are requested for the system, especially by stakeholders, it is
neither optional nor ignorable. It has to be implemented without affecting other components of the system.
This is when the change control comes handy. It helps project teams to modify the scope of the project
using specified controls and policies. Change Control is practiced whenever a project is not progressing as
It is mandatory that a formal document for change request is completed and reviewed in order to keep
control of change requests.
Number of question one might encounter while analyzing Change Control like

Who will approve the change?

Does it require to run through a change control board?
How much time will be required to research and implement the change?
What are the impacts of changes to other components of the system (schedules, cost, resources,

Is there any threshold under which the project management can approve it?
Different factors of Change Control process
There are various factors that a Change Control process should consider
Steps in



Action taken in Change Control

Change request initiation

and Control

Request for changes should be standardized and subject to

management review
Change requestor should be kept informed

Impact Assessment

Make sure that all requests for change are assessed in a

structured way for analyzing possible impacts

Documentation of Changes


A change log should be maintained that tells the date, person

details who made changes and changes implemented
Only authorized individual should be able to make changes
A process for rolling back to the previous version should be



Whenever system changes are implemented the procedures

and associated document should update accordingly

Authorized Maintenance

Testing and User signoff

Version Control

System access
unauthorized access







Software should be thoroughly tested

Control should be placed on production source code to make
sure that only the latest version is updated

Emergency Changes

A verbal authorization should be obtained, and the change

should be documented as soon as possible

Process of Change Control

Before we look into what is involved in Change Control process, we will get familiarize with what
documents are used in Change Control. While carrying out Change Control, there are mainly two
documents involved

Change Log: A change log is a document that list the details about all the Change Requests like
project number, PCR (project change request) ID, priority, Owner details, Target date, status and status
date, raised by, date when raised etc.

Change Request Form: It is used to document details required to support the decision making
process like type of change, benefits of change, name of resource requesting the change, time and
estimate cost, priority of change, authorized person detail, change request status etc.

Change Process Flow-Diagram

Change Process follows a specific pattern to implement the changes in the product or system. Here
through flow-diagram we explained what are the steps involved in the Change Process.

Steps for Change Control

Steps for Change Control




Identify the need for a change and describe it on the project

change request form



If the change is not valid, it has to be deferred or rejected

Determine appropriate resources required to analyze the
change request
Perform quick assessment of the potential impact and
update the change request form
At this stage, rejected change request should stopped

Change request analysis

For analysis assign the change request to an authorized

Deferred change re-enter this analysis step
At this stage, rejected change request should stopped

Change request approval

Identify change risk and complexity level before approval

Identify the impact level of the change before approval
Review impact of Change Request to authorized person for
At this stage, rejected change request should stopped



Update project procedure and management plans


Inform about the changes to the team

Monitor progress of change request
Record the completion of change request
Close change request

NOTE: The approval for Change Control may be done by Project Manager, Lead IT or Lead Developer,
Change Management Vs Change Control
Change Management


It is responsible for managing and controlling

change requests to effect changes to the IT
infrastructure or any aspect of IT services to
minimize the risk of disruption of services and
promoting business benefit
RS Vs SRS : The Myth Busted
Before we begin you must know
The difference between a Requirement and a Specification


They outline what the software must do

They outline how the software will be created

They outline the software from the end-user ,

business and stakeholder perspective.

They outline the software from the technical team


There are a plethora of terms and terminology for various documents

Specification Documents like

SRS - System Requirement Specifications

FRS - Functional Requirement Specifications
BRS - Business Requirement Specification
CRS- Compatibility Requirements Specifications
PRS - Performance Requirements Specifications
RRS- Reliability Requirements Specifications
CRS-Configurations Requirements Specification
Requirement Documents like -

BRD - Business Requirement Document

SRD - System Requirement Document
Points To Ponder

In many places these documents are not separate and are used interchangeably.

Specifications and requirements roughly communicate the same information, but to two completely
different audiences.
For a given project which documents of above are created, depends on the nature of the project
and the organizational processes
In this tutorial we will discuss SRS and BRS

BRS ( Business Requirement Specification)

SRS (System Requirement Specification)

It describes at very high level the functional

specifications of the software

It describes at a high level , the functional and

technical specification of the software

It is a formal document describing about the

requirement provided by client (written, verbal)

It specifies the functional and non-functional

requirements of the software to be developed

Usually its created by the Business Analyst who

interacts with clients

Usually its created by the System Architect who is

an technical expert .
Though in smaller companies the BA will create
SRS as well.
Some companies do not create SRS altogether.
Their BRS is detailed enough to be used as SRS as

It is derived





It is derived from the BRS

Introduction to Software Testing & its Importance

This tutorial introduces software testing to the audience and justifies its importance.

Please be patient. The Video will load in some time. If you still face issue viewing video click here
Video Transcript with Key Takeaways Highlighted:

Software testing is a process used to identify the correctness, completeness, and

quality of developed computer software. It includes a set of activities conducted with the intent of
finding errors in software so that it could be corrected before the product is released to the end users.
In simple words, software testing is an activity to check whether the actual results match
the expected results and to ensure that the software system is defect free.
Why is testing is important?
This is China Airlines Airbus A300 crashing due to a software bug on April 26, 1994, killing 264
innocent lives
Software bugs can potentially cause monetary and human loss, history is full of such examples
In 1985, Canada's Therac-25 radiation therapy machine malfunctioned due to software bug and
delivered lethal radiation doses to patients, leaving 3 people dead and critically injuring 3 others
In April of 1999, a software bug caused the failure of a $1.2 billion military satellite launch, the
costliest accident in history
In may of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to
be credited with 920 million US dollars
As you see, testing is important because software bugs could be expensive or even
As Paul Elrich puts it - "To err is human, but to really foul things up you need a computer."
What is User Acceptance Testing (UAT)?
User acceptance is a type of testing performed by the Client to certify the system with respect to the
requirements that was agreed upon. This testing happens in the final phase of testing before moving the
software application to Market or Production environment.

The main purpose of this testing is to validate the end to end business flow. It does NOT focus on the
cosmetic errors, Spelling mistakes or System testing. This testing is carried out in separate testing
environment with production like data setup. It is a kind of black box testing where two or more end users
will be involved.
Who Performs UAT?

End users

Need of User Acceptance Testing:

Once a software has undergone Unit, Integration and System testing the need of Acceptance Testing may
seem redundant. But Acceptance Testing is required because

Developers code software based on requirements document which is their "own" understanding of
the requirements and may not actually be what the client needs from the software.
Requirements changes during the course of the project may not be communicated effectively to the
Acceptance Testing and V-Model
In VModel, User acceptance testing corresponds to the requirement phase of the Software Development
life cycle(SDLC).

How is UAT Performed

Prerequisites of User Acceptance Testing:
Following are the entry criteria for User Acceptance Testing:

Business Requirements must be available.

Application Code should be fully developed
Unit Testing, Integration Testing & System Testing should be completed
No Showstoppers, High, Medium defects in System Integration Test Phase Only Cosmetic error are acceptable before UAT
Regression Testing should be completed with no major defects
All the reported defects should be fixed and tested before UAT
Traceability matrix for all testing should be completed
UAT Environment must be ready
Sign off mail or communication from System Testing Team that the system is ready for UAT
User Acceptance Testing Process:

UAT is done by the intended users of the system or software. This testing usually happens at the client
location which is known as Beta Testing. Once Entry criteria for UAT are satisfied, following are the tasks
need to be performed by the testers:

Analysis of Business Requirements

Creation of UAT test plan
Identify Test Scenarios
Create UAT Test Cases
Preparation of Test Data(Production like Data)
Run the Test cases
Record the Results
Confirm business objectives
Analysis of Business Requirements
One of the most important activities in the UAT is to identify and develop test scenarios. These test
scenarios are derived from the following documents:

Project Charter
Business Use Cases
Process Flow Diagrams
Business Requirements Document(BRD)
System Requirements Specification(SRS)
Creation of UAT Plan:
The UAT test plan outlines the strategy that will be used to verify and ensure an application meets its
business requirements. It documents entry and exit criteria for UAT, Test scenarios and test cases
approach and timelines of testing.
Identify Test Scenarios and Test Cases:
Identify the test scenarios with respect to high level business process and create test cases with clear test
steps. Test Cases should sufficiently cover most of the UAT scenarios. Business Use cases are input for
creating the test cases.
Preparation of Test Data:

It is best advisable to use live data for UAT. Data should be scrambled for privacy and security reasons.
Tester should be familiar with the data base flow.
Run and record the results:
Execute test cases and report bugs if any. Re-test bugs once fixed. Test Management tools can used for
Confirm Business Objectives met:
Business Analysts or UAT Testers needs to send a sign off mail after the UAT testing. After sign-off the
product is good to go for production. Deliverables for UAT testing are Test Plan, UAT Scenarios and Test
Cases, Test Results and Defect Log
Exit criteria for UAT:
Before moving into production, following needs to be considered:

No critical defects open

Business process works satisfactorily
UAT Sign off meeting with all stakeholders
Qualities of UAT Testers:

UAT Tester should possess good knowledge of the business. He should be independent and think as
anunknown user to the system. Tester should be Analytical and Lateral thinker and combine all sort of
data to make the UAT successful.
Tester or Business Analyst or Subject Matter Experts who understand the business requirements or flows
can prepare test and data which are realistic to the business.
Best Practices:
Following points needs to be considered to make UAT Success:

Prepare UAT plan early in the project life cycle

Prepare Checklist before the UAT starts
Conduct Pre-UAT session during System Testing phase itself
Set the expectation and define the scope of UAT clearly
Test End to End business flow and avoid system tests
Test the system or application with real world scenarios and data
Think as an Unknown user to the system
Perform Usability Testing
Conduct Feedback session and meeting before moving to production

UAT Tools
There are several tools in the market used for User acceptance testing and some are listed for reference:
Fitnesse tool : It is java tool used as a testing engine. It is easy to create tests and record results in a table.
Users of the tool enter the formatted input and tests are created automatically. The tests are then
executed and output is returned back to the user.
Watir : It is tool kit used to automate browser based tests during User acceptance testing. Ruby is the
programming language used for inter process communication between ruby and Internet explorer.
Some Important points of UAT

Most of the times in a regular software developing scenarios, UAT is carried out in the QA
environment. If there is no staging or UAT environment
UAT is classified into Beta and Alpha testing but it is not so important when software is developed
for a service based industry
UAT makes more sense when the customer is involved to a greater extent
UAT is one of the many flavors of testing that has emerged over last twenty five years. With UAT, the client
can be sure "What to expect" from the product rather than assuming. The benefit of UAT is that there will
be no surprises when the product is released to the market.
The complete Business Analysis Process
For any Business Analyst the biggest challenge after getting a project is, how to start and from where to
start the project? Or what deliverables might be creating and how to complete the project successfully?
To help you with all sort of questions we have listed out some of the key techniques for a successful
business process analysis.
It will give guide you step by step from the day 1 business analysis process till the end of the planning
Step 1) - Gather all information about the project
It is business analyst's responsibility to gather all the details related to the project. By asking questions to
people connected with the project (project manager, project sponsor, manager or business owner).
The information gathered should cover these topics

Project scope and boundaries

Current factors influencing the organization
Project risk and constraints
Broader organizational context
Stakeholders that are actively involved in it. This would be a good time to conduct Stakeholder Needs
After gathering all this information, analyze your part in the project and make a checklist that as a
Business analyst you can include like

From your previous experience what you can implement in your current project

Documentation and planning required into the current project

Discussing the possible outcome of the project with stakeholders
Sort out the members that are involved in the project
Look for any help from client - fixing a meeting with the stakeholders
What are the expected deliverable and in what format it is required
What existing documentation you can review for better project idea
Find out what methodology (Agile or Waterfall) will be appropriate for your project
Step 2) Set up a review meeting with Project manager/ Stakeholder/ Team members
An unclear agenda may lead to a failure of the project.

Be specific in what is expected out of the project.

Involve Project manager/ Stakeholder/ Team members in meeting and ask questions related to

It is very likely that you might be working on completely new project, in that case, ask project
manager or contact person who has worked in that domain before
Step 3)Analyze all the project relevant documents like

Business process documentation

Business and system requirements documents
Business cases
Charts and flow diagrams
Project plans
Organization chart
Strategy documents and business plans
Policies and legislation
Uncover the information hidden in business requirement document and trace out any gaps with current
systems, processes, procedures and operations. It is possible that document that is provided to you is out
of date, so validate the information that you discover.
Step 4) Record all the facts and information that you discover
From your research and analysis, you may discover many useful information relevant to the project that
has to be changed or implemented in the project. Record them.

Business requirements including reporting requirements

Business processes and supporting systems
Functional and non-functional requirements
Issues and risks that are currently influencing the project
Step 5) Understanding the problem domain
By now you will have a good insight of the project, now you can identify the problem domain in the project.
You need to find out

Exactly which business function will be affected

Risks and factors affecting the business
Policies and constraints that influence the project
Values that determines the level of importance of the project
System currently supports the business activities
Document giving brief about the problem domain- e.g., Annual Report
Issues currently blocking the business to achieve the desired outcomes

On proposed change does it make any difference to problem domain

Step 6) Presenting your Business Requirement

Once you have gather all your business requirement and understand the problem domain. The next step
ispresenting your Business Requirement to Stakeholders or Project Manager. There are numerous
techniques which can be used for presenting requirement like

A table or spreadsheet
A diagram or graph
A prototype or simulation
A structured text template or structured sentence
Glossary of words that will give quick overview of business analyst process

Purpose: Defines the purpose of the business analysis activities required for the proposed initiative
Scope: Defines the deliverables that are included and excluded
Root Cause: Define the root causes of the issues identified
Current Condition: Defines the problem that cause the need for change
Planned Activities: Defines the reason for the activity, deliverables, and delivery dates
Stakeholder Engagement plan: It gives an overview of the stakeholder engagement process
Quality Management: It describes the activities that will ensure the quality of project deliverables
Target Condition: Defines how critical issues identified will be addressed
Quick tips for Business Analyst

Ask questions in meetings

Be prepared before stakeholder meeting or review
Be adaptable to change and new experience
Manage expectations
Respond to feedback

Learn ER Modeling with a Case Study

What is ER Modeling?
Entity Relationship Modeling (ER Modeling) is a graphical approach to database design. It uses
Entity/Relationship to represent real world objects.An Entity is a thing or object in real world that is
distinguishable from surrounding environment. For example each employee of an organization is a
separate entity. Following are some of major characteristics of entities.

An entity has a set of properties.

Entity properties can have values.

Let's consider our first example again. An employee of an organization is an entity. If "Peter" is a
programmer (an employee) at Microsoft, he can have attributes (properties) like name, age, weight,
height, etc. It is obvious that those do hold values relevant to him.

Each attribute can have Values. In most cases single attribute have one value. But it is possible for
attributes have multiple values also. For example Peter's age has a single value. But his "phone
numbers" property can have multiple values.
Entities can have relationships with each other. Let's consider a simplest example. Assume that each
Microsoft Programmer is given a Computer. It is clear that that Peter's Computer is also an entity. Peter is
using that computer and the same computer is used by Peter. In other words there is a mutual relationship
among Peter and his computer.
In Entity Relationship Modeling, we model entities, their attributes and relationships among entities.
Enhanced Entity Relationship (EER) Model
Enhanced Entity Relationship (EER) Model is a high level data model which provides extensions to
originalEntity Relationship (ER) model. EER Models supports more details design. EER Modeling emerged
as a solution for modeling highly complex databases.
EER uses UML notation. UML is the acronym for Unified Modeling Language; it is a general purpose
modeling language used when designing object oriented systems. Entities are represented as class
diagrams. Relationships are represented as associations between entities. The diagram shown below
illustrates an ER diagram using the UML notation.

ER Model with UML Notation

Why use ER Model?
Now you may think why use ER modeling when we can simply create the database and all of its objects
without ER modeling? One of the challenges faced when designing database is the fact
that designers, developers and end-users tend to view data and its usage differently. If this

situation is left unchecked, we can end up producing a database system that does not meet the
requirements of the users.
Communication tools understood by all stakeholders(technical as well non-technical users) are
critical in producing database systems that meet the requirements of the users. ER models are
examples of such tools.
ER diagrams also increase user productivity as they can be easily translated into relational tables.
Case Study: ER diagram for "MyFlix" Video Library
Let's now work with the MyFlix Video Library database system to help understand the concept of ER
diagrams. We will using this database for all hand-on in the remainder of this tutorials
MyFlix is a business entity that rents out movies to its members. MyFlix has been storing its records
manually. The management now wants to move to a DBMS
Let's look at the steps to develop EER diagram for this database1.

Identify the entities and determine the relationships that exist among them.


Each entity, attribute and relationship, should have appropriate names that can be easily
understood by the non-technical people as well.


Relationships should not be connected directly to eachother. Relationships should connect



Each attribute in a given entity should have a unique name.

Entities in the "MyFlix" library
The entities to be included in our ER diagram are;

Members - this entity will hold member information.

Movies - this entity will hold information regarding movies
Categories - this entity will hold information that places movies into different categories such as
"Drama", "Action", and "Epic" etc.
Movie Rentals - this entity will hold information that about movies rented out to members.
Payments - this entity will hold information about the payments made by members.
Defining the relationships among entities
Members and movies
The following holds true regarding the interactions between the two entities.

A member can rent a more than movie in a given period.

A movie can be rented by more than one member in a given period.
From the above scenario, we can see that the nature of the relationship is many-to-many. Relational
databases do not support many-to-many relationships. We need to introduce a junction entity.
This is the role that the MovieRentals entity plays. It has a one-to-many relationship with the members
table and another one-to-many relationship with movies table.

Movies and categories entities

The following holds true about movies and categories.

A movie can only belong to one category but a category can have more than one movie.
We can deduce from this that the nature of the relation between categories and movies table is one-tomany.
Members and payments entities
The following holds true about members and payments

A member can only have one account but can make a number of payments.
We can deduce from this that the nature of the relationship between members and payments entities is
Now lets create EER model using MySQL Workbench
In the MySQL workbench , Click - "Create New EER Model"

Double click on Add Diagram button to open the workspace for ER diagrams.

Following window appears

Let's look at the two objects that we will work with.

The table object allows us to create entities and define the attributes associated with the
particular entity.
The place relationship button allows us to define relationships between entities.
The members' entity will have the following attributes

Membership number
Full names
Date of birth
Physical address
Postal address
Let's now create the members table
1.Drag the table object from the tools panel

2.Drop it in the workspace area. An entity named table 1 appears

3.Double click on it. The properties window shown below appears

Next ,

Change table 1 to Members


Edit the default idtable1 to membership_number


Click on the next line to add the next field


Do the same for all the attributes identified in members' entity.

Your properties window should now look like this.

Repeat the above steps for all the identified entities.

Your diagram workspace should now look like the one shown below.

ER Model With all Entities

Lets create relationship between Members and Movie Rentals


Select the place relationship using existing columns too


Click on membership_number in the Members table


Click on membership_number in the MovieRentals table

Repeat above steps for other relationships. Your ER diagram should now look like this -


ER Diagrams play a very important role in the database designing process. They serve as a nontechnical communication tool for technical and non-technical people.
Entities represent real world things; they can be conceptual as a sales order or physical such as a
All entities must be given unique names.
ER models also allow the database designers to identify and define the relations that exist among
The entire ER Model is attached below. You can simple import it in MySQL Workbench