The document discusses the role of a business analyst and key aspects of requirements gathering and software development processes. It defines what a business analyst does, including interacting with stakeholders to understand requirements and communicating them to technical teams. It also outlines different types of requirements, requirement elicitation techniques, stakeholders, and common software development lifecycles models like waterfall, RUP, agile scrum.

1. BUSINESS ANALYST
1

2. 2
Content
 Who is a Business Analyst?
 BA Role/ Competencies
 What are Requirements?
- Business Requirements
- Stakeholder Requirements
- Solution Requirements
- Transition Requirements`
 Requirement Elicitation Techniques
 Who are the Stakeholders?
- Project Stakeholders
- Business Stakeholders
- 3rd Party Stakeholders
 Business Process Modelling
 SDLC (Software Development Life-Cycle)
- Waterfall Model
- RUP (Rational Unified Process) Model
- Evolutionary – Spiral Model
- Agile – Scrum Model

3. Who is a Business Analyst?
• A business analyst is a person who interacts with
the client / stakeholders of the project to:
 Study Business / Business domain/ Organization &
its needs
 Asses Business Model to integrate with the
Technology
 Analyse documents to establish clients
requirements
• Business Analyst is bridge between client &
technical team to develop or modify the system
based on requirements
• BAs engage with business leaders and users to
understand how data-driven changes to process,
products, services, software and hardware can
improve efficiencies and add value.
3

4. • Interact with client to understand Business
Problems, needs & stakeholders
• Understand Product Feature / Domain
• Ownership of Requirements i.e. BA is
responsible to gather requirements from
client
• Document Requirements by using standards
set by IEEE (Institutions of Electrical &
Electronics Engineers), CMM-i (Capability
Maturity Model – Integrated) & Comp Specs
• Process Engineering / Re-engineering
• Model requirements of the client by using
UML (Unified Modelling Language)
• Communicate requirements to tech team via
Walkthrough Meetings or Knowledge Transfer
(KT) Sessions
BA Role / Competencies
• Track developments during Development
Stage through RTM (Requirement Traceability
Matrix – Generally the excel sheets)
• Handel Change Requests (CR)
• Facilitates User Acceptance Testing (UAT)
4

5. What are Requirements?
• Requirement is basically the need of the client. i.e. property that is essential for the
system to perform its functions.
• Requirements could be functions, constraints, or other elements that must be
present to meet the needs of the intended stakeholders.
• Types of Requirements:
 Business Requirements (BRD)
 Stakeholders Requirements (URD)
 Solution Requirements: (SRS)
- Functional Requirements (FS/ FRS)
- Non Functional Requirements (SSD)
 Transition Requirements
• As a Business Analyst we will gather business requirements & stakeholders
requirements to prepare functional requirements.
5

6. 1. Business Requirements
This is the initial phase of the project where the management of the client or owners describes the
need of the project, goals, objectives & the metrics that will be used to measure its success.
2. Stakeholder Requirements
These are the needs of a particular stakeholder or a class of stakeholders which describes how
the stakeholder will interact with the solution. Stakeholder requirements acts as the bridge
between business requirements and the various classes of the solution requirements.
4. Transition Requirements
These are time/ temporary requirements which describes capabilities of the solution in order to
facilitate transition from current state of enterprise to a desired future state.
3. Solution Requirements
These describes the
characteristics of the
solution that meets business
& stakeholders requirements.
Further classified as:
a. Functional Requirements
b. Non- Functional
Requirements
a. Functional Requirements
Functional Requirements describes the behaviour &
capabilities of the system / information that solution will
manage in terms of operation or actions or responses.
b. Non-Functional Requirements
These describe capabilities of the solution by the integration
of external peripheral equipment & quality requirements.
Ex. Integration of Card Reading device in Billing system
6

7. 7
Requirement Elicitation Techniques
• Business Analyst is responsible to gather Correct, Consistent & Complete (3 Cs’) requirements by
client interactions by elicitation techniques.
 Stakeholder Analysis:
 This identifies the users & stakeholders who may
influence or be impacted by the system
 Brainstorming:
 Generally used to identify possible solutions to
problems, and clarify details of opportunities from
group of people/ SMEs’.
 Document Analysis:
 Reviewing the documentation of an existing system
can help when creating AS–IS process document, as
well as driving gap analysis for scoping of migration
projects.
 Focus Group:
 A focus group is a gathering of people who are
representative of the users or customers of a product to
get feedback.
 Interface Analysis:
 Interfaces for a software product can be human or
machine. Integration with external systems and devices
is just another interface.
 Interview:
 Interviews of stakeholders and users are critical to
understand goals of the project.
 Observation:
 By observing users, an analyst can identify a process
flow, steps, pain points and opportunities for
improvement.
 Prototyping:
 Is to gather preliminary requirements that you use to
build an initial version of the solution
 Engineering/ Re-Engineering:
 When a migration project does not have access to
sufficient documentation of the existing system,
engineering will identify what the system does.

8. Who are the Stakeholders?
• Stakeholder is a person or a group of persons or an
organization that is directly or indirectly effected or
impacted the proposed solution.
• Types of Stakeholders:
 Project Stakeholders
 Business Stakeholders
 3rd Party Stakeholders
- External Consultants
- Negative Stakeholders
 Project Stakeholders
People inside the organization who provides
knowledge & expertise necessary to complete
technical & business constraints
 Business Analyst
 Project Manager
 Development Team
 Quality Assurance
 Testing
 Operations
 Business/ Subject
Matter Expert
 Business Data Modeller
 Graphics/ Aesthetics
Specialists
 Business Stakeholders
These are the people with interest in projects
outcome
 Project Manager
 Business Owner
 Business Sponsor
 SPOC (Single Point of
Contact)
 SME (Subject Matter
Expert)
 Ambassador User
 End User
 3rd Party Stakeholders
 External Consultants:
These are the people outside the organization who
provides knowledge & expertise necessary to
quantify technical & business constraints
 Negative Stakeholders:
These are the people or organizations who do not
want your project to succeed.
Ex. Hackers, Competitor, Political Parties, etc.
8

9. 9
Difference between BRD & SRS:
BRD SRS
It is a high level functional specification of the
software
It is a high level functional & technical
specification of the software
It is a formal document to describe
requirements provided by the client
It describes functional & non functional
requirements of the software to be developed
The Business Analyst creates it after their direct
interaction with the clients
The System Architect creates it as it needs
technical expertise.
It is derived based on the requirements and
client interaction
It is derived from the BRS

10. Business Process Modelling (BPM)
 Business Process is a collection of activities designed to produce specific output.
 Business Measures which cannot be measured/ matriculated are rendered in terms of Business Process
Model
 BPM helps to define:
 Goals in terms of Quality, Support & Profit
 Input
 User Resources
 Output based on Input
 Group of Activities
 Value to the end user
 Business Process Modelling can be done using following techniques:
1. Business Process Modelling Notations
2. UML (Unified Modelling Diagrams)
3. Flowcharts
4. Yourdon's Data Flow Diagrams (DFDs’)
5. Gantt Charts
6. PERT Diagrams
7. Functional Flow Back Diagrams
8. Petri & Colored Petri Nets (CPN)
10

11. 11
Software Development Life-Cycle:
 Is a process of planning, creating, testing & deployment of an information system to
produce high quality software's that reaches or exceeds clients expectations.
 Acronym: SDLC
 Also known as Application Development Life Cycle
 SDLC is divided into 6 phases:
1. Requirement Phase: Gather requirement from
Client in terms BRD (Business Requirement Doc) &
URD (User Requirement Doc)
2. Analysis Phase:
-Define & Document the product requirement
& get it approved from the client/ customer
via SRS (Software Requirement Specification
Documents)
- SRS consist of all the product requirements to
designed & developed during the project
3. Design Phase: Here requirements are translated into
designs. It has two steps:
a. High Level Design (HLD): Gives Architecture of the
software & is developed by Architects / Senior
Developers.
O/p: High Level Document
b. Low Level Design (LLD): Designed by senior
developers & describes how each functionality will
work.
O/p: Low Level Document
4. Development Phase: This is the phase where we
start building software & start writing code
O/p: Source Code Document & Developed Product
5. Testing Phase: Here Quality Analyst (QA) Test the
product
O/p: Quality Product & Testing Artefacts
6. Deployment & Maintenance Phase:

12. 12
Waterfall Model
 This is the most common & classic model followed in Software Life-Cycle.
 It is a linear sequential model where output of the first phase acts as the input of the next
phase.
 In this approach, the output of the initial phase has to be freezed before going to next
phase. i.e. Completion of initial stage is compulsory.
Stages of the
Waterfall Model
Resources Artefacts
Requirement
Gathering
BA, PM
BRD (Business
Requirement Doc)
Requirement
Analysis
BA, PM, Solution Architect,
Networking Architect,
Database Architect
FS/ FRS (Functional
Req. Spec), SSD
(Supplementary
Spec. Doc), SRS,
RTM
Design Phase
Tech Team, DB Arch, GUI
Designer
HDD, Sol Doc
Development Programmers/ Developers LDD, CDD
Testing Testers Test Doc, Appln.
Deployment Deployment Engineers

13. 13
Rational Unified Process (RUP):
 RUP is the iterative software development process created
by Rational Software Corporation (Acquired by IBM in 2003)
 3 Key Aspects of RUP are:
 Use Case Driven (Role i.e. who drive system):
Development proceeds through series of workflows derived
from Use Cases.
Terminologies:
- Users: A person who interacts with the system
- Use Case: Interaction between User & the system
- Use Case Model: Collection of Use Cases which
describes the complete functionality
 Architecture Centric (Work Product i.e. what is the function):
- is the complete design of the system with all
characteristics without too many details
 Task / Process (How it will function)
 Phases
Each iteration in RUP is divided into 4 phases:
1. Inception – Describes scope of the project & domain
2. Elaboration – Used during domain analysis & define
architecture.
3. Construction – Coding
4. Transition – System handover to client
Use Case
Iteration
Architecture
Influence
Goal
Define

14. 14
Spiral Model:
 It is a combination of Waterfall Model & Iterative Model. i.e.
Evolutionary Method
 Here each phase starts with Objective Determining & ends
with Reviewing
 More emphasis is given on Risk Analysis
 The spiral model has 4 phases:
1. Planning: Determines Objectives, Constraints & Alternatives
2. Risk Analysis: Evaluate Alternatives, Resolve Risks Attached
3. Engineering: Design, Code, Test, Integration, Acceptance &
Implementation
4. Evaluation:
 Advantages:
1. High Amount of Risk Analysis
2. Good for large & Mission Critical Projects
3. Software is produced in early life cycle.
 Disadvantages:
1. Costly
2. Risk Analysis requires Highly Specific Expertise
3. Projects success is highly dependent on risk analysis phase
4. Doesn’t work for small projects

15. 15
Scrum - Agile:
 Scrum is a Agile methodology where software is
delivered in packets to client in term of iterations
 Values of Agile:
 Individuals & Interactions over processes &
tools
 Working software over comprehensive
documentation
 Customer interactions over contract
negotiations
 Responding to change over following the
plan
 Product Backlog: Where all project requirements
are saved
 Sprint Planning: Divide entire project in sprints of 1-
4 weeks
 Sprint Backlog: Every sprint has its set of
requirements from product backlog
 At the end of every sprint potentially shippable product
is released to client for feedback
• Product Owner: Someone who represent client or
stakeholders
• Scrum Master: A person who manages the entire scrum