Tell Me About Yourself

Well, i am Pooja Soneja. I have 3 + years of experience as Business Analyst and Quality Analyst,
have been working as a BA since 1 year. I have strong background in P&C Insurance domain.

The kind of projects that have worked on have varied right from creating AS IS model at the very
start of the project to complete requirement gathering processes using various techniques. I
have also handled impact analysis and prioritization of change requests in the existing solution
project.

The documents that I have experience in modelling are BRD, FSD, Requirement Traceability
Matrix, etc. Apart from the documentations, I have experience in creating User Stories with
defined Acceptance criteria for Scrum Team's reference.

I have been actively involved in assisting the UAT Team in creating test cases as well as executing
them, troubleshooting their issues as well as proactively resolving them with the help of the
Implementation team.

I consider myself a great communicator as communication is not only limited to the documents
you create but it helps foster team and stakeholder collaboration. Communication has helped
me to single-handedly play a crucial role to interface between the Business and Development
Team and bridging the gap between them.

Apart from Competencies and soft skills, I am proficient in technical skills like SQL Server queries,
REST architecture of API and executing test scripts using JavaScript.

I am a hard-working professional who tries to deliver detail-oriented, quality-driven and most

importantly value-driven work.

Why do you want to be a BA?

Well, i love technical aspects of the application, meaning how the data flows within and between
the applications but more than that I love to talk Business. As much as I am into visualizing the
Business scenarios, I am also passionate about representing solution to the interested parties.

What are your Strengths?

I would like to consider my greatest strengths are Gathering, analyzing and managing
information and being polite and professional in the workplace.

I love to work with data and analyze them to figure out the patterns and defects. I have
experience in SQL Server and MS-Excel to analyze the data trends using SQL queries and Excel
functions.
Being polite and professional in the workplace has helped me to a great extent to collaborate
with the stakeholders. I am a go-to person if any help or clarification is required by the Business
or Development Team. I have been told that I am friendly as well as professional.

What are your weaknesses?

At times I am overly self-critical about my work and think that I could have done something more
in my project despite making the project live. I am have been trying to thwart this feeling by
meticulously analyzing it, making points on what I could have done better and nonetheless, still
celebrating my achievements.

Tell me about your Current Project

I would like to take my present project as an example as by far this has been the most
challenging experience for me.

The project that i am working on is an integration of 3 applications along with some reportings.
The objective of this project is to completely eliminate the manual steps of Operations team in
their day-to-day tasks. Besides, the operations team had to toggle between four different
applications and perform some manual steps. The objective of this project was to reduce
submission processing time from 45 minutes to around 20 minutes. This would not only increase
throughput but reduce FTEs as well. (Full Time Employees)

To define scope of the project in the beginning, I conducted Interface Analysis to determine the
integrated applications, Document Analysis to read Business Rules and requirements of those
applications, created Use Case diagram and Context diagram to define proper In-Scope items. I
modelled AS-IS state and To BE state with the help of the stakeholders involved and conducted
Gap analysis. I presented these techniques in the BRD document and got them signed-off by the
Project Sponsor and the stakeholders who gave high level requirements.

This BRD proved to be a guideline for the requirement elicitation processes. The techniques I
used in the elicitation process were Observation, Interviews and JAD sessions. I wrote textual use
cases and created wireframes to present them in the Functional Specification Document and
also clarified the technical team's queries as they developed and tested the modules.

The project was a bit challenging because I had to undergo training of 4 different applications
and understand their usage in the operation team's life. Also, as the application was coming to
life sprint by sprint, the end users' expectations were changing as they had different user
experience in the original applications the APIs of which were now integrated in this application.
Gradually, the users got acclimatized and even commented that "One application is more
awesome than all the individual applications"

How did you kick start your project?

There was a Project kick-off meeting wherein the Project Sponsor and the relevant Business
people along with Project Manager, Managers from Operations team and I were present. The
Project Sponsor started by stating the purpose of the application. The Operations Team also
pitched in by telling us the problems they were facing in their current process. I jotted down the
names of all the stakeholders that were present in the kick-off meeting. I noted down two key
pointers from that meeting - Purpose of the application and stakeholders who will be involved in
the Requirement elicitation.

We had a series of few more meetings with the same group wherein I determined - Vision of
Software, Need for software, Scope of Software, AS-IS state, TO-BE state. I used techniques -
RACI matrix and Importance/Influence matrix throughout the Project for Stakeholder
management. Interface Analysis, Use Case diagram and Context Diagram to determine scope of
the application.

I delivered BRD after this analysis and got it signed-off first by the Operations team and then by
Project Sponsor. To get the sign-off, I conducted a Review session with them. After BRD
finalization, I informed them about elicitation meetings frequency and the techniques that I
would be using for Requirement Elicitation (Observation, Interviews and JAD session)

Functionalities of the Project

As I mentioned before, the said application is actually an integration of 3 applications. It

consumes their APIs in order to perform end-to-end tasks of the Operation Team. A scheduler is
run daily which loads or picks emails of NA Casualty from the Ops Team common mailbox and
triggers API of the first application. The first application that comes into play is based on
Machine Learning. It begins by extracting relevant information from the Emails that Operations
Team receives from UW/Broker daily. The extracted fields range from Broker Name,Broker
Contact Person Name, Broker Contact Person Email ID to Underwriter, Insured and applies some
rules for Effective Date, Expiry Date etc. and sends this information using POST API to my
application which populates this information on the UI. About 20 fields constitute the Home
Page. The Operations Team members, in real-time get access to the Emails of NA-Casualty only in
the application. The email once assigned to a member cannot be seen by other members. It then
becomes a task allocation tool. The fields are then verified by the Ops team, they verify whether
fields are populated correctly and then validate whether this Insured information is already
existing in their Policy Administration system. This validation part is taken care by the second
application using their APIs. This validation is based on multiple Business rules. It determines
whether the information received is a new submission, duplicate submission, or perhaps a
renewal. Basis this validation result, the RPA BOT runs to make the submission or edit the
renewal information in the Policy Administration tool, called DuckCreek. This marks the whole
submission process of the Submission Team. My application provides reporting mechanism and
dashboards as well through which the admin user can view the allocated tasks and actions
performed on them.

Use Case Names in the Project

1. Activate Scheduler
2. Load Emails on Home Page

3. Send for Clearance

4. Perform Action on Email

5. Create User, Update User

6. Create Underwriter, Update Underwriter

7. Create Broker/Broker Contact Person, Update Broker/Broker Contact Person

8. View Report

9. View Dashboard

10. View User Allocation

Actors in the Project

1. Admin

2. Processor

3. Direct Producer

4. Quality Control

How difficult it is to communicate with the Development Team?

If it comes to communication with the Development Team, I would rate myself 7 out of 10. I give
myself good 7 points because I understand the database structure, the log files, APIs, basic HTTP
Methods and OOP Concepts. The remaining 3 points account for the technical constraints that I
sometimes fail to predict. For instance, when the end users wanted to have refined sorting
criteria on the reporting screen. I had suggested that we give sorting feature on all the columns
in the report. After sorting on one column, a user would be able to apply sorting on other
column as well which came across as a technical constraint from the Development Team who
countered that it would break the page. So the final solution came out to be sorting on one
column at a time.

Was there a time when the Business Team and you were in contradiction/conflict?

There was one instance when I was gathering requirements from the Operations team about
the Reports that they wanted to see in their application. I had created wireframes using
Blasamiq and I was presenting to them. I had drawn two 'Submission Number' fields which
Business Team thought was redundant. But I deliberately put those two fields there because
Submission Number was actually getting saved in multiple DB tables. in One table it was getting
generated by coding and rules and in other DB table, it was via manual entry through UI. By
Busines Process, these two submission numbers should be same but considering human error
while typing or for whatever reason, this could have created conflict in data integrity.

I explained my insights to them in as simple language as possible and explained one more
additional scenario wherein the submission number wont be generated automatically and they
will have to make manual entry in that case.

The Operations Team agreed with me then and even gave me praises for the scenario that they
couldnt think of but argued that the label of one of the fields be changed

How do you deal with a difficult stakeholder?

The UAT of this project went on for approximately 5 months and yet I observed and even heard
from the Development Team that Operations Team was still not aware of how the application
was working. They were aware only about the basic functionality but when it came to exploring
more, they were losing track. Besides, when the project was about to go Live and we were all
awaiting their sign-off, they reported bugs from initial sprints which were not actually bugs but
complete requirement change. I gradually realized that they had negative view about this project
and they were trying their best to prevent this project from going Live.

So I borrowed few minutes time of the Manager who was leading the UAT instead of setting up
the meeting. I asked her whether UAT was facing any challenges because by so far we had not
received any defect that would prevent the project from going Live and if there was any help she
required from me. She said UAT was going smoothly. And then I told her how her UAT team was
performing work.

Then she pitched in that she had a lot of work pressure, she and the team had to do their daily
ops work along with testing the application as the whole project team awaited their feedback
daily. And if by any chance, any bug was leaked to the production, they would be blamed for
missing it.

I told her diligently that i fully trust my testing team and even she had reviewed their exhaustive
test cases. Besides, UAT couldn't have found any major defect so far in 5 months. So she should
completely respect our efforts and even she was part of our team as we were burning both ends
of the candles to meet the timelines for them. I also added that she doesn't have to think like a
tester but like Business team because their business cases were getting accomplished anyway.

She then agreed to test only her business scenarios and got the positive view to make this
project live.
How do you resolve opinions/requirements of conflicting stakeholders?

To resolve opinions of conflicting stakeholders, I validate whether their statements traces back to
Business Need. For instance, the project that I was handling was an internal project. The
requirements were given by the Operations Team per se. During the requirement gathering
phase, we were discussing how reply emails were to be handled for the same submission
account. One Ops Team member wanted only the latest reply email to be catered whereas other
member wanted all the emails within the chain mail to be handled. I knew for a fact that the
latest reply email didn’t necessarily contain information that Ops required. Seldom the
information was in the email previous to reply email. But I also asked the end user who wanted
all mails to be picked within ‘Reply’ as to why he wanted all emails to be picked, to which he
answered that information could be in any mail and they could verify manually whether
submission had been prepared for that account. This statement contradicted with the Business
Need which dictated that application were to handle only unique emails and the objective of
100% automation wouldn’t have fulfilled if we allowed Business Team to verify that manually.

Can you describe a time when you had to steer a client toward a different course of action

than the one, they were set on taking? - same as above. I suggested that we go through Reply
emails of last 2 months to see the patterns. We could handle unique submission account if we
identified unique identifier.

**Give example of Combined Account Report**

What are your roles and responsibilities as a BA?

My Primary role as a BA is to help Business implement technology solutions by precisely
determining the requirements of a project, and communicating them clearly to the key
stakeholders. In doing so,I participate in the functional testing and UAT Testing to verify the
system.

My Core responsibilities include -

1. Understanding the requirements of the Business
2. Analyzing Information
3. Communicating with a broad range of people
4. Documenting the findings
5. Evaluating and implementing the finest solution

Questions to ask in the end of the interview

1. Will SQL be a core part of my duties or something I use occasionally?

2. What is the typical day of a BA in your organization?

3. The responsibilities the role will require

4. Any shared interests that came up during the course of the conversation

A major telecommunications giant posted a surprising net loss last quarter. Why? What can
the company do to improve its forecast?

The key with these is to ask as many questions as you can to understand the context. The
interviewer is expecting you to ask them questions; it's purposefully vague. So what kind of
context? Ask something like:

∙ What geographic market?

∙ Where there any new competitors or new competitor products?
∙ Was there a lawsuit or some other kind of non-recurring expense?
∙ Was there some other major news event?

Provide a solution for a requirement wherein an insurance company wants people to buy
insurance from them when they search for a hospital

The interviewer is expecting you to ask questions in this case. Ask the current process that the
insurance company follows, ask what would be the future state etc.

Why do you want to work for this company?

∙ My experience fits in well to tackle the opening

∙ I'm interested in the problems the company is trying to solve

Why do you want to change the company?

I have worked with my current employer for the last 3 years and have grown well. However, my
work is no longer challenging. I have no new avenues to grow within the organization. That being
said, I am keen to make this transition to stay on the path of progress. So its not only about
upward mobility but also about financial growth.

How did you utilize Fundamentals of UX in your work?

First off, I got to learn a lot from the Fundamentals of UX by gymnasium. However, the course
was meant for interactive websites like Facebook, MakeMyTrip etc. which actually rely on UX for
the company revenue. But the kind of projects that I work on are internal Projects, meaning the
end-users are the Operations Team that sits in India itself. So to be honest, I couldn’t utilize much
of the UX skills in my project but it surely helped me create wireframes. For example, my key
takeaway was Personas which are target audience, Scenarios, giving them hypothetical
background and User Stories, how they would like to interact with the system. So in my project,
the first 2 steps were not applicable. I kept my wireframes as simple as possible so long as the
end users’ need was satisfied. Also, more thing I learned was to keep on having the wireframes
reviewed by the end-users. This process was called ‘Fail Fast, Fail Often”

Difference between UI and UX?

At the most basic level, the user interface (UI) is the series of screens, pages, and visual

elements—like buttons and icons—that enable a person to interact with a product or

service.User experience (UX), on the other hand, is the internal experience that a person has as

they interact with every aspect of a company’s products and services.

What is your typical day as a BA in your company?

It starts with a stand-up with the Delivery team where we discuss progress made so far. It’s at
this point they’ll raise any issues, or notify me of any information they need from the business to
progress.

Following this, I’ll have meetings with relevant stakeholders across the business, where I’ll
question and probe in a way which will help me understand the requirements and get the
answers needed for the Tech team to progress. Once I’ve got that high-level understanding, I’ll
refine those requirements into user stories, which the Delivery team will use to build a solution.
Apart from the Stand-up meeting, I occasionally have ad-hoc discussions with the technical team
as and when they need clarification or walkthrough of the requirements.

After working parallely with both teams, the documentation has to be done. The different
documents have to be prepared from time to time like business cases, user stories, stakeholder
management plans, etc. On a day to day basis, these documents have to be reviewed and
necessary changes have to be made.

On a daily basis we have client meetings wherein the Project Sponsor outlines the upcoming
changes in their policies that might have effect on our application. I document such pointers for
my future reference and as and when new requirements arise, I map them with these pointers.

When it's time to start gathering requirements for the new phase, I conduct interviews with
them. Prior to conducting interviews, I have to do my homework and prepare interview
questions that I can pose during requirement gathering. Post that, I verify the requirements to
find gaps.

How did you become BA from QA?

So what had happened was that the BA of my project had left the company and I approached my
Project Manager to volunteer myself to be BA. He in turn consulted the client. Since I had had
frequent interactions with him and also since I had been working in the Project for a very long
time, he agreed to grant me that role. For the first two months, I was working both as a BA and
QA. But then they got a QA hired and I was moved completely into the BA role.

Difference between low-fidelity and high fidelity wireframes

Low fidelity has these elements:

● Focuses on layout and high-level interactions and concepts.
● UI elements and content can be represented as boxes or lines, with or without label
descriptions.
● Gray-scale.
● Can be paper sketch.

High fidelity has these elements:

● Emphasizes visual aesthetics and branding, such as tone, colors, graphics and font style.
● Can include realistic images and copy.
● UI elements look realistic and might include aesthetic touches such as textures and
shadows.
● Sometimes known as a mockup.
How will you create pagination in the wireframe?

What tools are used by business analysts?

Business analysts used a wide range of tools to help them do their jobs. They fall into a number
of different categories. Some of these categories and tools are:

For gathering and organizing research

● Microsoft Word

For defining objectives and analyzing data

● Microsoft Visio
● Excel

For prototyping and wireframing

● LucidChart
● Balsamiq

For presentation
● Microsoft Powerpoint

For project management and collaboration

 ● Azure DevOps
● Jira

How will you track changes/enhancement in the existing document for the development
team?

If I were to be the new BA in the project, I would make a copy of the existing FSD and make the
required changes that are to happen whether its a new functionality or change in the existing
functionality. I will write these changes in the Revision History of the document that is usually
the second or third page of the FSD.

How do you deal with Change Requests?

1. Receiving a change request

The goal, at this stage, is to capture as many details as possible and verify that the request has

been captured in its entirety. If the request sounds too outlandish even without in-depth

analysis, don’t be afraid to voice your opinion. All change requests should ideally be reviewed by

a senior authority to be considered valid.

2. Conducting a preliminary change assessment

A preliminary change assessment should analyze the impact the change request is likely to have

on the project schedule, budget, resources, scope, and other existing systems, just to name a

few areas of assessment. The purpose of a preliminary change request assessment is to find out

the effects of the change. Some changes have such a large impact and so little value that they

are not worth implementing at any stage, especially near project completion.

3. Assessing the priority of the change request

Some change requests should be dealt with without any delays, while other change requests can

wait virtually indefinitely. It’s important to clearly separate various kinds of change requests and
deal with them according to their priorities. This will ensure that the team is not overwhelmed

unnecessarily.

4. Taking action

Once you know which change requests to implement and which to disregard, it’s time to take

action. At this stage, it’s paramount to resist working on low-priority change requests before

dealing with urgent change requests.

5. Providing feedback

Regardless of whether you’ve decided to dismiss or implement a change, you need to inform the

customer of its status. In some cases, this could lead to additional change requests, but you can

easily deal with them using the same workflow.

What is Impact analysis?

Impact Analysis is used to evaluate the effect of a change when a requirement changes,

its relationship to other requirements would also have to be assessed. This might lead to

changes to other related requirements.

When considering if a change should be approved, the following needs are to be

considered -

1. Benefit - What benefit would be gained by making this change?

2. Cost - What is the total cost to make this change? These costs include the cost of

rework and opportunity cost of other features that need to make the change

possible.
 3. Impact - How many stakeholders would be affected by this change?

4. Schedule - How would making this change affect the timeline of the project?

5. Urgency - How urgent is the change? If this change is not implemented, how

would it affect the success of the solution?

How do you do impact analysis of Requirements?

https://www.dummies.com/business/business-strategy/how-to-ensure-your-business-analysi

s-requirements-have-traceability/

Which tool have you used for the documentations?

Confluence, SharePoint

E2e, b2b, c2c?

B2b - Business-to-business (B2B) simply means business-to-business, which is a business model

that focuses on selling products and services to other companies. Think of it as a supportive
company that that through their products and services helps companies succeed or boost their
internal efforts.Services like Dropbox, General Electric, Xerox and WeWork are great examples of
modern day application of B2B companies.Unlike business-to-consumer (B2C) businesses whose
customers are the people who purchase a product or service, B2B customers are harder to
define.

C2c - Consumer to consumer, or C2C, is the business model that facilitates commerce between
private individuals.A solid example of C2C transactions would be the classifieds section of a
newspaper, or an auction. In both cases, a customer – not a business – sells goods or services to
another customer. A more high-tech version of this is the rise of apps like OLX.

B2C - or business to consumer, is the type of commerce transaction in which businesses sell
products or services directly to consumers. Traditionally, this could refer to individuals shopping
for clothes for themselves at the mall, diners eating in a restaurant or subscribers deciding to get
pay-per-view TV at home. More recently, however, the term B2C refers to the online selling of
products, or e-tailing, in which manufacturers or retailers sell their products to consumers over
the internet.

C2b - A consumer-to-business model, or C2B, is a type of commerce where a consumer or end

user provides a product or service to an organization.
In the C2B model, a consumer provides a business with a fee-based opportunity to market a
product or service on the consumer's website or blog. In this type of relationship, a website
owner is paid to review the product or service through blog posts, videos or podcasts. In most
cases, paid advertisement space is also available on the consumer website. For example, many
bloggers tend to endorse products.

What is Gap Analysis? What are the parameters of Gap Analysis?

The gap analysis is a tool designed to help you understand where you are, and what you need to
do in order to get to where you want to be.

A gap analysis is essentially taking a look at three key elements:

● The current situation, or “performance”

● The ideal situation, or “potential”

● What needs to be done in order to get from performance to potential, or “bridging the

gap”

Fundamentally, the gap analysis is a means of understanding why a company isn’t performing at

its peak potential. What factors are stopping the company, person, team, product, or process

from achieving their maximum capacity, and how can it be fixed?

Gap Analysis categories -

There are a few different types of “gap” to consider, all of which are pretty straightforward:

● Performance (or strategy) gap: Actual versus expected performance

● Product (or market) gap: Actual versus budgeted sales

● Profit gap: Actual versus target profit

 ● Manpower gap: Actual number and quantified performance of workforce versus that

which is required

How did you perform Gap Analysis in your project?

http://studylecturenotes.com/what-is-gap-analysis-how-to-do-gap-analysis-in-project-manage

ment/#:~:text=Project%20manager%20need%20to%20follow%20these%20three%20steps,3%

20Identify%20how%20you%20will%20Bridge%20the%20Gap

I used spreadsheet to conduct Gap Analysis in my project wherein I stated - Current State, Future

State and Tasks required to reach from Current State to Future State

How is BA involved in UAT?

The BA role is all about ensuring that each project delivers the value the business needs and
expects. Actively participating in planning for and running User Acceptance Testing is an
important way for the BA to ensure that value is indeed delivered. The focus of UAT should be
on how the system will actually be used in practice. Because the Business Analyst learned about
the business needs and business activities during Requirements Elicitation and Analysis, he/she
has an understanding of what should be tested during UAT and should be involved in planning
the UAT tests. UAT planning should go something like this:

1. Create a separate test Case document for each type of User who will participate in UAT. The
test cases for each type of User must include each business scenario that role will use the
system to work through. Be sure to include not just the normal “happy path” scenarios, but also
all of the special cases and error cases.

2. Go through all of the requirements and ensure that each will be tested by all of the users that
it is designed for. Add to the individual user role test plans as appropriate to achieve complete
UAT coverage of each requirement.

How do you control the project as a BA?

Every project initiates, as a response to a business need that, according to the BABOK® Guide,
“describes a problem that the organization is (or is likely to) face or an opportunity that it has not
taken, and the desired outcome. The business need will guide the identification and definition of
possible solutions.” . To summarize this concept, we can say that from the Business Need arises a
request for changing the organization's capabilities, and this change should deliver benefits to
the business.

On the other hand, projects are the means through which changes are implemented. Project
management best practices suggest that, after the project is “formally authorized,” it should be
planned—starting with defining “what” has to be delivered (project scope) and “how”
(Process)—and then carried out in order to build these project deliverables. Through the use of
the project deliverables, the organization will realize the expected business benefits. Exhibit 1
describes this concept:

Exhibit 1 – Business and Projects

In order to create project deliverables that produce the expected business benefits, it is essential
first to understand the need for change of the organization (and this is not a simple task, because
business stakeholders always speak a “business language,” not a “project language”;
furthermore, they are also used to speaking in terms of “solutions” rather than “needs”); then,
the business needs must be prioritized and translated into a set of “implementable”
requirements and, eventually, the project must be planned and executed, and during the
execution, the project team must “listen,” continuously and carefully, to the new needs that
might arise from the business. And, still, when the project is completed and the deliverables are
released to the business, the performance of the solution must be assessed in order to capture
the limits and opportunities for creating more business value.

It is obvious then to realize why organizations must develop both project management and
business analysis skills in order for a project to deliver value to the business, because this value is
in fact created before, during, and after the project. Project management focuses on the
implementation of the change, and business analysis leads the project toward the understanding
of the needs and the realization of business value.

How do you know that you have enough requirements to start the development?

Requirements are considered as complete when they satisfy the below criteria:

● Requirements should be aligned with the objectives of a business. It means that

the views of business stakeholders should align with the needs to be built for the
project.
● All the possible views and ideas of key stakeholders are to be extracted.
● The quality of the requirements should meet/satisfy the organization’s set of
criteria through which the quality of the requirements is tested. - CMMI format
● One can say that the requirements are complete when they could be done within
the possible available resources.
● All the stakeholders of the project should be in consent with the gathered
requirements.

What will you do if the developer or the tester haven’t understood a requirement very well
but you have explained them well before and there is no time to re –explain them.
I’m assuming because of a hard stop, I wouldn't have time to re-explain the requirement to the
technical team. In that case, I will ask them to read the User Story/FSD again and then they can
accost me if any clarification is required in the requirement.

What is BA’s role in implementation?

Supporting implementation is when BAs are involved through the end of the life cycle. BAs are
not typically involved directly in implementation unless they’re holding additional roles on the
project. But they are typically brought in if issues come up during implementation that cause
some new requirements to be addressed. This could involve facilitating a problem-solving
meeting to discover how a particular business need can be met given newly discovered
technology constraints.

How to do Requirement Elicitation?/Strategy for Requirement Elicitation/What do you look for

in a Requirement while eliciting?
https://baknowledgeshare.com/3-steps-to-eliciting-requirements/

Talk about non-functional requirements as well.

What would be your approach in dealing with non-functional requirements?

You can never create a product that combines the maximum levels of all quality characteristics.
Tradeoffs are necessary between properties such as usability and efficiency, integrity and
usability, and integrity and interoperability. Therefore, it’s important to understand which
specific portions or aspects of the product have critical quality demands so that developers can
optimize their designs to achieve those objectives.

Suppose there is a legacy system in place and it does not have any specification document
available. How will you go about in knowing about the system?
I shall use the Reverse Engineering method through which I will attempt to understand through
deductive reasoning about how the software accomplishes the task. I will research the domain
terms and come up with queries that I can clarify with available stakeholders.

What is a Use Case? What are the components of a Use Case?

Use cases can be represented by diagrams or text
Use Case is a textual description that captures the user system interaction. It’s the interaction
between the user and a software system.
Components of the textual Use Case are -
1. Use Case Name - you want that name to be verb-noun. So, “Purchase Course,”
“Subscribe to Free Training,”. You want to know: what is the action that user is taking
that’s going to be described in the use case?
2. Brief Description - Insert a 1-2 sentence description of this use case. Be sure to include a
starts when / ends when statement to clarify the beginning and ending points of the
scope of this process or piece of functionality.
3. Actors - List any roles or systems involved with this process or use case. A person or
system fulfilling a role will be the actor in one of the steps.
4. Pre-Condition - List anything that must be true before this process or functionality
begins. Preconditions should state that a system can validate to be true. A common
example is that a specific Actor has logged into the System.
5. Basic Flow - The basic flow is the normal course of events, otherwise called the “happy
path.” Ask yourself, what happens most of the time and you’ll discover the steps that
belong here. You’ll want your basic flow to cover the full scope of activities between the
starts when and ends when.
6. Alternate/Exception Flow - An alternate flow is a variation from the basic flow.
Alternatives can be triggered at any step in the basic flow and often reinsert the actors
back into the basic flow. An exception flow is an error, or a negative condition. When an
exception is encountered, it prevents the process from finishing through to its
conclusion until it’s addressed.
7. Post-Condition - Post-conditions indicate what must be true of the state of the system
after the steps of the use case are complete. These should be true for the basic flow and
all alternate flows. Exception flows may have different post-conditions or none at all.
8. Supplemental Requirements - This is a special section I use to hold miscellaneous
requirements related to the use case. Often you’ll find BAs including a Business Rules
 section or other collection of information related to the use case. These may or may not
be actual requirements – you’ll want to establish a clear pattern and communicate that
clearly and ensure it’s consistent with how your organization documents this type of
requirement. I’ve also used this section to capture the most salient decisions and notes
so they are stored right with the use case for future consideration.
9. Visual Model - Many use cases are enhanced by a visual model. A simple work-flow
diagram can be used to visually show the sequence of steps and alternate and exception
flows. A user interface mock-up can be used to show a possible representation of these
user requirements in an interface (or a desired representation). In some organizations, a
more formal UML diagram may be appropriate.

Use cases can also be represented using diagrams. The UML notation is the most widely used
standard.
Components of Use Case Diagrams are -
1. Actor
2. System
3. Use Cases

Difference between Basic Flow, Alternate Flow and Exception Flow

BASIC / POSITIVE FLOW
The main flow of events describes a single path through the system. It specifies the interactions
between the actor and the system for an ideal condition. It represents the most common way
that the use case plays out successfully and contains the most common sequence of user-system
interactions.
ALTERNATE / OPTIONAL FLOW
An alternate flow is a series of actions other than the basic flow that results in a user completing
his or her goal. Often ,It is considered to be an optional flow. It means that the user has chosen
to take an alternative path through the system.
EXCEPTIONAL FLOW
An exceptional flow is any action that will cause the Actor to not to complete or achieve the
desired result. Exception flows represent an undesirable path to the user. However, even though
the exception flow has occurred the system should still react in a way that recovers the flow and
provides some useful information to the user.

What is BRD? What are the components of BRD?

“A Business Requirement Document (BRD) focuses on the business perspective as it holds the
details of the business solution for a project.”
Business requirements document also emphasizes the needs and expectations of the customer.

Components of BRD -
1. Revision History and Approvals
2. RACI Chart for this Document
3. Business Goals - Need: Detail out the need for the software. To give examples, need can
be any one of the following.
● Is it because of problems in the existing software?
 ● Is it a new software being created to grab a new opportunity

in the market? Is it created for process improvement?

● Is this an enhancement to existing software?

● Is it just changing the interface of the existing software?
● Is it changing the back end of existing software?

GOAL should be SMART (Specific, Measurable, Achievable, Realistic, Time

Bound)

4. Business Objective - What are specific expectations from the software?

Examples of Business Objectives are:

● 10% lesser frauds in credit cards

● 2 minutes lesser time taken to book tickets
● Speed of report generation increases.
● Process automation will reduce x number of people working on it
● Employee satisfaction increase, improves morale of employees, reduces

monotonous work

5. Business Rules - List Organization Policies, Procedures, and Rules & Regulations

6. Background - Provide a brief history of how the project came to be proposed and

initiated, including the business issues/problems identified, and expected benefit of

implementing the project/ developing the product.

7. Project Objective - These should describe the overall goal in developing the product,
high level descriptions of what the product will do, how they are aligned to business
objectives, and the requirements for interaction with other systems]
Till now we were discussing Business from here on we talk about the project and
software that we are developing.

8. Project Scope - What we are going to develop in the current project? Draw the use
case diagram with boundary

8.1 In Scope Functionality - List what functionalities we are going to do with in the
project in bullets

8.2 Out Scope Functionality - List of functionalities what is not included in the
current project

9. Assumptions - List all assumptions requirements are based on

10. Constraints - List all Constraints
11. Risks - Technological Risks, Skill Risks, Political Risks, Business Risks, Requirement Risks
12. Business Process Overview - This describes the overall process flow from each phase.
 This section is divided into AS-IS system and TO-BE system overview

12.1 Legacy System (AS-IS) - Brief Explanation about the process in legacy system and
draw process flow diagram

12.2 Proposed Recommendations (TO-BE) - Describe the new recommended processes.

Draw similar diagrams for each of the new processes in the recommended Software
System.

13. Business Requirements - The specific business requirements elicited from stakeholders
should be listed, categorized by both priority and area of functionality to smooth the
process of reading and tracking them. Include links to use case documentation, and
other key reference material as needed to make the requirements as complete and
understandable as possible.
14. Appendices
15. List of Acronyms
16. Glossary of Terms
17. Related Documents

What is FSD? What are the components of FSD?

A functional specification works like a blueprint that helps the development team to understand
how an application will function. It describes the user experience step by step.

A functional specification basically tells developers what features they need to build and why. It
also helps all the stakeholders involved in the process to work through their often diverging
opinions by focusing on a set of goals. Components of FSD include -

1. Project Scope
2. Risks and Assumptions
3. Use Cases
4. Requirements – critical features of your product that answer the question: what does
your product do?
5. Configuration – steps required to configure a product (for example, setting up a user
account)
6. Non-Functional Requirements

Difference between BRD and FSD?

BRD contains the business requirements that are to be met and fulfilled by the system under
development. These requirements specify "what" the system must do in order to fulfill the
requirements of the business. They often take the form of "The system shall..." Each
requirement, or group of similar requirements, is typically accompanied by a business rationale.
The business rationale explains "why" the business requirement is necessary. This is often
important later if analysts or developers have questions regarding the purpose or validity of the
requirement. The rationale can be used to support the need for the business requirement or
clarify ambiguous language by providing a context for the requirement. In addition to a rationale,
constraints can be provided for each requirement along with other supporting reference
material.

FSD defines "how" the system will accomplish the requirements by outlining the functionality
and features that will be supported by the system. Ideally, the functionality of the system will be
described in logical terms so that the FSD is technology and platform independent. This gives the
architects and developers more freedom in making development and design decisions about the
physical design of the system. Inevitably, however, some things have to be explained in physical
terms. The User Interface is one such example.

What is a JAD meeting and what is the Business Analyst's role in one?

A JAD is a Joint Application Development (or Design) meeting. It is an opportunity for

stakeholders with different points of view to come together to understand business
requirements and brainstorm what the best technical approach might be for meeting the
customer's needs.

A JAD is a challenging environment because it is a meeting or workshop that brings together

people from a number of different disciplines. They could include business or product owners,
systems analysts, enterprise architects, solution architects, software developers, and managerial
staff. Each will come with their own points of view and may at times resort to lingo specific to
their focus area.

The Business Analyst (BA) frequently stands front and center as the facilitator of a JAD and as the
presenter of what the business needs, objectives, and requirements are. The BA may also further
elicit requirements as needed.

As facilitator, the BA's job is to ensure the meeting keeps running smoothly. That requires setting
the agenda, making sure the agenda items are being met, help brainstorm when discussions
become snagged, and bring order when discussion gets heated or defensive. The BA should
come prepared with copies of the agenda and business requirements documents.

If asked to serve as the representative of the business, the BA must be fully informed of what the
business needs are and be prepared to discuss and explain them. That may mean responding to
questions from the technical staff with regards to how the business would like to see something
implemented.

If other business stakeholders are present, the discussion between them and the other JAD
members may cause them to realize that additional business requirements need to be captured.
The BA would elicit and capture those requirements. If technical requirements come to light, the
BA may capture those if they have the necessary expertise, or else rely on a systems analyst to
do so at the meeting.

A JAD is successful, and therefore the Business Analyst is successful, when there is a "meeting of
the minds" among all of the individuals present with agreement on what kind of solution needs
to be developed to fully address business needs, with all requirements put in writing to facilitate
development.

How do you see yourself in the next 5 years?

Since I became BA only last year, I wish to grow vertically in this sphere to such an extent that I
become confident to understand all the complex problems and requirements that come in my
way. I wish to take decisions on the basis of my past experience projects that will provide value
to the customers.

What if the development is to start soon and you are supposed to start collecting
requirements. Client is not reachable, what will you do in this case?

First off, if the client is unreachable, I will drop him/her an email stating that the project timeline
would be impacted if the requirement elicitation is not started by the said date. In the interim, I
will read the RFP document thoroughly to understand the rationale behind the project, research
the company and domain, prepare the interview questions so that the requirements can be
elicited without any delay.

What if the project is nearing its completion and stakeholders have come up with new
requirements. Will you accept it?

As a BA, first I’ll get signed a document by the user which states that after a point of time no
changes to the requirements are accepted. However, if the project wouldn’t provide value
without that requirement, I will conduct Change Request Analysis.

Why do we do Requirement Prioritization?

Large software systems have a few hundred to thousands of requirements. Neither are all
requirements equal nor do the implementation teams have resources to implement all the
documented requirements. the BA needs to understand the needs of the business to prioritize
the requirements. Prioritization of requirements will –

● Reduce development costs

● Shorten the project duration
● Ensure that the most important requirements are taken care of
● Manage project better
● Help in trade-offs
Factors to determine priority of the requirements

BABOK 3.0 suggests 8 factors that influence the prioritization of requirements.

1. Benefit - It is the advantage that the business accrues as a result of the

requirement implementation. The benefit derived can refer to functionality,
quality or strategic / business goals. For instance, the Business Team needed a
report on urgent priority in order to send it to the onshore client.
2. Penalty - It is the consequence of not implementing a requirement. It can refer to
the loss in regulatory penalties, poor customer satisfaction or usability of the
product.
3. Cost - It is the effort and resources that are required to implement a requirement.
A resource can refer to finance, man-power or even technology.
4. Risk - It is the probability that the requirement might not deliver the expected
value. This can be due to various reasons ranging from difficulty in understanding
the requirement to implementing the requirement.
5. Dependencies - It is the relationship between requirements. As such, a
requirement will require the completion of another requirement for its
implementation.
6. Time Sensitivity - Everything comes with an expiry date. There has to be mention
of what time the requirement will expire or also if the requirement is seasonal.
7. Stability - It refers to the likelihood of the requirement remaining static.
8. Regulatory/Policy Compliance – Those requirements that must be implemented
to meet the regulatory requirements.

Whose responsibility is it to prioritize?

Prioritization of requirements cannot be done by the BA alone based on his understanding of the
project scope. He needs to bring in various stakeholders into the process and get their
agreement on the priority of requirements. The BA can use any of the prioritization techniques
to statistically prioritize the requirements. But, before prioritizing the requirements, the BA
needs to understand the dependencies between the requirements. Creating a dependency map
helps the cause.

Tools used for Requirement Prioritization

1. MoSCoW Technique - Must have – These are features that must be included before the
product can be launched.
Some of the common guidelines for Must haves are as follows:

● Cannot deliver on target date without this data

● Cannot deliver the Business Case without it
Should haves are features that are not critical for the launch, but are considered to be important
and of a high value to the user.

● Important but not vital

● Solution viable without the requirement
● Work around available for the requirement.

Could haves are features that are nice to have and could potentially be included without
incurring too much effort or cost.

● Wanted or desirable but less important

● Workaround available for the requirement.
● Less impact if left out

Should and Could are differentiated by the relativity of importance. The ones that have higher
business impact are categorized under Should.

Won’t have - are features that have been requested but are explicitly excluded from scope for
the planned duration and may be included in a future phase of development.

As a BA, challenge the Must have requirements and try pushing them in any of the other
categories. The effort allocation for the Must, Should and Could - should comprise of 60%, 20%
and 20% of the total estimated effort.

2. Kano Analysis -

Kano analysis allows us to prioritize requirements as a function of customer satisfaction.

Kano defined four categories into which each feature or requirement can be classified (an
Apple® iPod® is used for examples in each of the following four requirement categories):

1. Surprise and delight. Capabilities that differentiate a product from its competition
(e.g. the iPod nav-wheel). Offering up the unexpected (or bonuses) to the customer.
2. More is better. Dimensions along a continuum with a clear direction of increasing
utility (e.g. battery life or song capacity). How well you meet the needs of the
customer.
3. Must be. Functional barriers to entry—without these capabilities, customers will not
use the product (e.g. UL approval). Quality is key here or you may lose the customer
to a competitor.
 4. Better not be. Represents things that dissatisfy customers (e.g. inability to increase
song capacity via upgrades).

BA Competencies
Communication Skills: The most important is how effective you communicate so that the right
information is conveyed properly to all the participants in the team meetings. Asking the right
questions and focusing on listening as well helps a lot. You should able to take proper notes from
the meetings whether it is room meeting or conference call meetings. The same is applicable in
email communications as well.

Critical Analysis skills: Critical thinking is the one kind of asset to the business analyst. He should
possess strong domain knowledge. Until and unless he doesn’t understand the complexity of the
project he may not be able to think about all aspects of the project.

Problem Solving Skills: After understanding the complexity of the project, the business analyst,
has to figure out what could be the problems and produce potential solutions to that problem.

Management and Leadership Skills: Managing the project is not only meant to manage the
functional and nonfunctional requirements of the project but also to manage the team with his
behavioral skills. Your leadership skills also polished well so that you can manage the team
efficiently.

Technical Awareness: While handling the project, a business analyst must be aware of technical
terms, the jargon used in the industry, and also how the technical people such as developers and
testers working on various tools and which technology they are using to develop the application.

Tools And Techniques: Apart from the industrial technical knowledge a business analyst should
aware of the tools which are used to develop the requirement analysis document,

Use cases, user stories, change management, impact analysis management, etc.

Difference between Validation and Verification

Validation - Ensure that all requirements support the delivery of value to the business, fulfill its
goals and objectives, and meet a stakeholder need. Requirements validation is an ongoing
process to ensure that stakeholder, solution, and transition requirements align to the business
requirements.
Before even a draft specification, meeting with the primary business stakeholder to iterate
through potential requirements, understand the business value and fit them together in a logical
way, is VALIDATION.

Verification - Requirements verification ensures the intrinsic quality of the requirements. The
purpose of Verify Requirements is to: “Ensure that requirements specifications and models meet
the necessary standard of quality to allow them to be used effectively to guide further work.”

Verification Activities - 1. Checking for compliance with organizational performance standards for
Business Analysis, such as using the right tools and methods.

2. Checking for correct use of modeling notation and templates.

3. Checking for completeness within each model.

4. Ensuring the terminology used in expressing the requirement is understandable to

stakeholders and consistent with the use of those terms within the organization.

Difference between “Building the Product Right” and “Building the Right Product”

Validation - “Am I building the Product Right?”

Verification - “Am I building the Right Product?”

How did I learn all the BA responsibilities?

I was not aware of many responsibilities of a BA when I was a QA but I used to observe my BA in
the meetings and review their BRDs and FSDs. The role has always intrigued me and in fact, I was
encouraged by my colleagues to be a BA. So when the opportunity arrived at my doorstep, the
role was completely different from what I initially expected. So I made use of the lockdown by
enrolling myself in the IIBA ECBA Training and learnt all the tools and techniques that a BA
should know and I successfully applied them in my project. To stay in the path of learning, I read
articles on Business Analysis. My favorites are BACentric and Bridging the Gap.

Client has given 10 requirements out of which developers say that 2 are not technically
feasible. What would you do next?
I will sit with developers and try to understand why the requirements are not feasible. I will gain
clarity to the limitation as much as my technical knowledge would allow. Then we shall have a
brainstorming session as to how we can find an alternative solution so that Business Need is
served and do the impact analysis to make sure other requirements are not changed. I will
propose these alternative solutions to the client, seeking their approval.

What if 100 requirements have been captured after the Requirement Elicitation, what would
you do next
After Requirements have been captured, I will validate whether the requirements captured
aligned with the Business Needs, analyze the requirements to find any missing link or if the
requirement was incorrectly captured. And I will also make sure that there is no conflict between
the requirements; they seek clarifications from stakeholders if there are any unclear or vague
requirements. After all the requirements have been analyzed, I will present the requirements in
the form of textual use cases in the FSD document.

What if the client says after the implementation that the functionality delivered was not as
expected?
First and foremost, I shall verify myself if the delivered functionality was part of the requirement
or not. Since the BRD and FSD documents are approved by the clients themselves, I shall counter
that we have delivered functionality as per the requirements. We shall counter that if they want
requirement to be changed, it will be taken up as a CR.
If, however, the requirement is urgent and the project would not provide value without it, it
would have to be taken up on priority.

What do you do if the developer does not understand requirements during the Product
Backlog Grooming session?

Scrum does not mandate that one has to give walkthrough of the requirements only in Product
Backlog Grooming session. I will at first rephrase my sentence that would be understandable to
all the developers but if they still face the same challenges then another meeting would be
booked to re-explain the requirement.

What is a Risk? Examples of Risk in a project

An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more
project objectives (such as scope, schedule, cost, and quality.. Negative Risks are threats and
positive risks are opportunities.
The uncertain event or condition may or may not occur. If a threat occurs, it becomes an issue or
problem. If an opportunity occurs, it becomes a benefit. So, risks are things that may occur;
issues and benefits are things that have occurred.

Negative Risk in my project -

● Read Scheduler license was valid for 6 months. It had to be renewed. This could impact
the project schedule if not renewed on time.
● Requirement change after FSD finalization is a negative risk. It will impact the scope and
schedule of the project
● Unplanned leave for a long duration by the implementation team member(s) can
negatively impact the project timeline.

Positive Risk in my project -

● Project completion before the timeline. (However, its not advisable because it would
mean incorrect estimates)
● Project under-budget

Once you identify Risks in your project. What would be the next steps?
Once the risks have been identified, I will present them in the Risk register along with their
probability, severity and impact along with the mitigation steps.

What are Project Constraints?

Project constraints are limiting factors for your project that can impact quality, delivery, and
overall project success.
Sometimes referred to as the triple constraints and project management triangle, the iron
triangle is a set of three interdependent project constraints that every manager faces. As
discussed before, the three basic constraints known are the following:

1. Scope constraints: Project scope are extremely precise and come with all the necessary
information about the final project deliverable. The feature and functions identified in
the scope have to be achieved in order to call any particular project a success.
 2. Time constraints: Imagine you come to your office on a local subway that takes 20
minutes to reach your stop and you can’t change the way you commute. Then those 20
minutes are your time constraint. Similarly, there are several tasks in a project that have
a certain processing time and there is nothing you can do to reduce it. Effective time
management requires you to accommodate that time while ensuring that all the
required objectives are met within the given deadline.

3. Budget constraints: The project budget indicates the maximum amount you are allowed
to spend on a particular project. It does mean the associated costs of the required
materials or processes only. The budget includes vendor payments, labor costs, and even
contingency funds that are only required when you are in damage control mode if things
don’t go as planned.

How Project Constraints can be controlled?

● Transparency is often considered a key factor for successfully managing project

constraints. With transparency, everyone involved in the process knows about the
priorities and objectives of the project.

● measuring performance throughout the project life cycle, keeping the team members
engaged, and having an effective control strategy are some of the ways that can improve
your performance despite multiple constraints.

What are Project Assumptions

A Project Assumption is a documented fact, statement or interpretation that is not expected to

change for the duration of a project. A change to assumptions typically has a significant impact
on a project because they are the foundation for project decisions, estimates and designs.

Types of Assumptions -

1. Technology
2. Business
 3. Financial

Assumptions in my Project -

● There will be no significant increase in volume of the emails because it is assumed that
by the time ops will login at work in the morning, the scheduler would have run.
● Emails are received in the common mailbox

What if the client says that they want a particular functionality (possibly CR) in a few days but
the implementation team says that they want it in more days?

I will at first do impact analysis of the change request in terms of functionality. Will make sure
that the scope is properly well defined and there would be no unexpected changes. Check any
external dependencies. Put suggestion like - it is better to deliver a quality product with extra
time than to deliver a poor quality product on time.

How would you communicate extension of the Project Timeline to the client?

1. First and foremost, all the risks regarding the project schedule should be documented
and approved by the client before the implementation phase. In case of an unforeseen
event, communicate the delay to the client and highlight the risk that was identified in
the project initiation phase.
2. Be transparent about the problem. Did the project or account manager fail to take into
account a key requirement when setting deadlines? Was there an unforeseen issue with
the technology? Did a member of the team need to take some unexpected personal
time? clarify the problem and what you are doing to solve it. Show the client that you
are open to a discussion about the mistake.
 3. Before you communicate the delay to the client, consider when you can complete the
deliverable. It needs to meet quality standards. Once you agree upon this deadline, stick
to it -- even if it means your team needs to work extra hours to get the project done
on-time. However, this could be a situation where a missed deadline just won't work for
the client's timeline. You could determine a plan for cutting features or elements so that
your team can get the project done within the original timeline. It’s not perfect, but if
you can revise the scope (and reduce the cost), the client may walk away satisfied with
the results.
4. Once you’ve made it past the project, audit the situation. What caused the setbacks?
Was there a lack of communication? How could your team have known earlier that the
team would miss a deadline?

For a successful project, a weekly communication should be established with the client to update
them with the project status, highlighting the progress and risks.

Business Analysis Life cycle

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

1. Understanding the business

2. Identify the business needs
3. Define the project scope
4. Elicit the requirements
5. Analyze the requirements
6. Document and present requirements
7. Communication of the requirements
8. Process Modeling
9. Verification of the solutions meeting the requirements
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.

Effort Estimation of a Business Analyst

15% of the total project should be allocated to requirements alone. So if the full project is 1000
hours, we estimate 150 hours of requirements work. Identify all the deliverables (work products,
artifacts) you will produce during the business analysis effort. It is essential to first identify the
approach you're going to take, whether plan-or change-driven (Waterfall/Agile). It is also helpful
to use the BABOK knowledge areas to identify which work products will be completed. During
the course of an Elicitation event, for example, we might send out an agenda (one work
product), update our traceability matrix (another deliverable), create an "as-is" process model
(another deliverable), and update our list of issues (yet another deliverable). Next we think of
the tasks needed to complete each work product, and finally how many hours the task will take.

What are the challenges that a Business Analyst faces?

1. Paralysis from Analysis - Be it agile environment or a traditional one, Business Analysts

need to dive into the project right away and start acting as soon as possible. The project
could be new or underway, but most often marred with ambiguity. This puts into picture
the need to understand the processes from scratch.

Solution - Yes, reading all that material from scratch may leave you tired and puzzled. So, it is
important to read the project description and its actual demands. Then, ask as many questions
as possible. The ability to formulate and ask as many ‘Whys’ and ‘Whens’ in as many ways as
possible could help. Asking questions would mean more clarity over the project and its needs.
Moreover, you can develop more models and business artifacts than what is required.
2. Changing Business Requirements - In businesses, change is one thing that is always
constant. The stakeholders are known to keep changing their requirements several times
in a week or even in a day. This makes it important for the Business Analyst to take
prompt decisions on whether to implement the changes or not.

Solution - One of the key aspects while taking into consideration the changes to be
implemented in a project is its delivery timeline. If the business requirement is changed
due to any modification of a particular law, policy or rule by the government, then the
change should be implemented immediately even if that requires a certain delay in
planned project deliverables. If the change in requirement is due to stakeholders’
unclear vision, then the Business Analyst should take some time out communicate,
re-plan with the concerned stakeholder and re-schedule the plan. The change in
scheduled deliveries should always be maintained transparent and the need for the
longer execution period should be well justified.

3. Conflicts with Stakeholders - One of the common challenges faced by the Business
Analyst is resolving conflicts. These conflicts could arise due to various factors such as
team members proposing a new idea for the project, arguing over its implementation,
timelines and more. Every time a team working on a project is unable come to a
consensus, it is the Business Analyst who has to step in and resolve the matter without
affecting productivity and delaying schedules.

Solution - A Business Analyst has to thoroughly run through all aspects of the argument,
gauge the pros and cons, and have a sound understanding of all the documentation
involved with the particular project. Critically evaluating the consequences is a must as
the decisions taken would directly impact the project. All of this then needs to be
discussed with the stakeholders involved, and a fair case/presentation needs to be put
forth that maintains transparency and promises efficiency. A proper and thorough
presentation of the matter itself would mean half the battle has been won.
 4. Frequent Absence - While it is important to gather data and keep a track of the minutest
change, sometimes the frequent absence of stakeholders may make this quite difficult.
There would be times when the stakeholders may not meet for a stretch, and then
suddenly turn up only to ask you to change things that were finalized during their
absence. This isn’t all. It is quite possible that one particular execute may attend a
meeting while another may turn up for the next meeting, leading to inconsistency at the
management level.

Solution - The Business Analyst can handle such a tricky situation by keeping all
stakeholders in the loop, each time a change has been proposed or implemented. This
may, a record of the changes can be maintained and shared. In case of a new executive,
all the data can be shared with him or her to keep the process rolling without any delays.
However, in certain cases, it is best to highlight such matters to maintain consistency and
efficiency in the future.

Difference between RFI, RFP and RFQ?

What do you do if there are quality challenges in the released product? How will you
handle the situation?
First and foremost, I will verify the issue myself in the system. If it is indeed a bug, we
will raise it as a production bug and have the implementation team fix it on priority. In
the retrospective meeting, we shall discuss how the bug was missed and leaked in the
production. Perhaps, it will be taken as a lesson learned and quality team will include it
in their test case.

What do you do when developers come up with queries/requirements in the scrum

call that were missed by you?
I basically act as an SME for the Operations Team. So if there is anything that I can
resolve, I provide my inputs, considering that the Business Need is served. But if there
happens to be a requirement that even i am unsure of, I park this question to be clarified
from the Operations Team. If its a close-ended question, I drop an email to them but if is
an open-ended question that requires a discussion, I book a meeting with them to get
the requirement clarified and at the same time I conduct impact analysis with respect to
existing functionalities.

What 5 steps would you take before launching your new idea/product in the market?

https://keap.com/business-success-blog/growth/planning-strategy/ten-stages-to-a-su
ccessful-product-launch
What do you like and hate most about your job?
Likable - Requirement elicitation and preparing, analyzing and managing information
Despise - Taking follow-up from stakeholders for sign-off on documents or for
clarification on query

What do you mean by Stakeholder Management?

https://creately.com/blog/diagrams/stakeholder-management-guide/

Should we keep the wireframes simple ?

What is the most used app on your phone? What are the challenges you face in it and what
solutions do you recommend?

What drives you to work?/Source of motivation?

Who is your role model and why?

Have you been involved in preparing a Business Case?