Business analyst training at united global soft call: +1 201-710-8393 India: +91-8099902123

1. Business Analysis Training Brochure
Business Analyst

2. Duration
 Normal course
 25 hours /one month/daily one hour
 Fast track course
 25hours/15days/daily two hours/

3. DURATION

4. Tools
 Ms visio --- UML DIAGRAMS/DFD
 RATIONAL ROSE---UML DIAGRAMS/DFD
 MS WORD—BRD/SRS/DRD/FRD document
preparations
 ERD/TEST CASE PREPARATION

5. TEMPLATES
 BRD TEMPLATE
 FRD TEMPLATE
 DRD TEMPLATE
 SRS TEMPALTE
 TEST CASE TEMPLATE
 USE CASE DOCUMENT TEMPLATE
 ALL UML DIAGRAMS
TRAINING/TEMPALTES

6. BA COURSE
1. RESUMES
2. RESUME TIPS
3. RESUME DEVELOPMENTS
4. PROJECTS FOR RESUMES TO INCLUDE
5. INTERVIEW QUESTIONS
6. INTERVIEW TIPS
7. CASE STUDIES
8. LIVE PROJECTS IN ALL DOMAINS
9. TIPS TO WORK AS BA IN IT COMPANY

8. BUSINESS ANALYST OPENING

9. Business Analyst Training Intro
Presented by
Chandra, Sr.Business Analyst

10. Agenda
 Business Analysis Definition
 Business Analyst Skills and Roles & Responsibilities.
 Fundamentals of Requirements Elicitation
 BA Training Course Structure and Placement Assistance
 Questions

11. Business Analysis Definition
IIBA defines Business analysis as ―the set of tasks, knowledge, and techniques
required to identify business needs and determine solutions to business
problems.
IIBA ( International Institute of Business Analysis)
Solutions often include a systems development component, but
may also consist of process improvement or organizational change.‖Thus,
business analysts are often the liaisons between business and solution
development (oftentimes IT), can-vassing the enterprise to understand business
needs, issues and opportunities in order to recommend solutions that address
those needs most effectively and efficiently.

13. Business Analyst Skills

14. …who follow a chain of reasoning that leads from problem definition to implemented solutions
…and maintaining the integrity and coherence of the chain is the work of the Business Analyst.
Owners
defines measures of success and £targets
£Money!
…Business Analysts confirm & document
Strategists
determine the strategy to hit the targets
…Business Analysts do market research, create strategy, challenge & document
Sponsors
establish a Programme that delivers the strategy
…Business Analysts document Programme
TOR and build the Business Case (TOR :
Terms of Reference) Programme Managers
Institute Projectsthat implement the programme
…Business Analysts document the Project TOR
Business analysts
specify requirements for Projects in the Business Model
Systems Analysts
IT design solutionthat satisfies the requirements
…Business Analysts protect requirements & document compromisesbuild solution
…Business Analysts protect requirements & document compromises IT and the Business test solution …Business Analysts
ensure tested against requirements
Project managers
Implement solution
Users
Accept solution
…Business Analysts help with
-£MEASURING £BENEFITS £REALISATION
…Business Analysts help with
-Process and data migration
-Cutover planning
-Rollout
POST-IMPLEMENTATION
Business Analysts feed back to the Owner how well their
measure of success has been achieved
Scope Of The Business Analyst Role Vs SDLC

15. Answer Following Question
When ? : Analysis
What ? : BRS
Why ? : Tools & Tech..
Who? : SMEs,Rteam,TSMEs
How? : Process … 3D Method

18. Business Analysis –
• its not rocket science
• it is science (not a *dark+ art)
• science has the scientific method
• Business Analysis has many structured methods
All structured methods must be fundamentally the same as they
must all
•analyze problems
•analyze the scope of the solution
•analyze functional and non-functional requirements
•manage requirements in to design & delivery

19. What is Business Analyst
IIBA Definition of a Business Analyst:
Business Analysts are responsible for identifying business needs.
The Business Analyst is responsible for requirements development and
requirements management. Specifically, the Business Analyst elicits, analyzes,
validates and documents business, organizational and/or operational
requirements. Solutions are not predetermined by the Business Analyst, but are
driven solely by the requirements of the business. Solutions often include a
systems development component, but may also consist of process improvement
or organizational change.
The Business Analyst is a key facilitator within an organization, acting as a bridge
between the client, stakeholders and the solution team.
Business Analysis is distinct from financial analysis, project management, quality
assurance, organizational development, testing, training and documentation
development.
International Institute for Business Analysis
http://www.iiba.com

20. • Usually assigned to the project after it has started
• Responsible for bridging the gap between the Business and IT
• Learn the business inside and out
• Essentially the architect of effective business systems
• Job title, definition and responsibilities viewed inconsistently across
the industry
Business
Technology

21. Business Analyst Working Domains
 Banking & financial
 Insurance
 Health care
 HRM
 Telecom
 Airline
 Marketing or manufacturing
BA is going to work on different domains depends upon
company projects
insurance
telecom
banking
healthcare
HRM

22. EXAMPLE
CEAT Company is a client
Business Analyst
client
It company
IBM
CEAT
GATHERING REQUIREMENTS
Design developers
Testing engineers

23. BUSINESS ANALYST
BA/BRD
PROJECT MANAGER
PRODUCT MANAGER/INTERNAL REQUIREMENTS
EXTERNAL CLIENTS
PRODUCT BASED COMPANY
CLIENTS EXTERNAL REQUIREMENTS

24. CLIENTS MEETING
BDM SALES
CLIENT
S
SALES DICUSSION ON PROJECT
,TECHNOLOGIES,ABOUT OUR COMPANY
STRUCTURE AND WORK OUTLETS WITH
CLIENTS
FINALLY CLIENTS WANTS TO MAKE KICK-OFF
MEETING WITH OUR COMPANY LEADS TO
DICUSS ABOUT PROJECT

25. HOW THE PROJECTS ARE COMING
TO ITCOMPANY
BDM
CLIENT/STAKE
HOLDERS
(CEAT)
INTRANET HOME PAGE
TECHNOLOGY---SHARE POINT
---- JAVA
---- .NET
DATA STORAGE---- 3RD
PARTY--SAP
IT COMPANY/
IBM
PRE SALES
POST SALES---PROJECTS
BRINGING PROJECTS TO IT COMPANY
EXPLAIN THE STRUCTURE AND KNWOLEGE OF
OUR COMPANY
RFI
RFQ
RFP

26.  BDM AFTER FINISHING THE
COMMUNICATION WITH CLIENTS
REGARDING THE PROJECTS WHEN
THE CLIENT LOOKING FOR PROJECT
DEVELOPMENT
 NOW BEFORE STARTING OF
DEVELOPMENT OF SYSTEM THE
CLENT WANT TO MAKE KICK OFF
MEETING WITH OUR COMPANY

27. KICK OFF MEETING
 The Kickoff Meeting is the first meeting with the project team and the client
of the project. This meeting would follow definition of the base elements
for the project and other project planning activities. This meeting
introduces the members of the project team and the client and provides
the opportunity to discuss the role of each team member. Other base
elements in the project that involve the client may also be discussed at this
meeting (Schedule, Status Reporting, etc.).
 The basic format of a kickoff meeting includes the roles of and
contributions from the stakeholders. It also mentions the risks and issues
involved, particularly those that may affect project schedules and lead to
decreased customer satisfaction. This is the point at which help needed
from stakeholders is explicitly mentioned.
 If there are any new team members, the process to be followed is
explained so as to maintain quality standards of the organization. Clarity is
given by the project lead if there exists any ambiguity in the process
implementations....

28.  There is a special discussion on the legalities involved in the project.
For example, the design team interacting with the testing team may
want a car to be tested on city roads. If the legal permissions are not
mentioned by the concerned stakeholder during kickoff, the test may
get modified later to comply with local traffic laws (this causes
unplanned delay in project implementation). So, it was best to have
a discussion about it in the kickoff meeting and follow it up
separately, than to assume stuff and later be forced to replan test
procedures.
 The kickoff meeting is an enthusiasm-generator for the customer
and displays a full summary of the project so far. By displaying a
thorough knowledge of the goal and steps on how to reach it,
confidence is put in the customer

29. WHO IS GOING INVOLVE IN KICK OFF MEETING
KICK OFF MEETING
IT COMPANY CLIENTS SIDE
1.PROJECT MANAGER
2.BUSINESS ANALYST
3.BDM
4.TECHNICAL MANAGER
5.DELIVERY MANAGER
KEY STAKEHOLDERS
Subject matter Experts
Technical subject
Matter Experts
Head of Departments
MEETING
DISCUSSION REGARDING THE
SYSTEM BUSINESS NEEDS

30. Project manager
 Presentation regarding the project
development in means of
 1.cost
 2.duration
 3.quality
 4.risk
 5.development process

31. Project plan/scope/charter
ANALYSIS BA 1-15 DAYS 60,000
DESIGN DESIGNERS 15—35 DAYS 1LAKHS
CODING PROGRAMMERS 35---50DAYS XXXX
TESTING TEST ENGINERS 50—65 DAYS XXXX
DEPLOYMENT DEPLOY 65---90DAYS XXXXXX

32. KICK OFF MEETING
Kick- Off
Analyze
Design
Stabilize
UAT
Implement
Build

33. BA INVOLVES IN KICK OFF
 BA INVOLVES IN KICK OFF MEETING
 DEPENDS UPON THE COMPANY
BUSINESS ANALYST
KICK OFF MEETING
ACTION EVENTS
ACTION REQUIREMENTS
-End1
*
-End2
*
-End3
*
-End4
*
-End7
*
-End8
*
-End9
*
-End10
*

34. ACTION EVENTS
 WHAT EVER WE DICUSSED IN KICK OFF
MEETING REGARDING THE PROJECT
ISSUES
 ACTION EVENTS ARE THE WHAT EVER
RESPONSE IS COMING FROM THE
CLIENTS REAGRDING THE QUERY IN
PROJECT SCOPE
 EXAMPLE—IN COST OF PROJECT
 DEVELOPMENT OF
PROJECT

35.  ACTION COMING FROM THE STAKE
HOLDERS
 ACTION REQUIREMENTS ARE WHAT
EVER WE HAVE DICUSSED REGARDING
THE DEVELOPMENT OF CLINETS
PROJECT SCOPE.
 WE ARE GATHERING ALL THE
REQUIREMENTS

36. SUCCESS COMPLIATION OF KICK OFF MEETING
 KICK OFF MEETING FINISHED
SUCESSFULLY.
 CLIENT PREPARES THEIR BUSINESS
PROPOSAL AND SEND TO IT COMPANY
PM
 PM PREPARES THE BUSINESS
PROPSALS FOR CLIENTS PROJECT
DEVELOPMET

37.  PROJECT MANAGER/LEAD BA PREPARES
PROJECT MANAGER
PREPARES THE RF
REQUEST FOR
PROPOSAL
REQUEST FOR
QUOTATION
REQUEST FOR
INFORMATION
BUSINESS PROPOSAL
-End1
*
-End2
*
-End3*
-End4*
-End5
*
-End6
*
-End7
*
-End8
*
-End9*
-End10*
-End11
*
-End12
*
-End13
*
-End14
*
-End15
*
-End16
*

38. BUSINESS PROPOSAL
 BA HAS TO GO THROUGH WITH
BUSINESS PROPSAL
 GATHER INTERNAL REQUIREMENTS
 BEFORE STARTING REQUIREMENT
GATHERING FROM CLIENTS OR
INTERACTION WITH CLIENTS
 BA HAS DO SURVEYS REGARDING THE
CLIENTS COMPANY

39.  SURVEYS
 PRIMARY DATA COLLECTION
 1.ONLINE MARKET RESARCH
 2.FACE TO FACE INTERACTION WITH CLIENTS
 SECONDARY DATA COLLECTION
 1.HISTORICAL DATA
 2.PREVIOUS DOCUMENTS
 THESE SURVEYS FOR INTERNAL REQUIREMEMNTS
FEEDBACK ONLY.

40. PROJECT MANAGER
BUSINESS ANALYST TEAM MEMBERS PROGRAM MANAGER
CLIENTS INTERACTION
REQUIREMENTS
BA
SURVEYS
BEFORE INTERACTING
WITH CLIENTS FOR
REQUIREMENTS
PRIMARY
DATA
COLLECTION
YES
SECONDARY
DATA
COLLECTION
NO
IN ORDER TO UNDERSTAND STRUCTURE OF
CLIENTS COMPANY BEFORE GATHERING
REQUIREMENTS

41. AS-IS AND TO-BE
 As-Is study means studying the business process of the
 client. The BUSINESS ANALYST goes to the client's place
and gets this document. Once the As is document is ready
the
 consultant based on the client's requirement prepares the
 To-Be document which means how the business of the
client
 must be. This whole process takes place in the Second
phase
 of ASAP which is the Blueprint Phase.

42. Business analyst topics
1. Roles of BA
2. SDLC METHODS
ANALYSIS
DESIGN
CODING
TESTING
IMPLEMENTATION
BA

43.  BA ROLE
CLEN
TS
IT
COMANY
CLIENTS
WANT TO
MAKE AN
INTRANET
ON
SHAREPOI
NT
DESIGNE
RS
DEVELOP
ERS
BA

44. BA Role - The Past
Elicitation AnalysisElicitation Specification
Validation and
Documentation
Requirements Phase

45. BA Role – The Future
A Critical Role Throughout the Project Life Cycle
Enterprise
Analysis
Strategic
Planning
Requirements Design
Construction Test Deliver
Operations
and
Maintenance
Deactivate
Study Period Implementation Period
Implementation Period (continued) Operations Period

46. Business Analyst Role - Study Period
• The executive team cannot affect the transition to a strategy-focused organization
alone
• Information, process, tools and facilitation are provided by the Business Analyst to
enable the organization to shift focus and activities to be strategy driven
• Conduct analysis to inform the portfolio planning team
1. Create and maintain the business architecture
2. Conduct feasibility studies to determine optimal solution
3. Prepare the business case

47. 1. Planning Business Analysis
activities
2. Requirements elicitation
3. Requirements analysis
4. Requirements specification5. Requirements validation &
verification
6. Requirements allocation and
tracing
7. Requirements change
management
8. Organizational change
management
Business Analyst Role - Implementation Period

48. SDLC METHODS
ANALYSIS
DESIGN
PROGRAM
CONSTRUCTION
TESTING
IMPLEMENTATION

49. WHY DOES A PROJECT NEED BA AND PM
Project management
Office
Program
manager
PM handles multiple projects
Project
Manager
PM handles single or more projects
BA
TECHNICAL
LEAD
TEST
LEAD

50. MOSCOW TECHNIQUE
 MOSCOW
 MUST SHOULD COULD WOULD
 HOW TO MAP REQUIREMENTS FROM
CLIENTS AND PRIORTY FOR EACH
REQUIREMENTS

52.  MoSCoW is a prioritization technique used in business
analysis and software development to reach a common
understanding with stakeholders on the importance they
place on the delivery of each requirement - also known as
Moscow prioritization or Moscow analysis.
 According to A Guide to the Business Analysis Body of
Knowledge, version 2.0[1], section 6.1.5.2, the Moscow
categories are as follows:
 M - MUST: Describes a requirement that must be satisfied
in the final solution for the solution to be considered a
success.
 S - SHOULD: Represents a high-priority item that should
be included in the solution if it is possible. This is often a
critical requirement but one which can be satisfied in other
ways if strictly necessary.
 C - COULD: Describes a requirement which is considered
desirable but not necessary. This will be included if time
and resources permit.
 W - WON'T: Represents a requirement that stakeholders
have agreed will not be implemented in a given release,
but may be considered for the future.

53. ZACHMAN METHOD
 5W+1H
 WHY
 WHEN
 WHERE HOW
 WHAT
 WHO

55. 3D FRAME WORK FOR REQUIREMENT
GATHERING
 3D
DISCOVER DISCRIEBING DOCUMENT

56. 3D MODEL FOR REQUIREMENTS
BRD
FRD DRD

57. BRD
 BRD- BUSINESS REQUIREMENT
DOCUMENT
 FRD- FUNCTIONAL
REQUIREMENTDOCUMENT
 SRS -SYSTEM REQUIREMENT
DOCUMENT
 DRD -DATA REQUIREMENT DOCUMENT
 BRD SHOULD BE COVERTED INTO

58. BRD/FRD/DRD
CAPTURING
CUSTOMER
DETAILS
BRD
HOW YOU WANT
SEARCH
1. CAPTURING
CUSTOMER
DETAILS
USING
REGISTRATIO
N
2. STORE
CUSTOMER
DETAILS
3. AVAILABLE TO
CUSTOMER
FRD
WHAT KIND OF
REQUIREMENTS
NAME
AGE
SEX
PROFILE
DRD

59. BRD STRUCTURE HOW TO
PREPARE
 EVERY COMPANY HAS OWN
STANDARDED TEMPLATE
 BRD
1.INTRODUCTION
OVERVIEW
PROJECT BACKGROUND
KEY STACKHOLDERS
2.SCOPE
INSCOPE
OUTSCOPE
3.FUNCTIONAL REQUIREMENTS
USE CASES DIAGRAMS
USE CASE DOCUMENT
FUNCTIONAL REQUIREMENTS
4.NON FUNCTIONAL REQUIREMENTS
QUALITY
PERFORMANCE
AASURANCE
HARDWARE
SOFTWARE
5.DRD
6.RTM

60. REVERSE ENGINEERING FOR
REQUIRMENTS
REQUIREMENTS
VALIDATION ELICITATIO
N
DOCUMEN
T
MANAGE

61. SDLC MODELS
WATER FALL MODEL
SPIRAL MODEL
RAD MODEL(RAPID APPLICATION
DEVELOPMENT)
RUP MODEL RATIONAL UNIFIED
PROCESS
V- SHAPED MODEL
INCREMENTAL MODEL
AGILE WITH SCRUM
AGILE WITH XP

62. RTM
 REUIREMENT TRACIBLITY MATRIX
REQ.NO FEATURE COMPONENT CATEGORY TESTCASE

63. REQUIREMENT ELICITRATION
PROCESS
1. INTERVIEWING & QUESTIONAIRE
2. JAD/WORKSHOPS/FOCUSGROUP
3. BRAINSTROMING
4. PROTOTYPE/STORY
BOARD/MARKUP/WIREFRAME
5. USE CASE MODEL
6. SURVEYS
7. REVERSE ENGINEERING
8. VIEWPOINT

64. USE CASE DIAGRAM
 EXAMPLE-- ATM CASH WITH DRAWN
VISIT ATM
USER
SELECTS
INSERT
CARD
SYSTEM
VALIDATES CARD
ENTER VALID PIN
SYSTEM
VALIDATES
SYSTEM OPENS
LIST OPTIONS

65. ANALYSIS
 STRUCTRAL ANALYSIS OOAD
 DFD UML
DIAGRAMS
 SFC
 HIPO
 STC
ANALYSIS

66. UML CLASS
OBJECT
PACKAGE
COMPOSITE
COMPONENT
DEPLOYMEN
T
STRUCTRAL
DIAGRAMS
UML
DIAGRAM
S
BEHAVIOURAL
DIAGRAMS
USECASE
DIAGRAMS
ACTIVITY
DIAGRAMS
STATE MACHINE
CHARTS
INTERACTION
DIAGRAMS
COMMUNICATION
SEQUENCE DIAGRAMS
TIMING DIAGRAMS
INTERACTION
DIAGRAMS
DESIGING
ANALYSIS
DEVELOPME
NT
ANALY
SIS

67. TESTING
 UNIT
 INTEGRATION TEST
 SYSTEM TESTING
 UAT
MANUAL AUTOMATIC

68. MANUAL
LLD
UI
U
2
U
N
PROGRAMMERS
SENIOR TEST
INTEGRATIO
N
SYSTEM
UAT
HLLD
BRD/FRD BRD/FRD
1.TOP-BOTTOM
2.BOTTOM-TOP
3.SANDWICH
1.FUNCTIONAL
2.USABILTY
3.PERFORMANCE
4.SECURITY
1.ALPHA
2.BETA

69. STLC
 SOFWARE TEST LIFE CYCLE
 TEST PLAN
 TEST DESIGN
 TEST EXCUTION
 BUG REPORT
 RESULT ANALYSIS
 TEST SUMMARY

70. DATA MODELING
 CONCEPTUAL DESIGN
 LOGICAL
 PHYHICAL

71. PROJECT MANAGEMENT
SYSTEM
 PROJECT MANAGEM ENT PHASES
1. INIATION
2. PLANNING
3. EXECUTION
4. MONITORING/CONTROLLI
NG
5. CLOSING
1.PROJECT INTEGRATION
2.PROJECT SCOPE
3.PROJECT TIME
4.PROJECT COST
5.PROJECT QUALITY
6.PROJECT HR
7.PROJECT RISK
8.PROJECT
COMMUNICATION
9.PROJECT
PROCUREMENT
10.SOCIAL &
PROFESSIONAL
KNOWLEDGE AREAS

72. ALL THE BEST FOR THE
FUTURE
 WELCOME AS BUSINESS ANALYSTS
THANKS
COURSE DURATION --27HOURS