DAY TO DAY RESPONSIBILITIES OF A BA

Table of Contents
VARIATION 1........................................................................................................................................................ 1
VARIATION 2........................................................................................................................................................ 3
BA LIFE CYCLE....................................................................................................................................................... 4

Variation 1
I have been involved in entire BA lifecycle throughout my career. And almost every project of mine involved these Major
activities
1. In every project I began my work with scope identification, and that is to understand what exactly what the project
was about. For which I went through various documents such as Project Charter, RFP, RFI, existing project documents,
standard operating procedures (sop) and any other document available
2. After this I was involved in Stakeholder analysis, where I was trying to document by whome and who would be
affected by this project. I build stakeholder register and when needed applied RACI matrix
3. After the initial preparation of BA was done, I started gathering requirements. I speak to various kinds of SH mainly
business users and end users to understand their requirements
a. I prefer going through interviews, so that I could get or elicit as much as information I can possibility.
b. But in certain cases, I had to use other techniques like JAD, prototype, Document Analysis, Observations,
Questionnaire, Survey, Brainstorming and benchmark analysis
4. Once the requirements were gathered, I moved to analysis of these requirements using two major technique
a. First, Gap analysis, so that I could understand discrepancies between as is and to be workflows and process
flow
b. Second, Decomposition or breaking down of application into multiple functions, modules so that I could
understand if I gathered all the requirements in the right way, if not, then I could go back to the end users
to get more clarifications or answers to the questions which I might have not got during the gathering
sessions
5. After analysis, I was more involved in documentation. Here documentations were completely different based on what
kind of methodology I was working on. I was involved at both Agile and Waterfall methodologies
a. When I worked on Agile, my major deliverables were user stories in product backlog and sprint backlog
along with any supporting documents
b. When I worked on Waterfall, I was involved in creating BRD. In this I clearly identified what were the
functional req, non functional req, data requirements, and transitional requirements including some
graphical user interface
c. In addition to these, I also created following using Lucid chart, MS visio, Draw.io
i. Flowcharts, BPMN, sequence diagrams
ii. Data Modelling (Logical & conceptual - DFD, ERD)
iii. Prototype, Wireframes
iv. Use case diagram, Class diagrams in UML
6. After these documentations were ready and approved, it was time to communicate these requirements. Where,
a. I had to translate and communicate this requirement to various technical SH such as design team, coding
team, testing team, delivery team
b. Make sure there is not obstacle while the team is developing
c. Again, there were different ways of communicating in different methodology
i. While in agile, I performed 4 ceremonies (Sprint planning, daily standup, Sprint review,
Retrospective)
ii. In waterfall, we facilitated kickoff meeting, walkthrough sessions, review sessions, UAT session,
sign off session etc.
7. After this my responsibilities were more revolving around supporting the
a. QA team in creation and execution of the test cases and management of defects
 DAY TO DAY RESPONSIBILITIES OF A BA
b. Design team: Data modelling, both conceptual and logical data models where I established entities and
identified the relationship between them. Also designed attributes. Basically full model so that this diagram
can be used by design team in quickly physical database objects
c. Training manuals
8. So these were some of my day to day responsibilities as a BA during my entire career.
 DAY TO DAY RESPONSIBILITIES OF A BA
Variation 2
There are various major areas in which ba adds value. He acts as a liaison between the project team and the client. Often
working together with the PM to get the project off the ground. The BA work depends on the project methodology but here a
short synopsis of what I do as a BA on an IT project:
https://www.quora.com/What-does-a-Business-Analyst-do-on-a-day-to-day-in-a-big-consulting-firm
1. Preparation:
a. Procedural analysis
i. New procedure, company rules, forms, admin requests, format of documentation
b. Scope identification
i. Project charter, RFP, RFI, existing apps, competitors software
ii. This is done when the PM has already drafted the project charter, or when the project charter has
been somewhat completed. It is important for the BA to gain a general understanding of what the
project is trying to accomplish, and the business landscape.
c. SH analysis
i. PM, HR, Project Charter, your own exp, org
ii. At the beginning of the project, upon meeting the client team, I sleuth around the client
organization, with an up to date organizational chart in my hand. I identify the main people and
areas in which the new system / project would be impacted. The Stakeholders Analysis is a
comprehensive list of people / business areas which are directly impacted, indirectly impacted,
and not impacted whatsoever. The project team would then rely on this in which to include in
requirements gathering, testing, training, and who to approach as the subject matter experts.
d. Facilitation
i. Meeting room, projector, agenda, reminders
2. Compilation of On Boarding documentation
a. A good BA will compile all relevant documentation from the project and business, and ideally put it on a
folder in the project shared drive (often SharePoint). The point is that anyone who newly comes onto the
project can go to this folder on their first day(s) and can independently ramp up knowledge on the project
and business landscape
3. Requirement Gathering
a. This is where the BA starts to shine. According to the Stakeholders Analysis built previously, the BA needs to
reach out to each of the folks and areas who are directly and indirectly impacted to gather business
requirements that the new system needs to handle.
b. My favorite of all is INTERVIEW, I like to talk to them face to face and understand their pain point, ask more
open and closed questions and judge what is that they have challenges and how are they trying to address
now and in future.
c. There are many techniques to use based on the situation here, if they are busy you can use questionnaire,
etc. etc.
4. Requirement Analysis
a. Gap analysis
b. Decomposition
5. Requirement Documentation
a. BRD
b. Agile
c. Supporting project documentation
i. Designing of data model
ii. Prep of test cases
iii. Use case diagram and use case models
iv. Training documents
6. Requirement Communication
a. Waterfall
b. Agile
7. Change Management
a. Waterfall
b. Agile
 DAY TO DAY RESPONSIBILITIES OF A BA

BA Life Cycle
1. Preparation
2. Requirement Gathering
3. Requirement Analysis
4. Requirement Documentation
5. Requirement Communication
6. Change Management

Waterfall Agile
1 Preparation • Procedural analysis
o New procedure, company rules, forms, admin requests,
format of documentation
• Scope identification
o Project charter, RFP, RFI, existing apps, competitors
software
• SH analysis
o PM, HR, Project Charter, your own exp, org
• Facilitation
o Meeting room, projector, agenda, reminders
2 Requirement Gathering Most time-consuming task: 70%
Direct questions from this subject
• Interview (Product Owner / BM / End User)
o Different questions to ask BM and different to End users
o PO/BM:
§ Introduce yourself
§ Ask as-is
§ Challenges faced
§ Ask future state
§ What benefits expected from new sys
§ # of group of users
§ # of end users
§ Who will give us the detailed req
§ What’s the budget
§ Est. deadline
§ Preferred technology
§ Preferred methodology
o End users:
§ User Stories
• Acceptance Criteria
• Ask UI – mock-up
• Priority
• Alternate flow
• Exceptional flow
• Questions / Survey
o If client is very busy and not giving us time
• Brainstorming
o Creative thinking to solve a problem or understand the
requirement
o If client says you find the requirement, BA sits with his BA
team and dev team to brain storm
o Then show the prototype to client
o Think of creative idea for the feature
• JAD
 DAY TO DAY RESPONSIBILITIES OF A BA
o Extension of brainstorming
o 1-2 weeeks full day
o Arrange this meeting only when brainstorming is not
working
• Prototyping
o Approval of requirements
o Or, show prototype and then gather requirements (ex.
Website templates)
• Job Shadowing
o Non cooperative end users
• RolePlay
o Sh says to replace his work by a bA for 2 days
• Trade Events
o Booth
o Event / poll
• Benchmark
• Document Analysis

3 Requirement Analysis WBS à Decomposition

• Helps in identifying if the requirements gathered are
complete…validating your requirements
GAP Analysis à
• Comparison between as-is and to-be requirements
• Mostly done with the help of process diagram (workflow etc.)
4 Requirement Documentation User stories is converted into BRD User stories à which is fed in product
and from BRD other documents are backlog with the help of product owner
generated such as FDD, etc etc and assistance of BA

Types of Docs: Type of Docs:

1. BRD 1. Product Backlog
2. FDD 2. Spring Backlog

USER OUTPUT PO + BA à decides what should go in

BA BRD product backlog
DESIGN T Arch diag
CODING T End Prod Dev team decides the priority, and
TESTER T Test case & urgency based on the user story
executing acceptance criteria.
Testing
DELIVERY T Deploy end Story point est:
product 1. US1: 1x, US2: 2x (where x is
any relative value of the
Adv: company)
1. Structured 2. Man hrs
2. Ownership
3. Less time consuming
Dis Adv:
1. No scope for change
2. Lot of miscommunication