BA’s Flow of Work in a

Project

TrainSmart Academy

7021437151
Step 1: BA joins the project

• BA is selected by PM / Delivery Head to be a part of a project

• Bas are selected on basis of their experience and domain knowledge in a project
• BA is given existing documents by PM / Delivery Head / Sales. These may include RFP / Old BRDs / Old
FRDs
• BA may also start reading domain documents. (Technique used Document Analysis)
• BA enhances his knowledge by reading domain related material from Google / internal company
knowledge repository etc.

Note: Old BRDs and FRDs would be only for enhancement or re-engineering projects. For new projects only RFP may be
available
Step 2: Kick off Meeting

• BA, PM, PL Solution Architect all key members from vendors end have a project kick off meeting with
the client.
• From clients side generally Sponsor, Business, Point of contact attend this meeting. Mostly Money Men
from clients side.
• Kick off meeting is where the client explains first hand why is the software being created
• BA should make a note of all the stakeholders involved in the meeting.
• BA should ask questions around who would be the other stakeholders involved in elicitation.
• In this meeting BA should try to gather two important details
1. Why is there a need for the software?
2. Who all will be involved in elicitation?

Note: He will not get all details at this stage but just an overview. Trust me nothing valuable comes out of kick off
meeting. This is one of the many useless meeting that software professionals attend in their career. 

• BA should be able to explain to client how will he be doing requirements gathering

• (Technique – Stakeholder analysis – can use RACI / Onion Diagram / Stakeholder matrix.
 Step 3: Elicitation Meetings with Sponsor and Business stakeholders to understand Scope

• BA will have a few meetings with the clients to understand the following:

• Need for software

• Scope of software (Technique: Use Case Diagram / Context Diagram / Interface Analysis / Scope
Modelling)
• Come up with high level feature list.
• Vision of software
• As Is state (technique: Process Modelling / BPMN)
• To be state
• Change strategy (i.e. how to reach from AS IS – TO BE)

• Documents created – Vision Document / Business Case Documents / Change Strategy / Scope
Document / BRD

Note: these are all documents that CAN be created at this stage. This doesn’t mean that BA will create all of them.
Depending on company to company you may create any one of them or few of them.
 Step 4: Sign Off on Scope Document / BRD / Vision Document / Business Case

• BA will aim to get a sign off on the initial scope.

• To get sign off he may have a review session with the clients. (Technique – Review)
• Initial documents depicting Scope have been signed off
• BA by this stage has a more or less complete list of stakeholders who will be involved in elicitation. He
can create an importance / influence matrix at this stage.
• He will identify the elicitation meetings frequency and fixes days of elicitation with the client.
• He will finalize the FRD template with the client
• He will finalize the Change Request Process. Client identifies who will be responsible for approving CR
from their side.
Step 5: Requirements Elicitation

• BA starts the elicitation process. He may use multiple techniques like:

• Interviews (Video conferencing)

• Document analysis
• Questionnaire
• Brainstorming
• Focus groups
• Workshops
• Prototyping
• Mock ups / Wire frames
• Observation
• Mind Maps
• Functional decomposition (he may mentally break down full project into multiple requirements
that are co-related to each other)

Note: He uses whichever technique he feels is appropriate. It doesn’t mean he uses all of these at one time.
Few of them are used simultaneously. BA is also learning which techniques may work well . He is also
learning stakeholder management. Which stakeholders are good and which are pain in the - - - 
Step 6: Requirements Analysis

• Requirement Analysis is not really a separate phase. It just means he weeds out duplicate information,
incorrect information. In case information is incomplete he conducts further elicitation.
• New stakeholders may be identified in the elicitation meetings as well. Then BA needs to gather
requirements from them as well.
• He actually does Requirement Analysis along with elicitation.
• He tries to see if any requirement is not gathered or missing.
• He tries to find gaps in the requirements.
• If all requirements seems complete he moves on to the documentation part.

Note: Surprise BA doesn’t know but he has missed a few requirements . They will be caught by developers and testers
further down the SDLC. They may be caught by client before FRD sign off (oh that’s not good). They may even be caught
in the UAT (trust me if this happens BA faces music in his appraisals 

No BA is perfect they always miss a few details

Step 7: Requirements documentation

• BA starts the requirement documentation.

• He may use following to depict the requirements:

• FRD
• Use Cases and data elements
• Process Modelling (Process maps / BMPN / Cross functional flowcharts)
• Wire Frames are created either by UX UI person or BA himself
• Data dictionary
• Sequence Diagram
• Data Flow diagrams

• Note: this is an indicative list. Your company may have a different mode of gathering requirements.
Hence you need to attend a training program @ TrainSmart Academy to know all these tools.
Step 8: FRD Sign off

• BA will run around trying to catch the client to get FRD sign off. Client becomes always very busy
before the sign off . Client is never available to sign off  vagaries of the BA role.
• To do this arduous task he would have review meetings. (Technique: Review & Workshops)
• Change requests (CRs) can pop up anytime during elicitation, analysis, FRD documentation stage.
• BA will have to go through the change control board if it happens.
• BA will have to create CR documents if this happens.
• Sign off done.
• It does finally happen someday after a lot of following around with the client  BA is happy
Step 9: Support Design / Development

• The team moves into design phase.

• BA starts training the development team on domain / requirements
• BA has meetings with UX UI designers to help them complete the wire frames
• BA has meetings with solution architects / Project leads so they can understand requirements better to
design the High level and low level design documents.
• Missed or incorrect requirements may be pointed out by UX UI Designers / solution architects / Project
leads.
• In this case BA will again go back to client for further elicitation meetings as and when needed
Step 10: Development starts

• Now the development of software has started. TL / PL has assigned work to developers.
• BA supports all development team’s queries.
• BA may have individual one on one sessions with each developer explaining him the requirements that
he is supposed to code.
• Missed requirements pointed out by development team are clarified from client
• Client queries on development are clarified by BA by taking help from development team members
• BA starts preparing functional test cases.
Step 11: Testing starts

• Now the testing of software has started.

• BA does functional testing.
• BA does UI Testing – checks look and feel of software is fine.
• Manual testers do functional testing
• Automated testers do automation testing
• Bugs are raised
• Once developers fixes the bugs BA needs to retest the system along with the testers.
Step 12: UAT Testing starts

• Hey we have solved all the bugs and submit the software to client for UAT
• BA may or may not be a part of UAT. Depends on organization to organization.
• He handles client queries at this stage.
Step 13: Training of client

• BA may be involved in creating user manuals.

• Technical writers are supposed to create user manuals. But BAs are very skilful. In absence of technical
writers they take on this task and create a user manuals.
• These manuals are distributed to the client.
• Client will need training on the software.
• BAs are multi purpose resources they start training the client in how to use the software.
• Client learns how to use to software project is coming to an end.
• Again client may have CRs at this stage. BA creates relevant CR documents.
• BA starts asking for a release from this project.

Note: at different times of the project BA trains different people. At the start solution architect / PL in understanding
requirements to create a High level design. In middle of the project he trains developers and testers in the domain and
requirements and at the end of the project he trains the client on how to use the software. No wonder I became a trainer

Step 14: software goes live

• Client starts using the software.

• BA is released from the project.
• BA is looking for the next big project that will escalate his career.
• And he is assigned in some new exciting project
• Go back to step 1 and start the BA journey again
Step 15: BA’s Life Cycle

• And someday he has done enough business analysis maybe 8-10 years down the line.
• He then decides to exit the BA role.
• This will be the end of his BA journey.
• Adios to BA role
• He starts in a new role.

Good luck to all you budding BAs

THANK YOU!

TrainSmart Academy

7021437151