Business Analyst Knowledge Material

by Diwakar Singh
About the Material
Business Analysis is a subject which provides concepts and insights into the development of the initial
framework for any project. It holds the key to guide key stakeholders of a project to perform business
modeling in a systematic manner. This material provides a brief overview of the concepts of business
analysis in an easy to understand manner.

Intended Audience
This material is meant for aspiring Business Analysts, and Project Owners or Business Owners,
Coordinators and Project team members who often work closely with Stakeholders of a Client. In
addition, it will also be useful for anyone who is involved in capturing, writing, analyzing, or
understanding requirements for Information Technology solutions, including Subject Matter Experts
(SME), Business Process Managers, and Business Process Users.

Pre-requisite
To understand this material, it is advisable to have a foundation level knowledge of business scenarios,
process and domain knowledge pertaining to a few industries.

2
Table of Contents
About the Material........................................................................................................................................ 2
Intended Audience ........................................................................................................................................ 2
Pre-requisite.................................................................................................................................................. 2
1. Business Analysis - Introduction ........................................................................................................... 5
What is Business Analysis?........................................................................................................................ 5
Who is a Business Analyst? ....................................................................................................................... 5
Why Business Analysis is Important?........................................................................................................ 5
Organizations employ business analysis for the following reasons: ........................................................ 5
Common Myths in Business Analysis ........................................................................................................ 5
Importance of Soft Skills in Business Analysis ........................................................................................ 12
Domain Challenges faced by Business Analyst – What and How to tackle this?.................................... 14
2. Business Analysis- Core Concepts ....................................................................................................... 15
Business Analysis Life Cycle .................................................................................................................... 15
Business Analysis Core Concept Model .................................................................................................. 17
3. SDLC Overview and Methodologies .................................................................................................... 20
SDLC – Overview ..................................................................................................................................... 20
Stages/Phases in SDLC ............................................................................................................................ 21
SDLC Models ........................................................................................................................................... 22
Sequential- Waterfall Model ............................................................................................................... 22
Iterative- RUP Model........................................................................................................................... 24
Agile- Scrum Model ............................................................................................................................. 25
4. Project Scope Definition and Modeling (BPMN, UML) ....................................................................... 30
Define Scope of Project – Inputs ......................................................................................................... 30
Define Scope of Project – Tools and Techniques ................................................................................ 32
Define Scope of Project – Outputs ...................................................................................................... 33
1. Business Process Modeling Notation (BPMN) .................................................................................... 34
2. Unified Modeling Language (UML) diagrams ................................................................................. 36
3. Flow chart technique ...................................................................................................................... 36
4. Data flow diagrams ......................................................................................................................... 37
5. Role activity diagrams ..................................................................................................................... 38
6. Role interaction diagrams ............................................................................................................... 38

3
 7. Gantt charts .................................................................................................................................... 40
8. Integrated definition for function modeling ................................................................................... 40
9. Colored Petri nets ........................................................................................................................... 41
10. Object oriented methods .............................................................................................................. 41
5. Requirements Engineering ...................................................................................................................... 42
Business Requirements Initiation (Gathering Stage) .............................................................................. 42
Stakeholder Identification, Analysis and Mapping ................................................................................. 42
Classification of Requirements ............................................................................................................... 46
Apply Requirement Elicitation Techniques ............................................................................................. 47
Sort the Requirements ............................................................................................................................ 56
Prioritize the Requirements .................................................................................................................... 57
Requirements Verification and Validation .............................................................................................. 58
Requirements Documentation ............................................................................................................... 60
Business Requirement Document....................................................................................................... 60
Functional Requirement Document.................................................................................................... 61
BRD Vs SRS Vs FRD .............................................................................................................................. 68
Use-Case.............................................................................................................................................. 68
Requirement Traceability Matrix ........................................................................................................ 71
6. Contribution of BA in Projects ................................................................................................................ 72
Change Management Process ................................................................................................................ 72
Gap Analysis: As-IS and To-Be mapping .................................................................................................. 73
Business Strategic Planning Technique – SWOT, SOAR, PESTLE, MOST ................................................. 75
Root Cause Analysis ................................................................................................................................ 78
7. BA Tools................................................................................................................................................... 80
Prototyping - Draw.io .............................................................................................................................. 80
Agile Project management - JIRA ............................................................................................................ 81
Repository - Confluence.......................................................................................................................... 82
Database - MS SQL .................................................................................................................................. 84

4
 1. Business Analysis - Introduction

What is Business Analysis?

Business Analysis is the set of tasks, knowledge, and techniques required to identify business needs and
determine solutions to enterprise business problems. Although, the general definition is similar, the
practices and procedures may vary in various industries. In Information technology industry, solutions
often include a systems development component, but may also consist of process improvement or
organizational change.

Business analysis may also be performed to understand the current state of an organization or to serve
as a basis for the identification of business needs. In most cases, however, business analysis is
performed to define and validate solution that meets business needs, goals, or objectives.

Who is a Business Analyst?

A business analyst is someone who analyzes an organization or business domain (real or hypothetical)
and documents its business, processes, or systems, assessing the business model or its integration with
technology. However, organizational titles vary such as analyst, business analyst, business systems
analyst or maybe systems analyst.

Why Business Analysis is Important?

Organizations employ business analysis for the following reasons:
• To understand the structure and the dynamics of the organization in which a system is to be
deployed.
• To understand current problems in the target organization and identify improvement potentials.
• To ensure that the customer, end user, and developers have a common understanding of the
target organization.

In the initial phase of a project, when the requirements are being interpreted by the solution and design
teams, the role of a Business analyst is to review the solutions documents, work closely with the
solutions designers (IT team) and Project managers to ensure that requirements are clear.

In a typical large-size IT organization, especially in a development environment, you can find On-site as
well as offshore delivery teams having the above-mentioned roles. You can find a “Business Analyst”
who acts as a key person who has to link both the teams.

Common Myths in Business Analysis

Myth 1: Business analyst must be able to create and implement solutions.

Myth 2: Business Analyst and Project Manager are one and the same

Myth 3: BAs are not required in the latter phases of the project

Myth 4: All BAs must be strong domain experts

5
Myth 5: BAs are product specialists; they don't need to have people skills

Myth 6: We don't need a Business Analyst for this type of project or product

Myth 7: BAs are only good at writing requirements documents

Myth 1: Business analyst must be able to create and implement solutions.

This is undoubtedly one of the most misconstrued perceptions about the business analyst’s role and
responsibilities. You can get to see this in almost every job description and mention of the business
analyst’s roles. Not just among the recruiting managers, but also with senior management and
technology managers, there is this widespread belief. Besides creating the design, BAs are also expected
to implement technology-driven solutions too.

Fact 1: Business Analyst focuses on the problem space and could at best, facilitate or
recommend the solution(s)
Almost everything worth analyzing in this world can be looked at from the perspective of Problem-
Solution pair. The problem space comprises all the activities related to the problems. Business
Analysts must focus on this domain. BAs identify the problems, prioritize, specify and communicate to
the relevant stakeholders.

The Solution space consists of conceptualizing, brain-storming and generating ideas for the pro-
posed solution(s). It takes a different set of skills, aptitude and attitude from the team members
to create and execute the solutions. BA does not necessarily need to create solutions. However
they must be able to lactate and help support the team in the implementation of solution.

6
Myth 2: Business Analyst and Project Manager are one and the some
In every technology-driven project, there is certainly one role for sure and that is the Project Man-
ager. Often times, project managers also double up as business analyst, which is not a
problem, so long as the two are clearly demarcated as different roles. However, problems start to
emerge when the roles and responsibilities of a BA are equated to those of a project manager
or vice versa.

7
Fact 2: Project Manager is the master of the project, whereas Business Analystowns the
product roadmap
Project Manager is most-certainly the owner of the project, being the key decision-maker
aboutresources, timelines, removing constraints and hurdles to ensure smooth execution of the
project. Business Analyst, on the other hand, is responsible for the product in terms of defining
the features, functionality and manages the product roadmap. It can be looked at as the PM being
the owner and captain of the project, while BA could be considered as equivalent to the
Product Owner.

Myth 3: Business Analysts are not required in the later phases of the project
This is another popular misconception that you come across during the project kick-off and
review meetings and resource planning sessions. Business analysts traditionally were confined
tothe initial stages of the project execution. They were actively allocated for the initial set of
activities in the pre-project and initiation phases. The requirements phase, among all the phases of
the project or the product’s life cycle, remained to be the forte of BAs.

8
Fact 3: Business Analysts ore very much port of the entire life cycle of the project,albeit
the proportion of their involvement may vary across the phases
BAs' contribution to the project starts much earlier than that of other team members. They are engaged
early on so as to outline the vision, scope and roadmap for the product, process or business. Moreover
analysts are required even in the pre-project (also called as pre-sales) phase. They are involved at this
stage to help in the creation of proposals and tenders.

The contribution of business analyst goes well beyond the initial requirements phase. They sup- port the
team members during the design, development and implementation. Analysts create wireframes,
mockups and sketches to help present their ideas of the proposed solution. This goes well with the
current agile methodologies e.g., SCRUM, User Stories and Test Driven Development (TDDj. Thanks to
these practices, today, analysts are involved and engaged all through the life cycle of the
project/product development.

Myth 4: All Business analysts must be strong domain experts

From banking to manufacturing and from retail to healthcare business analysts are deemed to be
experts in their specific domains and verticals. It is true that initially, analysts used to be
professionals who came with strong background of rich working experience in one or more
domains. BAs are often referred to as SMEs (Subject Matter Experts), functional consultants and
domain specialists, as they have experience and expertise in the specific functional, vertical area or
industry domain.

9
Fact 4: Business Analysts need not always be domain specialists, especially theIT Business
Analysts
With the onset of business system analysts, the core skill of analysts shifted from a mere business
domain expertise to the systems perspective. BAs emerged as professionals who have at their core,
strong analysis skills and not just domain expertise. Though it could be argued that
domain/functional knowledge helps augment the analysis skills, it is not a mandatory requirement.
Sometimes analysts do need to have the general and broad-based skills to address situations that
require “inch deep, mile wide" approach.

Myth 5: BAs are product specialists, they don't need to hove people skills
Nothing could be further from truth than this misplaced notion about the business analyst’s
expertise. This stems from the objections raised by people that analysts cannot be leaders or that
they cannot run businesses. While in fact, people skills are so much needed for the BAs that it is
almost like their second nature and perhaps the most important part of their work-flow.

Fact 5: A core skill of a Business analyst is to engage, interact, communicate, lead and
work with people at different levels
People-interaction and working alongside people could be said to be part of an analyst's DNA.
While working in teams, it is very much imperative that the analysts interact, engage and
communicate with the team members continuously. Within the team, the interaction level ranges
from a deep partnership to a consulting role with various roles such as architects, designers,
developers, testers and managers. Not just within the team but on a broader level too, analysts
have to interact with several other stakeholders. These include people who may have a direct
impact as well as those who have an indirect relationship with the project, product, process or
business in question. The level of engagement varies from merely updating through to sharing
reports and from moderating interviews to conducting workshops.

10
Myth 6: We don’t need a Business Analyst for this type of project or product
This is one of the off-quoted objections you come across when it comes to allocating resources to a
team. Whether it is in the outsourced project execution, an in-house project or development ofa
product, Business Analysts are often seen as mostly support role and are considered an over- head.
However, they are as valuable to the project asa developer, designer, architect, tester, manager or other
team member.

Fact 6: Analysts ore critical for the successful execution of any type of projects or products
Whether the project is a green-field, new product development or enhancing the existing product,
analysts play a key role in defining the roadmap. BAs contribute toa great extent in product
maintenance, re-engineering projects because most the changes are to do with customer/user-facing
features. Same is the case with process improvement and change man- agement initiatives, where BAs
study and understand the as-is and propose the improvements for to-be proposition.

Myth 7: BAs ore only good at writing requirements documents

Initially, when the role of business analysts was conceived and conceptualized, the focus was primarily
on the requirements elicitation, specification and communication. However, with the implementation of
agile approaches, analysts have emerged as product specialists. The focus of BAs shifted from a
problem space into transitioning into solution domain.

11
Fact 7: Analysts ploy a key role in the strategic vision, product development, customer
engagement and user experience areas
BAs have strategic, pan-enterprise level perspective, as well as a product or process specific role. Also,
analysts offer significant help in engaging with customers, key stakeholders and users, involving
conducting interviews, studies, workshops. In the course of these investigations, analysts identify the
needs, problems and opportunities and propose recommended solutions. So BAs now draw and design
wireframes and mockups of the proposed solution, create models and prototypes.

Importance of Soft Skills in Business Analysis

12
Here is a good list of skills you need to acquire/hone over the years to be a better Business Analyst
professional:

1. Communication Skill – As a BA, we need to be effective communicators establishing a bridge

between the various stakeholders

2. Negotiation Skill – Balancing between those demanding requirements of the

customer/stakeholder and the internal organization would need a good amount of negotiation
skills. Creating a fine balance while looking at the requirements from a holistic point of view will
for sure make us a perfect BA.

3. Facilitation Skill – As a bridge between stakeholders, we need to have excellent facilitation skills
to ensure that communication is proper and all the requirements are articulated well and
explicitly.

4. Analytical thinking Skill – Get analytical and problem-solving skills brushed to analyze all the
scenarios well, come up with solutions, and ensure that there are no conflicts in the team and all
the members communicate well with each other.

5. Problem-solving Skill - A definite skill for all BA, as explained in the point above.

6. Decision-Making Skill – You have come up with multiple options for a particular problem using
your analytical skills; now, you need to weigh the options well and come up with a decision to
present to the steering committee; this is why you need this skill.

7. Ability to see the bigger picture – This is a very important skill for all BAs; focusing on the given
set of requirements and not seeing the bigger picture lot of times leads to a situation where the
product does not see the light of the day or gets abandoned. Hence this is one of the very
important skills to have; you need to have good business knowledge and knowledge of
technology/business advancements to see a bigger picture and keep it in mind while the
designing of the system is being carried out.

8. Ability to appreciate and empathize – See the points coming from all stakeholders and the basis
of all requirements and make a good judgment of the same keeping all in mind.

9. Ability to influence without authority – As BA’s there are numerous meetings we need to
spearhead/facilitate, this is where we need to be good to influence senior stakeholders and
decision-makers/sponsors of the project.

10. Good interpersonal skills – Above all skills, we need to have good interpersonal skills and a good
rapport with the team and all stakeholders to make the project successful.

Above all these skills will make you a better professional each day, these skills are something we learn
with each day and polish with each day in our professional lives.

13
Domain Challenges faced by Business Analyst – What and How to tackle this?
Q. Can a Business Analyst change a domain?

A. Yes, definitely a business analyst can change domains.

Q. What are the challenges faced while planning to switch domains?

A. Well, there will be lot of challenges that you have to face. We have to understand that the role
demands analysis of business hence it becomes important to understand the business context (domain).
There are two ways to look at it:

1) If you are changing the domain within the same organization, the process becomes little easy
as you get that support and time for learning domain.

2) If you are changing the organization, the process becomes most difficult as most of the
organization demands prior experience in that particular domain. Now, this is the biggest
challenge that you will face.

Q. How can we change domain and job together?

A. Firstly, Luck! Yes you heard it right, the first thing that you need to have is luck. You have to be that
lucky enough where you are getting an opportunity to change your job and at the same time change
your domain.

Secondly, if you are not that lucky enough, then you will have to be confident enough and assure the
hiring manager that you can pick up any domain by giving the past example." Every experience person is
once a beginner". Read something about that domain, take inputs from someone who has worked in
that domain and convince the recruiter that you are a quick learner and can pick up domain knowledge
quickly.

Q. How to learn domain once got an opportunity?

A. Well, if you want to learn domain, you can follow below steps:

1. Domain learning is a vast thing and it cannot be done in a day, week or month. So, do some
smart work and identify which part of domain understanding is needed to drive that particular
project.

2. Ask more and more questions. ‘Business analyst should have the skill of asking questions’. You
will have an advantage since you are new to the project you can ask lot of questions to
understand that domain.

3. Do some self research and learn the new topics/terminologies that you come across. Try to
search the topics on internet and understand it.

14
 4. Lastly speak to your team members, friends or experts and understand concepts if you are
not able to do it by self research.

To summarize, yes domain changing is difficult but not impossible. Keep learning and stay motivated.

2. Business Analysis- Core Concepts

Business Analysis Life Cycle

A business analyst acts as a liaison between the client and the technical team. The client and the
technical team have different focus areas and hence might have conflicts which interacting directly to
each other. To minimize the occurrence of such cases, a business analyst comes into picture. He fills the
gap between the client and the technical team.

The business Analysis Life Cycle includes comprises of the following processes:-

1. Understanding the business

The business analyst is not just responsible for gathering the requirements but also understanding them
only then he can provide an appropriate solution. In order to understand the requirements, the BA has
to first understand the underlying business and the existing processes of the client. A BA has to analyze
the market very accurately for that business which means proper identification of the customers for
those products or services.

2. Identify the business needs

Also known as the business case, this process mainly focuses on penning down the goals and objectives
of the projects. This information can be gathered by interacting with the customers and end users who
have been previously associated with this business. Their needs and requirements are clearly
understood which helps in focusing on the goals and objectives of the projects.

3. Define the project scope

Before moving on, the BA is responsible for defining the scope of the project. This involves
determination of the goals of the project, what all features are to be delivered, the deliverables, what all
tasks and people needed, the deadlines for each of the tasks, and finally the cost estimation has to be
done. All these scenarios have to be analyzed as part of defining the project.

4. Elicit the requirements

This may be termed as the major role of a BA. A BA is needed to elicit the requirements accurately in
order to provide an optimum feasible solution. There are various elicitation techniques which are used
to obtain the 3C advantage. 3C stands for correct, complete and consistent gathering of requirements.
The various elicitation techniques are as follows :-

15
 • Brainstorming
• Focus groups
• Document Analysis
• Reverse Engineering
• Observation
• Workshop
• JAD (Joint Application Development)
• Interview
• Prototyping
• Questionnaire (Survey)

5. Analyze the requirements

Once these requirements have been clearly gathered from the clients, they are further organized and
verified. During this research, many more facts come up front. Once all the internal facts, whether
relevant or irrelevant related to a particular requirement come into light, we move on in observing the
remaining requirements. This process of digging up each and every requirement in depth is known as
analyzing the requirements.

6. Document and present requirements

BA’s job doesn’t end with just gathering and analyzing the requirements. Once that part is over, next
comes documenting these requirements and getting them approved. After carefully analyzing each and
every requirement, BA documents these requirements using various standards such as, CMMI, IEEE or
templates provided by the organization. Once the documents are ready, they are sent to the senior BAs
or the SMEs for verification. After proper screening of these documents, the leads approve these
documents.

7. Communication of the requirements

Once the requirements have been understood, analyzed, documented and been approved, they have to
be communicated to the clients for the final verification. The client has to understand and give his
approval that the requirements gathered are correctly understood and documented. Once this is done,
only the BA can move ahead with the further processes.

In order to communicate with the stakeholders different approaches are used such as:

• Communication Plan
• Communication Model
• Effective communication
• Efficient communication
• Communication Method
• Communication types

16
8. Process Modeling

Just documentation is not sufficient for the technical team to be clear on every requirement. So the BA
has to communicate these requirements to the Project Manager by modeling these requirements. The
BA can create few UML (Unified Modeling Language) Diagrams, create few prototypes or come up with
a number of wireframes depicting each of these requirements. It is very easy for the technical lads to
see these models and can get a good knowledge of the requirements along with the proposed solution.

9. Verification of the solutions meeting the requirements

Once the models have been communicated to the technical team, they continue with their various
phases of designing, developing and testing. The BA, during these phases, doesn’t sit idle. In fact, he
contributes in each of these phases as well. For example, he verifies that all the requirements have been
considered during the design phase. During the development phase, if any change requests come up,
the BA has to handle those and communicate it to the technical team after proper analysis. During the
testing phase, the BA has to go for a complete testing of the application and once when he is sure that
the application meets all the requirements, he facilitates the User Acceptance Testing (UAT) for the
client.

Business Analysis Core Concept Model

17
Let’s review the six core concepts in detail:

1) Change: Change is an act of transformation within an organization in response to a need. The

need can be internal or necessitated by an external event such as a disruption in the market.
The aim of the change is to improve the performance of an enterprise through deliberate
actions controlled through business analysis activities.

2) Need: Need is a problem or opportunity to be addressed by the business analyst. Needs can
cause changes by motivating stakeholders to act. Changes can also cause needs by eroding or
enhancing the value delivered by existing solutions or creating the need for new solutions.

3) Solution: A specific way of satisfying one or more needs in a context. A solution satisfies a
need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage
of an opportunity.

4) Stakeholder: A group or individual with a relationship to the change, the need, or the
solution. Stakeholders are grouped based on their relationship to the needs, changes, and
solutions.

5) Value: The worth, importance, or usefulness of something to a stakeholder within a context.

18
Value can be tangible or intangible. Examples of tangible values are potential or realized returns,
gains, and improvements. Intangible value often has a significant motivational component, such
as a company's reputation or employee morale.

6) Context: The circumstances that influence, are influenced by, and provide understanding of
the change. A change always occurs within an environment. A context is a wide-ranging term
that can include everything from an organization’s culture, mission, and demographics to
government policies, competitors, products and sales. In order to successfully implement the
change, the business analyst must carefully define and analyze the context within which the
change is being implemented.

Let’s consider an example to illustrate in more detail. The wave of digitization is transforming
many traditional industries. A traditional retail business that operated brick and mortar stores
for years must now compete with e-commerce companies that provide the same goods to
customers but with additional benefits such as convenience (shop from home), wide range of
products and attractive discounts (due to the lower cost business models of e-commerce
players). In order to respond to this change in market dynamics, a business analysis task can be
performed at a traditional brick and mortar retail store. Here is how the six core concepts may
be analyzed in this example:

1) Change: Provide e-commerce solutions to customers who prefer shopping online. This will
require completely new business processes and functions to fulfill online orders.

2) Need: Rising popularity and market share of e-commerce competitors who directly compete
in the marketplace with the company, to attract a growing share of customers, transactions and
volume of goods sold.

3) Solution: Depending upon the company’s organizational structure, capabilities and time-
sensitive nature of the change, the probable (but not exhaustive) list of solutions could be to
implement an IT project that enables the organization to set up its own e-commerce store,
partner with existing e-commerce players to use their infrastructure for order fulfillment or
acquire an existing e-commerce player and merge it with the company’s existing operations.

4) Stakeholder: The stakeholders, in this case, are almost from all functional areas – sales,
marketing, IT, HR and Operations – within the organization.

5) Value: The tangible value, in this case, can be increase in sales and increase (or maintaining)
the company’s market share. The intangible value can include transforming the organization to a
digital future, introduction of new talent and ideas.

6) Context: The context for this proposed change can be the growing market share and
popularity of e-commerce players, changing demographic profile of the customers,

19
 improvements in the digital infrastructure in the country, entry of foreign players in the market
and easier government regulations towards setting up of e-commerce companies.

3. SDLC Overview and Methodologies

SDLC – Overview
Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop
and test high quality software. The SDLC aims to produce high-quality software that meets or exceeds
customer expectations, reaches completion within times and cost estimates.

• SDLC is the acronym of Software Development Life Cycle.

• It is also called as Software Development Process.
• SDLC is a framework defining tasks performed at each step in the software development
process.

The following figure is a graphical representation of the various stages of a typical SDLC.

20
Stages/Phases in SDLC
Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the
senior members of the team with inputs from the customer, the sales department, market surveys and
domain experts in the industry. This information is then used to plan the basic project approach and to
conduct product feasibility study in the economical, operational and technical areas.

Planning for the quality assurance requirements and identification of the risks associated with the
project is also done in the planning stage. The outcome of the technical feasibility study is to define the
various technical approaches that can be followed to implement the project successfully with minimum
risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product
requirements and get them approved from the customer or the market analysts. This is done through
an SRS (Software Requirement Specification) document which consists of all the product requirements
to be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the product to be
developed. Based on the requirements specified in SRS, usually more than one design approach for the
product architecture is proposed and documented in a DDS - Design Document Specification.

This DDS is reviewed by all the important stakeholders and based on various parameters as risk
assessment, product robustness, design modularity, budget and time constraints, the best design
approach is selected for the product.

A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if any). The
internal design of all the modules of the proposed architecture should be clearly defined with the
minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code is
generated as per DDS during this stage. If the design is performed in a detailed and organized manner,
code generation can be accomplished without much hassle.

Developers must follow the coding guidelines defined by their organization and programming tools like
compilers, interpreters, debuggers, etc. are used to generate the code. Different high level programming
languages such as C, C++, Pascal, Java and PHP are used for coding. The programming language is chosen
with respect to the type of software being developed.

21
Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are
mostly involved in all the stages of SDLC. However, this stage refers to the testing only stage of the
product where product defects are reported, tracked, fixed and retested, until the product reaches the
quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market.
Sometimes product deployment happens in stages as per the business strategy of that organization. The
product may first be released in a limited segment and tested in the real business environment (UAT-
User acceptance testing).

Then based on the feedback, the product may be released as it is or with suggested enhancements in
the targeting market segment. After the product is released in the market, its maintenance is done for
the existing customer base.

SDLC Models
There are various software development life cycle models defined and designed which are followed
during the software development process. These models are also referred as Software Development
Process Models". Each process model follows a Series of steps unique to its type to ensure success in the
process of software development.

Following are the most important and popular SDLC models followed in the industry −

• Sequential- Waterfall Model

• Iterative- RUP Model

• Agile- Scrum Model

Sequential- Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-sequential life
cycle model. It is very simple to understand and use. In a waterfall model, each phase must be
completed in its entirety before the next phase can begin. At the end of each phase, a review takes
place to determine if the project is on the right path and whether or not to continue or discard
the project.

22
Stages of Waterfall Model Resources Artifacts

Requirements gathering BA,PM BRD

Requirements Analysis BA,PM FS/ FRS, SSD, SRS RTM

Tech Team - Sol Arch, NW

Arch, DB Arch

Design Tech Team - Sol Arch, NW HDD/ADD

Arch, Solution Document

DB Arch, GUI Designer

Development - coding Programmers LDD /CDD

Developers Application

Testing Testers Test Documents

Application with less Errors

Unit, Component, System, System Integration, UAT

PROCESS - Configuration Management - PM

Deployment & Release Engineers

Implementation

23
Iterative- RUP Model
The Rational Unified Process (RUP) is an iterative software development process framework created by
the Rational Software Corporation, which was acquired by IBM in February 2003.

RUP is based on a set of building blocks, or content elements, describing what is to be produced; the
necessary skills require d and the step-by-step explanation describing how specific development goals
are to be achieved. The main building blocks, or content elements, are the following:

Roles {who) - A Role defines a set of related skills, competencies and responsibilities.

Work Products {what) - A Work Product represents something resulting from a task, including all the
documents and models produced while working through the process. Tasks (how a Task describes a unit
of work assigned to a Role that provides a meaningful result. Within each iteration, the tasks are
categorized into nine disciplines:

Six "engineering disciplines" Business Modeling Requirements

Analysis and Design Implementation Test Deployment

Three supporting discipline s Configuration and Change Management Project Management

Environment

24
Four Project Life Cycle Phases
Inception: agreement among the team and customer as to what will be built

Elaboration: agreement within the team as to the architecture and design needed to deliver the agreed
system behavior

Construction: the iterative implementation of a fully functional system

Transition: delivery, defect correction, and tuning to ensure customer acceptance

Six best practices

• Develop iteratively, with risk as the primary iteration driver
• Manage requirements
• Employ a component-based architecture
• Model software visually
• Continuously verify quality
• Control changes

Agile- Scrum Model

Agile is Light weight can be implemented where faster delivery is required.

• No documentation required.
• Customer retention - since there is no documentation. The code in itself forms as
documentation
• Not support scalability and extendibility
• SDLC life cycle cut down by employing seasoned DEVELOPERS

25
Four main Values

• Individuals and interactions over processes and tools;

• Working software over comprehensive documentation;
• Customer collaboration over contract negotiation;
• Responding to change over following a plan

Twelve Principles of Agile Software

1. Satisfy the customer through early and continuous delivery of valuable soft ware.

2. Welcome changing requirement s, even late in development Agile processes harness change for
the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need
and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity-the art of maximizing the amount of work not done-is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.

Scrum Framework
SCRUM can be implemented either at the beginning of the project or when you sense that project is
falling behind schedule. This model exercises full Admin Power.

26
Scrum Team: Project resources are grouped as Scrum teams which comprises of BAs, Developers, and
Testers. Each Team size will on average be 7-8.

Product Owner: He will decide what needs to be in the product and will be responsible for how the
product has to be. He will regularly interact with customers and BAs. This role may be played by BA or
any person who worked for end users for a long time or customer himself.

Scrum Master: He will monitor the performance of the team within the sprint. Team will raise all their
issues to scrum master and he will run to look for answers. This role can be played by any person in
team normally BA's plays this role.

Product burn-down: It shows how much work was left to do at the beginning of each sprint.

Sprint: This is the period that team decides to deliver their objective. Normally a sprint period will be for
2 weeks but may extend to 4 weeks.

Sprint Events/Meetings:
Sprint Planning Meeting -This happens at the beginning of each sprint and team decides on what they
will be delivering in the sprint.

Sprint Grooming Meeting- This happens at the beginning of each sprint to demonstrate Sprint ready
User stories to the development team based on the priority defined.

Daily Scrum Meeting - This happens each day where team will just answer 3 questions:

1) What did you do today?

2) What will you do tomorrow?

3) Are there any impediments that is slowing or stopping you?

Sprint Review Meeting - This happens at the end of the sprint where team will demo the completed
stories to product owner and get it cleared.

Sprint Retrospective Meeting - This happens at the end of the sprint where team will answer these 3
questions:

1) What went well in the sprint?

2) What did not go well?

3) What are the required areas of improvements in next sprint?

Product Backlog: all Stories- all requirements

27
Burn down chart: A burn down chart is a graphical view of the remaining work left versus the time in an
iteration. A project backlog or hours can be expressed on the vertical axis, while time is indicated on the
horizontal axis. A burn down chart is often used to determine when work will be completed on a project
or iteration.

Epic: An epic is a set of related user stories. They are also considered a "really big user story."

Iteration: Iteration is an iterative development concept that establishes a short time frame to deliver a
set of soft ware features or user stories. Iteration includes typical waterfall activities such as analysis,
design, development, and testing, yet they are time boxed within a one to four-week window. At the
end of iteration, the progress is reviewed with the business customer, and recommended changes can
be incorporated into future iterations.

Planning Poker: Planning Poker is an estimation game used to estimate individual user stories as a team
activity. The team gathers and reviews user stories one at a time. As stories are presented, the team
discusses the user story and provides an estimate of the work from their own deck of cards. All
estimates are presented and discussed until the team arrives at a consensus.

Release: A release is a set of working software delivered to the business customer resulting from a set of
iterations. During release planning, teams will review a product backlog to organize user stories into the
specific releases and iterations that delivers functional product to the business customer.

Scrum: Scrum is an iterative development methodology used to manage software projects. In scrum-
based projects, there isn't a specific project manager directing project team tasks; the team is self-
directed, with co- located team members relying on communication over documentation for effective
project delivery.

Sprint: A sprint is a scrum-based agile methodology concept that is similar to iteration. A sprint is time
boxed to deliver a specific set of user stories and produce working features within a set time period.
During sprint planning, the business customer or product owner specifies the user story priority, and the
development team commits to the scope for a given sprint. During a sprint, user stories can be removed
from the sprint scope, but new stories cannot be added; this allows project teams to focus on the goals
of the sprint and deliver rapidly.

Story points: A story point is a relative estimation method used to determine the size of user stories so
teams can determine how much work can be done during iteration. Story points can be expressed in a
simple sequence, t- shirt sizes, or a relative number. By adding up the number of user stories and
associated story points, the project team can establish its velocity for future iteration planning.

28
BA's Role in Agile Scrum
To Start with, once a project is kicked off, BA does the requirement planning, then conducts various
requirements gathering sessions and analyses the requirement.

Finally, the requirement is listed as 'FEATURE LIST'. This Feature list is drafted by BA and discussed with
Product Owner. This feature list will have all enhancements and existing features (If it is a migration
project).

From the Feature List, BA identifies the Epic and breaks them as Themes and then to User Stories.

User Stories will have below Information:

Acceptance Criteria: - This area will have mandatory information that are needed in this story"

Then BA briefs the story to development team and regularly supports the team for development.

BA also does the Integration Testing and System Testing to ensure the system performs as desired

Waterfall Vs Agile

29
 4. Project Scope Definition and Modeling (BPMN, UML)

Define Scope is the process of developing a detailed description of the project and product. The key
benefit of this process is that it describes the product, service, or result boundaries by defining which of
the requirements collected will be included in and excluded from the project scope. The inputs, tools
and techniques, and outputs of this process are depicted below in the data flow diagram of the process.

Define Scope of Project – Inputs

The following are included in the defined scope process as the inputs:

1. Project Charter
2. The Project Management Plan
3. Project Documents

30
 4. Enterprise Environmental Factors
5. Organizational Process Assets

1. Project Charter

The project charter is a document that provides the high-level project description and product
characteristics. It also enlists all the project approval requirements. If a project charter is not being used
to its fullest in any organization, then comparable information needs to be developed and used as a
basis for the detailed project scope statement. In situations where the organizations do not produce a
formal project charter for setting out common goals, rules and regulations they will usually perform an
informal analysis to identify the content necessary for further scope planning.

2. The Project Management Plan

Both Project Management and scope management plans have the same characteristics but whereas
the Project Management plan documents how the project scope will be defined, validated, and
controlled.

3. Project Documents

Examples of project documents that can be listed as inputs for defining scope are as follows;

a. Assumption Log

The role of the assumption log is to identify the assumptions and constraints about the project, product,
stakeholders, environment, and other factors that can influence the project and the product scope.

b. Requirements Documentation

The process of identifying the list of requirements those are to be incorporated into the project scope.

c. Risk Register

The risk register mainly contains response strategies that may affect the project scope by reducing the
project and the product scope to avoid or mitigate a risk that is to occur in the project.

4. Enterprise Environmental Factors

The factors which can influence the Define Scope process include:

a. Organization’s Culture

b. Infrastructure

c. Personnel Administration

d. Marketplace Conditions

31
5. Organizational Process Assets

The factors that influence the Define Scope process include:

a. Policies, procedures, and templates for a project scope statement

b. Project files from previous projects
c. Lessons learned from previous phases and projects

Define Scope of Project – Tools and Techniques

The following are included in the tools and techniques for defining the scope of a project:

a. Expert Judgment
b. Data Analysis
c. Decision Making
d. Interpersonal & Team Skills
e. Product Analysis

a. Expert Judgment

With regards to the technique of expert judgment, one has always to consult a group or an individual
who has exceptional knowledge in dealing with similar projects.

b. Data Analysis

The best example of a data analysis technique that can be used in this process is alternatives analysis.
This alternatives analysis helps in evaluating ways to meet the requirements and objectives that are
identified in the project charter.

c. Decision Making

Multi-criteria decision analysis is the best example of this particular process. Under this technique, a
decision matrix is used to provide a systematic analytical approach for establishing necessities like
requirements, schedules, budget, and resources to clarify the project and product scope further.

d. Interpersonal and Team Skills

An example of interpersonal and team skills is the facilitation process. This process is mainly used in
workshops and sessions happening with key stakeholders who are always high on expectations. The
ultimate goal of this process is to reach a cross-functional and shared understanding of the project
deliverables.

e. Product Analysis

Product analysis is used to define the products and services related to a particular project. The process
includes asking questions about a product or service and generating answers to describe the use,
characteristics, and other relevant aspects of what is going to be delivered.

32
Define Scope of Project – Outputs
The following are included as the outputs of the defined scope process:

a. Project Scope Statement

A project scope statement is a detailed description of the project scope, which includes significant
deliverables, assumptions, and constraints. It also documents the project scope and the product scope
and describes the project’s deliverables and the work required to deliver them. Based on the level and
degree of detail the project scope statement defines the work that will be performed, and the work that
is minimized can help determine how well the Project Management team can control the overall project
scope.

b. Project Documents Updates

1. Assumption Log: The role of the assumption log at this stage is to update the log with additional
assumptions or constraints which were identified during the project process.
2. Stakeholder Register: The documentation consists of all of the stakeholder’s requirements that
are to be met and also registers the important deliverables that are in the pipeline of the project
manager.

33
 3. Requirements Documentation: A method that is used to record the requirements of a particular
project. This documentation will keep all the deliverables that are met and the other
deliverables that are to be accomplished by the project manager.
4. Requirements Traceability Matrix: A method that is used to compare the project’s scope,
requirements, and deliverables are all the same when they are compared with the project’s
baseline that was created during the Project Management plan.

The defined scope process takes the high-level product descriptions, assumptions, and constraints,
which were documented in the developed project charter process during the initiating process group,
and develops from them a more detailed description of the scope in the project scope statement. The
project scope may not be entirely defined during the initial stage of determining the scope.

1. Business Process Modeling Notation (BPMN)

Business process modeling notation (BPMN) is comprised of symbols that are used as a representation
of tasks and workflows. Any symbols can be used in your business process, but using standardized ones
allows you to collaborate with outside analysts more easily, and it spares you from having to invent your
own visual language.

BPMN symbols fall into the following categories:

• Flow objects. Shows the flow of the process and are represented as follows:

o Circles. Events are displayed inside of circular shapes

o Rectangles. Activities fit into rectangular boxes

o Diamonds. Control points or gateways are represented as diamond shapes

• Connecting objects. Used to show how tasks are connected, and in what sequence they occur

o Solid lines. Shows task transfers

o Dashed lines. Shows messages

• Swim lanes. These make provision for sub processes that share responsibilities and how they
interact. The swim lanes are the people or departments that the sub process impacts on

34
• Artifacts. Used if you have additional information that isn’t a sequence flow or message flow,
but that will further explain the process

o Dotted lines. These point to the flow object that the extra information expands on

o Squares outlined with dots and dashes. These group related elements in the diagram

o Square bracket. Text annotations are added here

35
2. Unified Modeling Language (UML) diagrams
Unified modeling language (UML) is a more modern approach to modeling and documenting processes.
UML was initially developed by software developers, but has been successfully used in business process
modeling, with a more object-oriented approach to its 14 UML diagram types.

3. Flow chart technique

This is a graphic representation of something that is manufactured or produced, which gives people
involved in the project or process a single reference point. Flow charts use basic shapes and arrows to
define relationships, such as processes, decisions, or data.

36
4. Data flow diagrams
Data flow diagrams (DFDs) show how data enters a system from external sources, how data moves
internally within the system, and how the data is stored. DFD symbols vary slightly, but are mostly based
on the same principles:

• Squares. These show external entities, which are either the source of data, or the
destination
• Rounded rectangles. These represent processes that receive data as input, interact with it,
and then produce an output
• Arrows. These show the flow of data, either as electronic data or physical items
• Open-ended rectangles. This represents data stores, and include electronic stores like
databases or XML files, as well as physical stores, such as or filing cabinets or stacks of paper

37
5. Role activity diagrams
Role activity diagrams (RADs) are used to map out the intangible roles or ideas of behavior that are
desired within the company. These can often be functions within the business, systems in IT, or
customer and supplier roles. RADs are easy to read and understand, and often provide a different
perspective on a process, which helps support communication.

6. Role interaction diagrams

Interaction diagrams are business process models that graphically illustrate the interaction of various
process with each other within a system. Interaction diagrams come in two forms: sequence diagrams
and collaboration diagrams. There are two types of interaction diagrams typically used to capture the
various aspects of interaction in a system:

• Sequence diagrams. A sequence diagram shows the interaction between objects in the
sequence in which they take place. Sequence diagrams describe how the objects function within
a system, and in what order, and are often used to document and understand what is required
for new and existing systems

38
• Collaboration diagram- Collaboration diagrams are used to define and clarify the roles of the
objects that carry out a certain flow of events in a visual format, and serve as the main source of
information when determining class responsibilities and interfaces

39
7. Gantt charts
In the late 19th century, Gantt charts were the gold standard, and are often the go-to business process
model for companies preparing for projects with distinct timelines, or that have time-sensitive processes
that need to be captured and tracked. Gantt charts make it easy for people involved in different parts of
a process to see when they are meant to start work, and by when each task should be complete, and to
check whether all the subprocesses are on schedule.

8. Integrated definition for function modeling

Integrated definition (IDEF) for function modeling displays when parent activities give rise to child
diagrams. There are 15 forms of IDEF and each address a different type of flow for functions,
information, data, simulation model design, process description capture, and so on.

40
9. Colored Petri nets
When a system has numerous processes that interact and synchronize with each other, then colored
Petri nets are ideal. This modeling technique is used to design, specify, simulate and verify systems.

Petri nets are unique in that they can represent both a state – such as passive, unsent, or waiting – and
an action – such as send, receive, or transmit – in the same diagram. Colored nets use colors to
differentiate their symbols, and use a formal, mathematical representation with well-defined syntax and
semantics.

10. Object oriented methods

The object oriented method of business process modeling is more than just modeling with objects: it
encompasses message-passing, encapsulation (where internal detail is hidden), inheritance from class to
subclass, and polymorphism (where the same procedure can operate on different data types).

41
Which business process modeling technique will you select for your business? Find the one that will
ensure those involved in the system or process carry out their tasks in a consistent and efficient way,
producing a predictable, measurable outcome.

5. Requirements Engineering

Business Requirements Initiation (Gathering Stage)

1. Stakeholder Identification, Analysis and Mapping
2. Classification of Requirements
3. Apply Requirement Elicitation Techniques
4. Sort the Requirements
5. Prioritize the Requirements
6. Verify & Validate Requirements

Stakeholder Identification, Analysis and Mapping

What is Stakeholder Analysis?
Stakeholder Analysis is a process of mapping the interest of your stakeholders. It is a process to
systematically analyze and gather qualitative information to determine whose interest should be taken
into account. It helps project leaders and managers to assess stakeholders’ interests, positions, alliances,
and knowledge related to the project.

42
What is Stakeholder Mapping?
Stakeholder Mapping is an effective process of finding the key stakeholders related to the project. It
helps to learn about the stakeholders and identify all the individuals interested in the project outcome.
Once all the stakeholders are identified, they can be mapped and categorized depending on different
interests and engagement levels.

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: Employees and Management Outside the organization: Government & Trade Association

Process for Stakeholder Analysis and Mapping

The following stakeholder mapping example explains 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 Action

High power, interested people – Manage closely

High power, less interested people – Keep satisfied

Low power, interested people – Keep informed

Low power, less interested people – Monitor with minimum effort

Step 4) Identify areas of conflicts (organization vs. stakeholder, stakeholder vs. stakeholder)

43
Step 5) Prioritize, reconcile and balance stakeholders

Step 6) Align significant stakeholder needs with organizations strategies and actions

Next in this example of stakeholder mapping, let’s learn about 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 During Stakeholder Analysis and Mapping

Different attribute check for
Question to ask your stakeholders
stakeholder

• Identification of • Who is paying for the project?

stakeholder
• 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.

44
Different attribute check for
Question to ask your stakeholders
stakeholder

• Interest • What direct benefit do stakeholders expect to get from the project?

• What outcomes do stakeholders expect as a result of the project?

• What changes do stakeholders need to make as a result of the

project?

• Are there any conflicts of interest amongst the stakeholders?

• Influence • What legitimate authority do stakeholders have in the organization?

• Who controls the project assets and resources?

• What degree of influence or negotiation power do your identified

stakeholders carry in the organization?

• Impact • 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 in the below stakeholder
map example:

Participation Type Inform Consult Partner Control

Needs Assessment

Planning

Implement

45
Participation Type Inform Consult Partner Control

Monitoring & Evaluation

Classification of Requirements
What is Requirement?
A requirement is basically the need of the Client. This Need or Requirement will transform into a
Solution while taking various shapes and forms as it progresses from each stage of SDLC. Requirements
serve as the foundation of systems or system components. A requirement can be thought of as
something that is demanded or obligatory; a property that is essential for the system to perform its
functions. Requirements vary in intent and in kinds of properties. They can be functions, constraints, or
other elements that must be present to meet the needs of the intended stakeholders. Requirements can
be described as a condition or capability a customer needs t o solve a problem or achieve an objective.
For clarification purposes, a descriptor should always precede requirements; for example, business
requirements, user requirements, functional requirements.

Types of Requirements
1. Business Requirements

2. Stakeholder Requirements

3. Solution Requirements

a. Functional Requirements

b. Non-functional Requirements

4. Transition Requirements

Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise.
They describe the reasons why a project has been initiated, the objectives that the project will achieve,
and the metrics that will be used to measure its success. Business requirements describe needs of the
organization as a whole, and not groups or stakeholders within it. They are developed and defined
through enterprise analysis.

Stakeholder Requirements are statements of the needs of a particular stakeholder or class of

stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will
interact with a solution. Stakehol der requirements serve as a bridge bet ween business requirements
and the various classes of solution requirements. They are developed and defined through requirements
analysis.

46
Solution Requirements describe the characteristics of a solution that meet business requirements and
stakeholder requirements. They are developed and defined through requirements analysis. They are
frequently divided into sub-categories, particularly when the requirements describe a soft ware
solution:

Functional Requirements describe the behavior and information that the solution will manage.
They describe capabilities the system will be able to perform in terms of behaviors or
operations-specific information technology application actions or responses.

Non-functional Requirements capture conditions that do not directly relate to the behavior or
functionality of the solution, but rather describe environmental conditions under which the
solution must remain effective or qualities that the systems must have. They are also known as
quality or supplementary requirements. These can include requirements related to capacity,
speed, security, availability and the information architecture and presentation of the user
interface.

Transition Requirements describe capabilities that the solution must have in order to facilitate
transition from the current state of the enterprise to a desired future state, but that will not be needed
once that transition is complete. They are differentiated from other requirements types because they
are always temporary in nature and because they cannot be developed until both an existing and new
solution are defined. They typically cover data conversion from existing systems, skill gaps that must be
addressed, and other related changes to reach the desired future state. They are developed and defined
through solution assessment and validation.

Bond between Requirement and BA

The BA always ensure that the Client Requirements are properly gathered or collected, communicates
the same to the Technical Team in UML language which is more understood to them. He communicates
to Client in Business language. BA nurtures these requirements into an IT Solution with the help of the
Technical Team. Generally, the technical Team will be headed by the Project Manager (PM). PM takes
care about the technical aspects of the Project, Team management and delivery of the project within
Time frames. BA will be in continuous track of the Client Requirements through all the different stages
of Project development Life Cycle. He helps the technical team to understand the Requirements clearly
and participates in UAT along with Client. In short, we can say that "BA takes the ownership of the Client
Requirements ".

Apply Requirement Elicitation Techniques

What Is Requirements Elicitation?
It is all about obtaining information from stakeholders. In other words, once the business analysis has
communicated with stakeholders for understanding their requirements, it can be described as
elicitation. It can also be described as a requirement gathering.

Requirement elicitation can be done by communicating with stakeholders directly or by doing some
research, experiments. The activities can be planned, unplanned, or both.

47
 • Planned activities include workshops, experiments.
• Unplanned activities happen randomly. Prior notice is not required for such activities. For
example, you directly go to the client site and start discussing the requirements however
there was no specific agenda published in advance.

Following tasks are the part of elicitation:

• Prepare for Elicitation: The purpose here is to understand the elicitation activity scope,
select the right techniques, and plan for appropriate resources.
• Conduct Elicitation: The purpose here is to explore and identify information related to
change.
• Confirm Elicitation Results: In this step, the information gathered in the elicitation session is
checked for accuracy.

We hope, you have got an idea about requirement elicitation by now. Let’s move on to the
requirements elicitation techniques.

There are several techniques available for elicitation. However, the commonly used techniques are
explained below:

#1) Stakeholder Analysis

Stakeholders can include team members, customers, any individual who is impacted by the project or it
can be a supplier. Stakeholder analysis is done to identify the stakeholders who will be impacted by the
system.

#2) Brainstorming
This technique is used to generate new ideas and find a solution for a specific issue. The members
included for brainstorming can be domain experts, subject matter experts. Multiple ideas and
information give you a repository of knowledge and you can choose from different ideas.

This session is generally conducted around the table discussion. All participants should be given an equal
amount of time to express their ideas.

Brainstorming technique is used to answer the below questions:

• What is the expectation of a system?

• What are the risk factors that affect the proposed system development and what to do to
avoid that?
• What are the business and organization rules required to follow?
• What are the options available to resolve the current issues?
• What should we do so that this particular issue does not happen in the future?

Brainstorming can be described in the following phases:

48
There are some basic rules for this technique which should be followed to make it a success:

• The time limit for the session should be predefined.

• Identify the participants in advance. One should include 6-8 members for the session.
• The agenda should be clear enough for all the participants.
• Clear expectations should be set with the participants.
• Once you get all the information, combine the ideas, and remove the duplicate ideas.
• Once the final list is ready, distribute it among other parties.

Benefits:

• Creative thinking is the result of the brainstorming session.

• Plenty of ideas in a short time.
• Promotes equal participation.

Drawbacks:

• Participants can be involved in debating ideas.

• There can be multiple duplicate ideas.

49
#3) Interview

This is the most common technique used for requirement elicitation. Interview techniques should be
used for building strong relationships between business analysts and stakeholders. In this technique, the
interviewer directs the question to stakeholders to obtain information. One to one interview is the most
commonly used technique.

If the interviewer has a predefined set of questions then it’s called a structured interview.

If the interviewer is not having any particular format or any specific questions then it’s called
an unstructured interview.

For an effective interview, you can consider the 5 Why technique. When you get an answer to all your
Whys then you are done with your interview process. Open-ended questions are used to provide
detailed information. In this interviewee cannot say Yes or No only.

Closed questions can be answered in Yes or No form and also for areas used to get confirmation on
answers.

Basic Rules:

• The overall purpose of performing the interviews should be clear.

• Identify the interviewees in advance.
• Interview goals should be communicated to the interviewee.
• Interview questions should be prepared before the interview.
• The location of the interview should be predefined.
• The time limit should be described.

50
 • The interviewer should organize the information and confirm the results with the
interviewees as soon as possible after the interview.

Benefits:

• Interactive discussion with stakeholders.

• The immediate follow-up to ensure the interviewer understands.
• Encourage participation and build relationships by establishing rapport with the
stakeholder.

Drawbacks:

• Time is required to plan and conduct interviews.

• Commitment is required from all the participants.
• Sometimes training is required to conduct effective interviews.

#4) Document Analysis/Review

This technique is used to gather business information by reviewing/examining the available materials
that describe the business environment. This analysis is helpful to validate the implementation of
current solutions and is also helpful in understanding the business need.

Document analysis includes reviewing the business plans, technical documents, problem reports,
existing requirement documents, etc. This is useful when the plan is to update an existing system. This
technique is useful for migration projects.

This technique is important in identifying the gaps in the system i.e. to compare the AS-IS process with
the TO-BE process. This analysis also helps when the person who has prepared the existing
documentation is no longer present in the system.

51
Benefits:

• Existing documents can be used to compare current and future processes.

• Existing documents can be used as a base for future analysis.

Drawbacks:

• Existing documents might not be updated.

• Existing documents might be completely outdated.
• Resources worked on the existing documents might not be available to provide information.
• This process is time-consuming.

#5) Focus Group

By using a focus group, you can get information about a product, service from a group. The Focus group
includes subject matter experts. The objective of this group is to discuss the topic and provide
information. A moderator manages this session.

The moderator should work with business analysts to analyze the results and provide findings to the
stakeholders.

If a product is under development and the discussion is required on that product then the result will be
to update the existing requirement or you might get new requirements. If a product is ready to ship
then the discussion will be on releasing the product.

How Focus groups are different than group interviews?

52
A Focus group is not an interview session conducted as a group; rather it is a discussion during which
feedback is collected on a specific subject. The session results are usually analyzed and reported. A focus
group typically consists of 6 to 12 members. If you want more participants then create more than one
focus group.

Benefits:

• You can get information in a single session rather than conducting one to one interview.
• Active discussion with the participants creates a healthy environment.
• One can learn from other’s experiences.

Drawbacks:

• It might be difficult to gather the group on the same date and time.
• If you are doing this using the online method then the participant’s interaction will be
limited.
• A Skilled Moderator is required to manage focus group discussions.

#6) Interface Analysis

Interface analysis is used to review the system, people, and processes. This analysis is used to identify
how the information is exchanged between the components. An Interface can be described as a
connection between two components. This is described in the below image:

The interface analysis focus on the below questions:

1. Who will be using the interface?

2. What kind of data will be exchanged?
3. When will the data be exchanged?
4. How to implement the interface?
5. Why we need the interface? Can’t the task be completed without using the interface?

Benefits:

• Provide missed requirements.

• Determine regulations or interface standards.
• Uncover areas where it could be a risk for the project.

Drawbacks:

53
 • The analysis is difficult if internal components are not available.
• It cannot be used as a standalone elicitation activity.

#7) Process/Task Observation

The main objective of the observation session is to understand the activity, task, tools used, and events
performed by others.

The plan for observation ensures that all stakeholders are aware of the purpose of the observation
session, they agree on the expected outcomes, and that the session meets their expectations. You need
to inform the participants that their performance is not judged.

During the session, the observer should record all the activities and the time taken to perform the work
by others so that he/she can simulate the same. After the session, the BA will review the results and will
follow up with the participants. Observation can be either active or passive.

Active observation is to ask questions and try to attempt the work that other persons are doing.

Passive observation is silent observation i.e. you sit with others and just observe how they are doing
their work without interpreting them.

Benefits:

• The observer will get a practical insight into the work.

• Improvement areas can be easily identified.

Drawbacks:

• Participants might get disturbed.

• Participants might change their way of working during observation and the observer might
not get a clear picture.
• Knowledge-based activities cannot be observed.

#8) Prototyping
Prototyping is used to identify missing or unspecified requirements. In this technique, frequent demos
are given to the client by creating the prototypes so that client can get an idea of how the product will
look like. Prototypes can be used to create a mock-up of sites, and describe the process using diagrams.

Benefits:

• Gives a visual representation of the product.

• Stakeholders can provide feedback early.

Drawbacks:

• If the system or process is highly complex, the prototyping process may become time-
consuming.

54
 • Stakeholders may focus on the design specifications of the solution rather than the
requirements that any solution must address.

#9) Joint Application Development (JAD)/ Requirement Workshops

This technique is more process-oriented and formal as compared to other techniques. These are
structured meetings involving end-users, PMs, SMEs. This is used to define, clarify, and complete
requirements.

This technique can be divided into the following categories:

• Formal Workshops: These workshops are highly structured and are usually conducted with the
selected group of stakeholders. The main focus of this workshop is to define, create, refine, and
reach closure on business requirements.

• Business Process Improvement Workshops: These are less formal as compared to the above
one. Here, existing business processes are analyzed and process improvements are identified.

Benefits:

• Documentation is completed within hours and is provided quickly back to participants for
review.
• You can get on the spot confirmation on requirements.
• Successfully gathered requirements from a large group in a short period.
• Consensus can be achieved as issues and questions are asked in the presence of all the
stakeholders.

Drawbacks:

• Stakeholder’s availability might ruin the session.

• The success rate depends on the expertise of the facilitator.
• A workshop motive cannot be achieved if there are too many participants.

#10) Survey/Questionnaire
For Survey/Questionnaire, a set of questions is given to stakeholders to quantify their thoughts. After
collecting the responses from stakeholders, data is analyzed to identify the area of interest of
stakeholders.

Questions should be based on high priority risks. Questions should be direct and unambiguous. Once the
survey is ready, notify the participants and remind them to participate.

Two types of questions can be used here:

• Open-Ended: Respondent is given the freedom to provide answers in their own words rather
than selecting from predefined responses. This is useful but at the same time, this is time-
consuming as interpreting the responses is difficult.

55
 • Close Ended: It includes a predefined set of answers for all the questions and the respondent
has to choose from those answers. Questions can be multiple choices or can be ranked from not
important to very important.

Benefits:

• Easy to get data from a large audience.

• Less time is required for the participants to respond.
• You can get more accurate information as compared to interviews.

Drawback:

• All the Stakeholders might not participate in the surveys.

• Questions may not be clear to all the participants.
• Open-ended questions require more analysis.
• Follow up surveys might be required based on the responses provided by participants.

Amongst the all above techniques, the top five techniques that are commonly used for elicitation are
shown in the below image.

Sort the Requirements

Sorting the requirements is the process in which scattered requirements are put together and
redundancy is removed the inter related requirements are linked

56
Key Tasks are

• Define Stakeholder needs

• Identify Business needs and divide them into functional and non-functional requirements Create
group of similar requirements
• Create supporting artifacts

Prioritize the Requirements

Analyze key areas that are taken into account before taking an important decision

• Benefit – an advantage that the business gets as a result of the required implementation.
• Penalty – a consequence of not implementing a requirement.
• Cost – effort and resources that are required to implement a requirement
• Risk – a probability that the requirement might not deliver the expected value.
• Dependencies – a relationship between requirements, for example when requirement will
require the completion of another requirement for its implementation.
• Time sensitivity – expiry date, urgency.
• Stability – the likelihood of the requirement remaining static.
• Policy Compliance – requirements that must be implemented to meet the regulatory
requirements.

MoSCoW
MoSCoW method works better than the numeric rating system as it is much easier for the stakeholders
to rate the requirements as Must, Should, Could or Would.

The acronym represents the following:

MUST – mandatory
SHOULD – of high priority
COULD – preferred but not necessary
WOULD – can be postponed and suggested for future execution

Voting
This is the simplest way to prioritize the requirements. When there are too many requirements that
need to be categorized into different categories with inputs from different stakeholders, voting is one of
the best ways to sort out the prioritization of requirements. Let’s say if 10 features are under discussion,
stakeholders have 10 points and they need to spread them across these features. For example, least
important= 1, most important= 10.

Bubble sort technique

Very similar to voting, but for some people, this technique helps them get the right priority faster. To
prioritize requirements using bubble sort technique, you take two requirements and compare them with
each other. If you find out that one requirement has greater priority over the other, you swap them

57
accordingly. You then continue in this way until the very last requirement is properly sorted. The result
is a list of requirements that are ranked.

Hundred Dollar Method

This simple method is useful anywhere multiple stakeholders need to democratically vote on which
requirements are the most important. All stakeholders get a conceptual 100 dollars, which they can
distribute among the requirements. As such, the stakeholder may choose to give all 100 dollars to a
single requirement, or the person may distribute the points more evenly. The higher the amount
allocated to each requirement, the higher the priority of the requirement. At the end, the total is
counted and the requirements are sorted based on the number of points received.

Let’s look at the example of how the software requirements prioritization process may look
like:
1. First of all what you do is creating a list of all the requirements, features, or use cases that you wish to
prioritize in a spreadsheet. If certain features are logically linked, include only the driving feature in the
analysis.

2. The second step is estimating the relative benefit that each feature provides to the customer, the
business on a scale from 1 to 9, with 1 indicating very little benefit and 9 being the maximum possible
benefit.

3. The third step is estimating the relative penalty the customer or business would suffer if the feature is
not included. Again, use a scale from 1 to 9, where 1 means essentially no penalty and 9 indicates a very
serious downside.

4. Then goes the total value – it is the sum of the relative benefit and penalty. By default, benefit and
penalty are weighted equally.

5. What is next? Estimation of the relative cost of implementing each feature, again on a scale ranging
from a low of 1 to a high of 9.

6. Developers estimate the relative degree of technical or other risk associated with each feature on a
scale from 1 to 9.

7. Once you enter the estimates into the spreadsheet, it calculates a priority number for each feature
and gives you the results taking into account all the inputs.

8. Sort the list of features in descending order by calculated priority. The features at the top of the list
have the most favorable balance of value, cost, and risk, and thus should have higher implementation
priority.

Requirements Verification and Validation

Requirements verification and requirements validation are two different methods used to ensure that
the gathered requirements meet the user’s needs. The distinction between those two terms is largely
related to the specifications. The difference between validations with respect to verification is:

58
• Verification: It is a process to check whether the software meets the specified requirements that are
written during elicitation phase or not. This is a process of confirming that the designed and built
product fully meets the documented requirements.

Those checks are: • Inspection • Analysis • Demonstration • Test • Expert review

• Validation: It is a process to check whether the specifications written during the elicitation phase
captures all the user’s needs. During validation phase developers use different set of tasks that ensures
that the software built is traceable to user’s requirements.

There are several techniques which are used individually or with other techniques to check the system,
which are:

1. Test case generation: The requirements mentioned in the SRS document should be testable. If it is
not testable then that generally means that the test is difficult or impossible to design. It is believed that
if the test is difficult to design then it means that it will be difficult to practically implement the
requirements to create the system and thus the requirements should be reconsidered.

2. Prototyping: In this validation technique, a basic working model (prototype) of the system is
presented before the end-user, they test and experiment with the presented model to check if it meets
their specified requirements. This technique is generally used to take feedback from the user.

3. Requirements reviews: In this approach, a group of people from both organization side and user side
carefully reviews the SRS. They review the document to check for any errors and ambiguity.

4. Automated consistency analysis: First, the requirement is structured in formal notation then a tool
like CASE is used to check for any in-consistency or errors. For the identified inconsistencies and errors
corrective actions are taken. In this approach, automated detection tool is used to search for type
errors, missing cases, error in requirement specification, etc.

5. Walk-through: This is not a formally defined procedure. The approach follows few steps, they are:

• Checking whether the idea is feasible or not

• Obtaining the ideas and opinions of other

• Checking the approval of others and reaching an agreement.

In conclusion, requirements validation ensures that the documented requirements gathered during
elicitation phase correctly captures the customer’s needs and requirements verification ensures that the
developed software meets those specifications or requirements. The combination of these two is called
V&V generally means Validation and Verification which is used to check everything from documented
user’s requirements to developed software.

59
Requirements Documentation
Business Requirement Document
A business analyst who has a thorough understanding of the business processes drafts
business/functional requirement document. The business requirement document is drafted for a project
to ensure the implementation of all the requirements to achieve business objectives.

The most critical component of a business requirement document is the scope of the project along with
the restrictions and constraints. The scope comprises of three key things:

• What are the problems which the business wants to solve?

• What are the restrictions?
• Is it worth to invest the time and money required for the project?

What are the preparations required to create a business requirements document?

• You should define the need of the company/ organization
• You have to get all the stakeholders involved.
• You must identify the phases of the project.
• You should establish benchmarks/ standards for all project requirements.
• You need a process in place to monitor the schedule & measure milestones.
• You will also need to use a suitable template.

Business Requirement Document Template

The ideal business requirement document template or sample BRD template should have the following
components:

1- A summary statement

The executive summary is the outline of the requirements of the project. The best time to formulate a
summary statement is once the BRD is written completely.

2- Project objectives

The project objectives should be written in a SMART format which implicates they must be specific,
measurable, attainable, realistic and time-bound.

3- Needs statement

The needs statement outlines why the project is needed for the business and how the project will be
able to meet the needs.

4- Project scope

The project scope outlines what to be included and what should not be included.

5- Financial statements

60
The financial statements indicate the impact of the project on the company’s balance sheet and revenue
over the specific period of time. This also holds the information on the funding of the project and how it
would be done.

6- Functional requirements

This section outlines in a detailed manner the functional requirements and corresponding features
including diagrams, charts, and timelines.

7- Personal needs

This section covers the human resources aspect of the project. Who needs to be hired and when the
hiring needs to be done. It also covers the cost of the resources.

8- Schedule, timeline & deadlines

Each phase of the project is covered in detail in this section. This helps to ensure that all stakeholders
are aware of what is required and when it will be required.

9- Assumptions

The assumptions outline anticipated events that would occur during the course of the project.

10- Cost & Benefit

This section holds a detailed list of all the costs involved in the project along with the cost-benefit
analysis. The savings from the project are also listed here.

Functional Requirement Document

Definition: “Any Requirement Which Specifies What The System Should Do.”

A functional requirement will describe a particular behavior of function of the system when certain
conditions are met, for example: “Send email when a new customer signs up” or “Open a new account”.

A functional requirement for an everyday object like a cup would be: “ability to contain tea or coffee
without leaking”.

Common/Sample Format of FRD

1. INTRODUCTION

[Provide an overview of the system and some additional information to place the system in context.]

1.1 Purpose

[Provide an overall description of the FRD, its purpose. Reference the system name and identifying
information about the system to be implemented.]

61
1.2 Scope

[Discuss the scope of the document and how it accomplishes its purpose.]

1.3 Background

[Describe the organization and its overall responsibilities. Describe who is producing the document and
why.]

1.4 References

[List references and controlling documents, including: meeting summaries, white papers, other
deliverables, etc.]

1.5 Assumptions and Constraints

[Provide a list of contractual or task level assumptions and/or constraints that are preconditions to
preparation of the FRD. Assumptions are future situations beyond the control of the project, whose
outcomes influence the success of a project.]

1.5.1 Assumptions

Examples of assumptions include: availability of a technical platform, legal changes and policy decisions.

1.5.2 Constraints

Constraints are boundary conditions on how the system must be designed and constructed. Examples
include: legal requirements, technical standards, strategic decisions.

• Constraints exist because of real business conditions. For example, a delivery date is a
constraint only if there are real business consequences that will happen as a result of not
meeting the date. If failing to have the subject application operational by the specified date
places the organization in legal default, the date is a constraint.

• Preferences are arbitrary. For example, a date chosen arbitrarily is a preference. Preferences, if
included in the FRD, should be noted as such.]

1.6 Document Overview

[Provide a description of the document organization.]

2 METHODOLOGY

[Describe the overall approach used in the determination of the FRD contents. Describe the modeling
method(s) so non-technical readers can understand what they are conveying.]

3 FUNCTIONAL REQUIREMENTS

62
4.1 Context

[Provide a context diagram of the system, with explanations as applicable. The context of a system
refers to the connections and relationships between the system and its environment.]

Exhibit 2 - Generic Context Diagram

Data 1
Data 3
Interface
Interface
Name 1
Name 2
(User) Data 2 Data 4

System/
Application
Name

Data 7
Interface Data 5 Interface
Name 3 Name 4

Data 6 Data 8

4.2 User Requirements

[Provide requirements of the system, user or business, taking into account all major classes/categories
of users. Provide the type of security or other distinguishing characteristics of each set of users. List the
functional requirements that compose each user requirement. As the functional requirements are
decomposed, the highest level functional requirements are traced to the user requirements. Inclusion
of lower level functional requirements is not mandatory in the traceability to user requirements if the
parent requirements are already traced to them.

User requirement information can be in text or process flow format for each major user class that shows
what inputs will initiate the system functions, system interactions, and what outputs are expected to be
generated by the system. The scenarios should be comprehensive, to the extent that all user types and
all major functions are covered. Give each user requirement a unique number. Typically, user
requirements have a numbering system that is separate from the functional requirements.
Requirements may be labeled with a leading “U” or other label indicating user requirements.]

4.3 Data Flow Diagrams

[Decompose the context level diagrams to determine the functional requirements. Data flow diagrams
should be decomposed down to the functional primitive level. These diagrams are further decomposed
during design.]

4.4 Logical Data Model/Data Dictionary

63
[Create the initial Logical Data Model. Describe data requirements by providing data entities,
decomposition, and definitions in a data dictionary. The data requirements describe the business data
needed by the application system. Data requirements do not describe the physical database and are not
at the level of identifying field names.]

4.5 Functional Requirements

[List the functional requirements of the system.]

4.5.1 Functional Requirements Group 1

[List the functional requirements for each functional requirements group.]

Section/
Requirement ID Requirement Definition

FR1.0. The system shall [parent requirement group 1].

FR1.1 The system shall [child/parent requirement].

FR1.1.1 The system shall [child requirement].

FR1.1.2 The system shall [child requirement].

5 OTHER REQUIREMENTS

Note: This section will be part of “SRS Software Requirement Specification”.

[Describe the non-behavioral requirements.]

5.1 Interface Requirements

[Describe the user interfaces that are to be implemented by the system.]

5.1.1 Hardware Interfaces

[Define hardware interfaces supported by the system, including logical structure, physical addresses,
and expected behavior.]

5.1.2 Software Interfaces

[Name the applications with which the subject application must interface. State the following for each
such application: name of application, external owner of application, interface details (only if
determined by the other application).

It is acceptable to reference an interface control document for details of the interface interactions.]

64
5.1.3 Communications Interfaces

[Describe communications interfaces to other systems or devices, such as local area networks.]

5.2 Data Conversion Requirements

[Describe the requirements needed for conversion of legacy data into the system.]

5.3 Hardware/Software Requirements

[Provide a description of the hardware and software platforms needed to support the system.]

5.4 Operational Requirements

[Provide the operational requirements in this section.

Do not state how these requirements will be satisfied. For example, in the Reliability section, answer
the question, “How reliable must the system be”? Do not state what steps will be taken to provide
reliability.

Distinguish preferences from requirements. Requirements are based on business needs, preferences
are not. If, for example, the user requires a special response but does not have a business-related
reason for it, that requirement is a preference.

Other applicable requirements on system attributes may be added to the list of subsections below.]

Operational requirements describe how the system will run and communicate with operations
personnel.

5.4.1 Security and Privacy

[Provide a list of the security requirements using the following criteria:

A. State the type(s) of security required. Include the need for the following as appropriate:

1. Physical security.
2. Access by user role or types.
3. State access control requirements by data attribute. For example, one group of users has
permission to view an attribute but not update it while another group of users has permissions
to update or view it.
4. State access requirements based on system function. For example, if there is a need to grant
access to certain system functions to one group of users, but not to another. For example, "The
system shall make Function X available to the System Administrator only".
5. State if there is a need for certification and accreditation of the security measures adopted for
this application]

65
The Security Section describes the need to control access to the data. This includes controlling who may
view and alter application data.

5.4.2 Audit Trail

[List the activities recorded in the application’s audit trail. For each activity, list the data recorded.]

5.4.3 Reliability

A. State the following in this section:

What is the minimum acceptable level of reliability?

State required reliability:

1. Mean-Time-Between-Failure is the number of time units the system is operable before the first
failure occurs.
2. Mean-Time-To-Failure is the number of time units before the system is operable divided by the
number of failures during the time period.
3. Mean-Time-To-Repair is the number of time units required to perform system repair divided by
the number of repairs during the time period.]

Reliability is the probability that the system processes work correctly and completely without being
aborted.

5.4.4 Recoverability

[Answer the following questions in this section:

A. In the event the application is unavailable to users (down) because of a system failure, how soon
after the failure is detected must function be restored?
B. In the event the database is corrupted, to what level of currency must it be restored? For
example “The database must be capable of being restored to its condition of no more than 1
hour before the corruption occurred”.
C. If the processing site (hardware, data, and onsite backup) is destroyed, how soon must the
application be able to be restored?]

Recoverability is the ability to restore function and data in the event of a failure.

5.4.5 System Availability

[State the period during which the application must be available to users. For example, “The application
must be available to users Monday through Friday between the hours of 6:30 a.m. and 5:30 p.m. EST. If
the application must be available to users in more than one time zone, state the earliest start time and
the latest stop time. Consider daylight savings time, too.

Include use peak times. These are times when system unavailability is least acceptable.]

66
System availability is the time when the application must be available for use. Required system
availability is used in determining when maintenance may be performed.

5.4.6 General Performance

[Describe the requirements for the following:

A. Response time for queries and updates

B. Throughput
C. Expected rate of user activity (for example, number of transactions per hour, day, or month,
or cyclical periods)

Specific performance requirements, related to a specific functional requirement, should be listed with
that functional requirement.

5.4.7 Capacity

[List the required capacities and expected volumes of data in business terms. Do not state capacities in
terms of system memory requirements or disk space—if growth trends or projections are available,
provide them]

5.4.8 Data Retention

[Describe the length of time various forms of data must be retained and the requirements for its
destruction.

For example, “The system shall retain application information for 3 years”. Different forms of data
include: system documentation, audit records, database records, access records.]

5.4.9 Error Handling

[Describe system error handling.]

5.4.10 Validation Rules

[Describe System Validation Rules.]

5.4.11 Conventions/Standards

[Describe system conventions and standards followed.

For example: Microsoft standards are followed for windows, Institute of Electrical and Electronics
Engineers (IEEE) for data formats, etc.]

67
APPENDIX A - GLOSSARY

[Define terms, acronyms, and abbreviations used in the FRD.]

BRD Vs SRS Vs FRD

Based on BRD or BRS SRS FRD

BRD or a BRS includes the FRD document consists of

high-level business SRS document includes the detailed requirements in
requirement of a system to functional and non- technical terms and technical
What it be developed in layman functional requirements diagrams like UML, Data Flow,
includes? language. and Use Cases. etc.

BRD answers the WHY part SRS answers the WHAT i.e. FRS focuses on the HOW part i.e.
What is i.e. Why the requirements What requirements to be How the requirements will be
Answers? are being prepared? fulfilled. implemented.

A BRD document is created SRS document is prepared FRD or FRS document is also
When will it during the analysis phase of during the planning phase created during the planning
be prepared? the project. of the project. phase of the project.

Since the functional requirement

document is detailed and
Business Analyst and technical, it is created by
Who will be System Analyst work Business Analyst, System
responsible A BRD will be created by the together to prepare an SRS Analysts, and Implementation
for creating? business analysts. document. team together.

Business Requirements SRS document is prepared FRD document will be used by

Document is developed for for the subject matter the development team and
Who will be the business users, experts and technical quality assurance i.e. testing
using? stakeholders, etc. leads. team.

Use-Case
A use-case describes a sequence of actions, performed by a system that provides value to an actor. The
use-case describes the system’s behavior under various conditions as it responds to a request from one
of the stakeholders, called the primary actor.

The actor is the Who of the system, in other words the end user.

In software and systems engineering, a use-case is a list of steps, typically defining interactions between
a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an
external system.

A use-case specifies the flow of events in the system. It is more concerned with what is performed by
the system in order to perform the sequence of actions.

68
Benefits of a Use-Case

• It is an easy means of capturing the functional requirement with a focus on value added to
the user.
• Use-cases are relatively easy to write and read compared to the traditional requirement
methods.
• Use-cases force developers to think from the end user perspective.
• Use-case engage the user in the requirement process.

Use-Case Template
Here, we have shown a sample template of a Use-Case which a Business Analyst can fill so that the
information can be useful for the technical team to ascertain information about the project.

Use-case ID:

Use-case Name:

Created By: Last Updated By

Date Created: Date Last Updated

Actor:

Description:

Preconditions:

Post conditions:

Priority:

Frequency of Use:

Normal Course of

69
Events:

Alternative Courses:

Exceptions:

Includes:

Special Requirements:

Assumptions:

Notes and Issues:

Example ─ Withdrawal Use-Case

The goal of a customer in relation to our money vending machine (ATM) is to withdraw money. So, we
are adding Withdrawal use-case. Withdrawing money from the vending machine might involve a bank
for the transactions to be made. So, we are also adding another actor – Bank. Both actors participating
in the use-case should be connected to the use-case by association.

Money vending machine provides Withdrawal use-case for the customer and Bank actors.

70
Requirement Traceability Matrix
Requirement Traceability Matrix (RTM) is a document that maps and traces user requirement with test
cases. It captures all requirements proposed by the client and requirement traceability in a single
document, delivered at the conclusion of the Software development life cycle. The main purpose of
Requirement Traceability Matrix is to validate that all requirements are checked via test cases such that
no functionality is unchecked during Software testing.

Which Parameters to include in Requirement Traceability Matrix?

• Requirement ID
• Requirement Type and Description
• Test Cases with Status

Below is a sample requirement traceability matrix.

71
 6. Contribution of BA in Projects

➢ Change Management Process

➢ Gap Analysis: As-IS and To-Be mapping
➢ Business Strategic Planning Technique – SWOT, SOAR, PESTLE, MOST
➢ Root Cause Analysis – Five Why Technique, Seven So What Technique, Pareto Analysis

Change Management Process

Change Request (CR) – A formally submitted artifact that is used to track all stakeholder
requests (including new features, enhancement requests, defects, changed requirements, etc.) along
with related status information throughout the project lifecycle. All change history will be maintained
with the Change Request, including all state changes along with dates and reasons for the change. This
information will be available for any repeat reviews and for final closing.

72
In project management, a change request often arises when the client wants an addition or alteration to
the agreed-upon deliverables for a project. Such a change may involve an additional feature or
customization or an extension of service, among other things. Because change requests are beyond the
scope of the agreement, they generally mean that the client will have to pay for the extra resources
required to satisfy them.

One of the more challenging aspects of change management is ensuring that all details are sufficiently
explicated and that all parties are in agreement as to what is expected. Explicit and detailed
documentation makes it easier to identify when a change request must be submitted.

Change requests can also originate internally. Internal change requests can involve a wide variety of
actions including patching and software and hardware upgrades.

Once a change request has been made, the process of change control should be undertaken to make
sure that the request is satisfied efficiently and without unnecessary use of resources.

Gap Analysis: As-IS and To-Be mapping

What Is a Gap Analysis?
A gap analysis process allows organizations to determine how to best achieve their business goals. It
compares the current state with an ideal state or goals, which highlights shortcomings and opportunities
for improvement.

73
1. Analyze your current state

First, you’ll need to choose which area of your business you want to focus on and start with your current
state. You need to discover where your organization currently is before you can make a plan for
reaching your goals.

For example, your company wants to become the most loved in your industry, but your customer
support team reports that many calls and customer interactions end in frustration on the customers’
part.

2. Identify the ideal future state

Once you have the big picture figured out and understand how your team or organization currently
functions, you need to become idealistic. Where would you like to be? What’s not happening that
should be? Don’t worry yet about how you’ll get there. That’s the next step. Right now, the sky’s the
limit, and you should dream big.

3. Find the gap and evaluate solutions

Completing the first two steps in isolation won’t get you great results––the status quo can seem
inescapable, and goals can feel lofty and unattainable. Putting them together, however, exposes what’s
missing between your performance and your potential. You also need to decide which solutions will
most effectively bridge the gap.

4. Create and implement a plan to bridge the gap

After you’ve charted out the possible ways to bridge the gap and decided which would be best, you
likely still need to convince others in your organization of that as well. The changes that you’ll
implement may also affect other teams and department, so it’s important to come up with a plan.

Establish a clear strategy and actionable objectives to help you actualize your transition and get
everyone on board.

74
Business Strategic Planning Technique – SWOT, SOAR, PESTLE, MOST
SWOT analysis
SWOT analysis is perhaps one of the oldest textbook-marketing assets. SWOT stands for strengths,
weaknesses, opportunities, and threats. You can perform a SWOT analysis both quantitatively and
qualitatively. This process will help you determine internal and external threats to your organization and
see where and how you stand out against the competition.

• Strengths: characteristics of the business or project that give it an advantage over others
• Weaknesses: characteristics that place the business or project at a disadvantage relative to
others
• Opportunities: elements in the environment that the business or project could exploit to its
advantage
• Threats: elements in the environment that could cause trouble for the business or project

75
SOAR Analysis
A SOAR analysis maintains the Strengths and Opportunities sections of a SWOT analysis but introduced
Aspirations and Results in the place of Weaknesses and Threats. Aspirations focus on what the
organization wants to do, who they want to serve, and where they wish to operate. The results section
addresses how the organization will identify and track their progress toward their Aspirations and
Opportunities. This section works to ensure that the organization is making progress and sticking to its
plan for achieving its goals.

WHAT ARE THE ADVANTAGES OF A SOAR ANALYSIS?

A SOAR analysis is considered oriented toward action to a greater degree than a SWOT analysis. A SWOT
analysis is more analytical in its approach. This difference makes SOAR more useful for younger
organizations that are developing their identity or brand. SOAR provides an option for organizations that
will not know exactly what their weaknesses are yet. It is a forward-thinking examination rather than an
analysis based on experience. Additionally, SOAR tends to be more positive whereas SWOT tends to
focus on opposing forces and competition.

PESTLE Analysis
The PESTLE analysis examines six factors: Political, Economic, Social, Technological, Legal and
Environmental. The analysis uses this framework to determine whether macro-economic factors are
affecting an organization.

76
Political: how much is the government involved in the economy or in your organization’s particular
market?

Economic: how many economic factors (interest rates, employment, foreign exchanged, unemployment,
etc.) will affect your organization’s profitability?

Social: how much do emerging trends or demographic changes (population growth, age distribution,
etc.) affect your organization?

Technological: how much do technological innovation, development, and disruption affect the
organization’s market or the industry/sector?

Legal: how will changes in legislation affect the organization’s profitability, sustainability, and growth?

Environmental: how much do the surrounding environment and ecological impact influence the
organization’s policies?

WHAT ARE THE ADVANTAGES OF A PESTLE ANALYSIS?

Understanding these six macro-economic factors and their relationship with an organization is an useful
first step toward potential threats and weaknesses. Similar to the next analysis, Five Forces, this general
framework is best when complemented by another analysis. This analysis is commonly used in
conjunction with a SWOT analysis rather than as an alternative. The PESTLE analysis works well to
ensure that marketers are not making decisions while thinking they work in a vacuum. Similarly, the
PESTLE form accounts for the dynamic macro-economic landscape. This allows businesses to plan and
adapt.

MOST
MOST is short for Mission, Objectives, Strategies, and Tactics. MOST analysis is used to improve internal
processes and company culture by analyzing the organization’s internal environment. MOST analysis is
extremely powerful – and often empowers businesses with a new sense of capability and purpose.

Mission

Basically, this is the main purpose of the business plan that we discussed above. It should be the top-
level, overall reason for being in business in terms of what you want to accomplish. The more specific
that you can be when defining your mission, the more success you will have later on trying to define the
remaining points within the tool.

Objectives

Your objectives are one step down from your mission. Think of these are a collection of individual goals
that will add up to reaching your overall mission. Just like with the mission, objectives should be specific
enough to guide your decision making and planning for the future. With your mission in place, it should
be relatively easy to develop a list of a few objectives.

77
Strategy

These are the things you are going to do in order to reach your objectives. What actions should be taken
in order to accomplish your objectives, and in turn, your mission? Keeping up with the example we have
been using, the following are a few sample business strategies that could be used:

• Run a promotion to entice new customers to switch from your competition, such as offering
to beat any rate by 10%
• Invest in new advertising channels such as paid online advertisements or local radio
• Offer benefits to customers who take the time to leave a review about your business

Tactics

Your tactics should be the specific details that will guide your daily activities. So, if you are going to run
radio ads as mentioned in the previous example, some tactics would include writing a script, hiring a
voice over artist, contacting radio stations, etc. Using your tactics to dictate your daily activities is the
best way to make sure what you are doing today will guide you in the right direction toward your overall
mission.

Root Cause Analysis

Root cause analysis (RCA) is the process of discovering the root causes of problems in order to identify
appropriate solutions. RCA assumes that it is much more effective to systematically prevent and solve
for underlying issues rather than just treating ad hoc symptoms and putting out fires.

Five Whys (5 Whys)

Five whys (or 5 whys) is an iterative interrogative technique used to explore the cause-and-
effect relationships underlying a particular problem.[1] The primary goal of the technique is to determine
the root cause of a defect or problem by repeating the question "Why?". Each answer forms the basis of
the next question. The "five" in the name derives from an anecdotal observation on the number of
iterations needed to resolve the problem.

An example of a problem is: The vehicle will not start.

1. Why? – The battery is dead. (First why)

2. Why? – The alternator is not functioning. (Second why)

3. Why? – The alternator belt has broken. (Third why)

4. Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why)

5. Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth
why, a root cause)

The questioning for this example could be taken further to a sixth, seventh, or higher level, but
five iterations of asking why is generally sufficient to get to a root cause.

78
7 So What Technique
So what? Its place in critical thinking differs from its conventional use; here, So what? is not a question
you ask if you don't care. Rather, you ask because you care a great deal. What you really want to know
is, “What is the relevance of this?” or “What if this were to happen?” You're truly asking, “Why is this
important?” Although that's a question with a why in it, you're really asking for the so what. However,
you must take care when using so what; people could easily misinterpret it as your being a wise guy or
insubordinate.

I can remember the very first time I asked, “So what?” A customer care manager came to me and said,
“Mike, our call hold time (the amount of time a customer has to wait on the line until a customer service
representative takes the call) is down to 15 seconds.” I asked him if I should be happy or sad, and the
manager responded that I should be happy.

I asked, “Why?”

The manager explained, “Because we answer calls in 15 seconds.”

“So what?”

At that point, the customer care manager looked at me in confusion. The conversation continued. What
was the value of answering the call in 15 seconds, when our nearest competitor took over 60 seconds?
Will our customers buy more from us? Will they recommend us? Will we retain them longer? It was
costing us a lot of money to answer calls that quickly; could..

What Is Pareto Analysis?

Pareto analysis is premised on the idea that 80% of a project's benefit can be achieved by doing 20% of
the work—or, conversely, 80% of problems can be traced to 20% of the causes. Pareto analysis is a
powerful quality and decision-making tool.

Steps to identify the important causes using 80/20 rule

1. Form a frequency of occurrences as a percentage

2. Arrange the rows in decreasing order of importance of the causes (i.e., the most important
cause first)
3. Add a cumulative percentage column to the table, then plot the information
4. Plot (#1) a curve with causes on x- and cumulative percentage on y-axis
5. Plot (#2) a bar graph with causes on x- and percent frequency on y-axis
6. Draw a horizontal dotted line at 80% from the y-axis to intersect the curve. Then draw a
vertical dotted line from the point of intersection to the x-axis. The vertical dotted line
separates the important causes (on the left) and trivial causes (on the right)
7. Explicitly review the chart to ensure that causes for at least 80% of the problems are
captured.

79
 7. BA Tools

Activity Tool
Prototyping Draw.io
Agile Project management JIRA
Repository Confluence
Database usage MS SQL

Prototyping - Draw.io
Visualization made easy

Teams around the world use draw.io to create powerful diagrams like BPMN and UML processes or
network architectures. You can also collaborate on digital whiteboards in meetings or brainstormings.

Smooth migration Bring your existing diagrams over to draw.io using our easy 1-Click batch Migration
function. Moving from draw.io for Confluence Server and Data Center to Cloud is just as easy.

You can use draw.io to visualize everything:

• Process Modeling and Relationships (BPMN 2.0, ERD, Flowcharts, Swimlane diagrams…)
• Software Development and Networks (UML, UML 2.5, AWS…)
• Administration (Org charts, Mindmaps, Floorplans, Infographics)
• Meetings and Brainstormings etc.,

80
Agile Project management - JIRA

Plan: Create user stories and issues, plan sprints, and distribute tasks across your software team.

Track: Prioritize and discuss your team’s work in full context with complete visibility.

Release: Ship with confidence and sanity knowing the information you have is always up-to-date.

Report: Improve team performance based on real-time, visual data that your team can put to use.

81
Choose a workflow, or make your own: Every team has a unique process for shipping software. Use an
out-of-the-box workflow, or create one to match the way your team works.

Connect your team's work to your product roadmap: Ship faster and more reliably by building smarter
plans for your team and for your organization.

Repository - Confluence
Why Confluence?

Break down team silos An open, connected structure allows information to flow freely among everyone
at the organization.

Turn conversations into action Built for lasting knowledge so you never lose great ideas or context in a
transient notification or chat.

82
Organize everything in one place From quarterly planning docs to new hire blogs, everything lives on
Confluence.

Build a culture of open teamwork With social features, employees at every level have a voice to
contribute, share, and receive feedback.

Move work forward From actionable meeting notes to inspiring project plans, kickstart team
participation with a flexible workspace.

83
Capture everything Save time by harnessing your teams' collective knowledge into easy-to-find answers
for everyone.

Inspire conversation Encourage all teams – from marketing to engineering – to share announcements,
strengthen company culture, and get instant feedback.

Database - MS SQL
What is SQL?
• SQL stands for Structured Query Language
• SQL will let you access and manipulate databases
• SQL became a standard of the American National Standards Institute (ANSI) in 1986, and of
the International Organization for Standardization (ISO) in 1987.

84
What Can SQL do?
• SQL can execute queries against a database
• SQL can retrieve data from a database
• SQL can insert records in a database
• SQL can update records in a database
• SQL can delete records from a database
• SQL can create new databases
• SQL can create new tables in a database
• SQL can create stored procedures in a database
• SQL can create views in a database
• SQL can set permissions on tables, procedures, and views

Here are some most commonly used commands in SQL

• SELECT - extracts data from a database.

• UPDATE - updates data in a database.
• DELETE - deletes data from a database.
• INSERT INTO - inserts new data into a database.
• CREATE DATABASE - creates a new database.
• ALTER DATABASE - modifies a database.
• CREATE TABLE - creates a new table.

These commands are categorized into:

• DDL
• DCL
• DML
• TCL

Let's see these categories one-by-one.

DDL
Data Definition Language (DDL) commands category is responsible for dealing with the structure of
objects. With these commands, we can modify our object/entity structure. For example, if there's one
table and you want to modify the structure of that table, you can use DDL commands.

The following are the commands in this category.

Command Description

Create Used to create objects.

85
Alter Used to modify the created object.

Drop Used to delete the object.

Using these commands, you can create any object like tables, views, databases, triggers, and so on.
For example -

1. CREATE DATABASE DB2

2. GO
3. CREATE TABLE tblDemo
4. (
5. Id int primary key,
6. Name char(20)
7. )
8. GO
9. DROP DATABASE DB2

DML
Data Manipulation Language (DML) commands manipulate the data stored in objects like tables, views,
etc. With the help these commands, you can easily modify, insert, and delete your data.

The following are the commands in this category.

Command Description

Insert Insert data into table.

Delete Delete data from the table.

Update Update data into a table.

Insert Insert bulk data into a table.

Using these commands, you can manipulate any kind of data stored in entities.
For example:

1. INSERT INTO tblDemo VALUES (1,'Abhishek')

2. GO
3. DELETE FROM tblDemo WHERE Id = 4
4. GO
5. UPDATE tblDemo
6. SET Name = 'Sunny'
7. WHERE Id = 6
8. GO

86
DCL
Data Control Language (DCL) commands are for security purposes. These commands are used to provide
roles, permissions, access and so on.

The following are the commands in this category:

Command Description

Grant Provide user access to the Database or any other object.

Revoke Take back the access from the user.

For example, we have the following data.

Database: CSharpCornerDB
Table:
User: CSharpCorner

Currently, we haven't provided any permission for this user.

Now, we'll create a table in the CSharpCornerDB database.

1. CREATE table tblArticles

2. (
3. ArticleId int primary key identity,
4. ArticleName varchar(10),
5. Category varchar(10)
6. )

If we execute this command, we'll get an error message.

Msg 262, Level 14, State 1, Line 1
CREATE TABLE permission denied in database 'CSharpCornerDB'.

87
This is because this user doesn't have permission to create anything right now. We'll learn how to grant
or revoke permission on objects in our next article.

TCL
Transaction Control Language (TCL) commands are for managing transactions in SQL Server. The
following are the commands in this category.

Command Description

Commit Used to save any transaction permanently.

Rollback This command is used to restore the database to its last committed state.

This command is used to save the transaction so that we can roll back that transaction to the
Save Tran
point whenever necessary.

For example, we have a table named "tblStudent" with 3 records as shown below.

Now, we'll begin our transaction and add another record and commit that transaction.

1. Begin Tran
2. Insert INTO tblStudents VALUES ('Sumit')
3. COMMIT

Now, we have 4 records.

Now, we'll add three records, one by one with save point, but we don't commit our transaction.

88
 1. Begin Tran
2. Insert INTO tblStudents VALUES ('Kajal')
3. SAVE Tran A;
4. Insert INTO tblStudents VALUES ('Rahul')
5. SAVE Tran B;
6. Insert INTO tblStudents VALUES ('Ram')
7. SAVE Tran C;

8. SELECT * from tblStudents

Now, we have the following records in the table, in which the last three records are not yet committed.

Now, we have 3 savepoints - A, B, and C. Since our transaction is not yet committed, we can roll it back
to any savepoint. We'll roll it back to point B, i.e., at "Rahul".

1. ROLLBACK TRAN B
2. COMMIT

Now, when you fire the Select query, you'll get records up to ID 6.

So, these were the categories and types of commands in SQL Server with which you can play with the
data.

-------End of the document-------i

89
 Thank you

Contact
Name: Diwakar Singh
Email: info.bahelpline@gmail.com
Phone: +91 8093744952, +91 8169048056

90