Business Analyst Fresher Interview Questions (Comprehensive Coverage)

This question can be unnerving if you are not prepared for it. It requires some preparation.

Firstly, you should know about the key responsibility areas and skills expected for this profile. This can be found in the job description (JD).

Secondly, map your existing skills and experience to the required skills and responsibility areas. Let's take an example.

Key Skill: UML Modelling

UML Modelling is used to model requirements. Use cases, activity diagrams and scenario development are specific skills. If you have used these in any of your projects, brief the interviewer about the project and the models you used. Be ready to create one during the interview, so practise it well.

If you have not used it in a project but are familiar with the skill, you can say so. Prepare well with concepts and examples from your project.

As per IIBA, business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to the stakeholders. This definition has three key elements:

• Defining the needs: why a customer wants a solution, what the problem or opportunity is.
• Recommending the solution: it could be a software solution, a non-software solution, or a combination of both.
• Delivering value: every organisation evaluates whether the solution justifies the investment.

These three elements, defining needs, recommending solutions, and delivering value, together constitute business analysis practice.

An IT Business Analyst works with customers and the technology team on a day-to-day basis. Here is a summary of the role:

• Interact with customers to understand their requirements
• Convert business requirements into detailed technical requirements for the technology team
• Coordinate with the technology team to explain the requirements
• Validate the developed solution before handing it over to the customer for User Acceptance Testing (UAT)
• Coordinate with the customer team and the technology team to facilitate UAT

For a deeper view of the BA role across project phases and Agile delivery teams, see the role-related questions in our main Business Analyst Interview Questions guide.

We have developed a framework covering four key skills for a Business Analyst, applicable for both entry-level and senior BAs:

• Soft skills: Communication, interaction and behaviour. A BA works as an intermediary between business and technology, so being effective in communication, what to present, how to present, how to negotiate, is critical.
• BA skills: Day-to-day practical skills used on a project, Agile, Waterfall, business analysis techniques like use cases, process modelling and user stories, and tools like JIRA and MS Visio.
• Functional knowledge: Domain knowledge. If you are working on an investment banking project, you need to understand the key terms and processes of that domain to understand what the customer is looking for.
• Functional testing: The ability to test a solution before it is handed over to the customer. Since you captured the requirements, you are best placed to validate the solution before delivery.

Stakeholders are people or groups who can affect a project or are affected by its outcome.

I’d start by finding out who uses the process, who manages it and who makes decisions about changes. I’d also check which teams provide information or receive the output.

For example, for a college admission portal, I would speak with students, the admissions team, the accounts team and IT support. Each would have different concerns. Students may want an easy application process, while accounts would need accurate payment records.

A business rule states what is allowed, required or restricted in a business.

For example, a library may have a rule that a student cannot borrow more than three books at a time. Another rule may prevent students from borrowing books if they have unpaid fines.

The system needs to enforce these rules, but the rules come from the business. As a BA, I’d confirm them with the person responsible for the policy, including any exceptions.

Root cause analysis means finding out why a problem is happening instead of only dealing with its visible effects.

Suppose students regularly submit assignments late. Sending more reminders might help, but I’d first check why they’re missing deadlines. They may be receiving different due dates through email and the student portal.

If that’s the cause, adding reminders could create more confusion. The useful change would be to establish one agreed deadline and make sure every communication reflects it.

I’d first understand how the work is being done and where the problem occurs.

Suppose expense reimbursements are taking too long. The delay might come from employees submitting incomplete claims, or from approvals sitting with someone who is unavailable. A new application may not solve either problem on its own.

I’d look at whether clearer instructions, a simpler approval process or a backup approver could help. Software would be an option once we understand what actually needs to change.

“In scope” describes what a project will cover. “Out of scope” makes clear what it will not cover.

For example, a college project might allow students to view attendance and download course material. Online fee payment could be outside its scope.

Being clear about this helps people agree on what to expect. If someone later asks for fee payment, I’d record the request and discuss its impact with the appropriate decision-maker before treating it as part of the agreed work.

A BA prepares a number of documents. Some of the commonly prepared ones are:

• System Requirement Specification (SRS), also known as FRS or FRD
• Use Case Specifications Document
• Business Requirements Document (BRD)
• Change Request Log and Change Request Documentation
• RACI Matrix
• Gap Analysis Document
• Requirements Traceability Matrix
• Impact Analysis Document

This is not a comprehensive list, but these are the documents most commonly prepared by BAs.

Gap Analysis is a term commonly used in the product implementation lifecycle.

In product implementation, we conduct an "AS IS" process study to understand the existing business processes in detail. The next step is to study the "TO BE" process, the desired processes, which is the primary reason the project is underway.

Once the "TO BE" processes are studied, the product is configured to incorporate them wherever configuration allows. Remaining processes are either developed as product customisation or as custom-built processes.

Finally, the configured product is demonstrated to the customer. During this session, all the gaps in the system are identified, for example custom reports, yet-to-be-implemented business processes, or search functionality.

Key elements of an SRS are:

• Scope of Work
• Assumptions, Constraints and Dependencies
• References used
• Functional Requirements
• Process Diagrams and Prototypes
• Data Model
• Non-Functional Requirements
• Acceptance Criteria

Requirements traceability means keeping track of how a requirement connects to its source and to related work, such as design, development and testing.

For example, a requirement to cancel an order should link back to the business need and to the test cases that check cancellation behaviour.

These links help when something changes. If the cancellation policy is revised, the team can identify which requirements, screens and tests may need updating. They also help us spot requirements that have been missed during implementation.

I’d include the meeting’s purpose, participants, key discussion points, decisions, open questions and action items.

For each action, I’d record who is responsible and the agreed due date. For example, “Priya to share the current refund policy by Friday” is more useful than “Refund policy discussed.”

I wouldn’t try to write down every sentence. The minutes should help people remember what was agreed and what they need to do next. I’d share them with participants so they can correct any misunderstanding.

I’d start with the process relevant to my assignment and learn the terms used in it.

If I joined an insurance project, for example, I’d first understand the product and process involved, such as policy issuance or claims. I’d read available documents, maintain a glossary and ask a domain expert to explain anything unclear.

I wouldn’t pretend to understand an unfamiliar term. I’d rather ask a basic question early than document something incorrectly and create confusion later.

Requirements are a useful representation of needs. Needs are a high-level description of what the customer wants. Requirements are the expanded and detailed-out description of those needs.

Example of a need: Only authenticated users can enter the system to access the member-only features.

Same need detailed as requirements: Create a login screen which will allow the members to enter login ID and password and click on submit button to access the member-only area. In case of a wrong login ID or password, the system throws an error.

Functional requirements represent what the system does primarily. They represent the behaviour of the system.

For example, registering to become a member of a website is an example of a functional requirement of the website.

Non-functional requirements represent the characteristics of the application under development (AUD) rather than the behaviour of the system.

These requirements relate to performance, user interfaces, security, auditing and similar areas. We do capture them in the SRS document along with functional requirements, but in a different section.

They are important because they allow us to identify the need for skills or resources outside the project team.

Assumptions, constraints and dependencies are important aspects of any software project, as they represent the context and constraints within which the project must be executed.

The schedule is created considering the assumptions and constraints, and if any assumption becomes invalid, it may have an adverse impact on the project. Identifying them in the requirements specifications document is therefore important.

Difference between assumptions and constraints:

• Assumptions are scenarios and situations considered to be facts for the project under development. Example: The customer will provide access to a test PayPal system for testing the payment process.
• Constraints are restrictions agreed upon and recognised by all the stakeholders. Example: The software will not be compatible with all versions of all browsers.

Yes, I have participated in the requirements elicitation phase in my last project. This was a project for a retail banking group. Though there were several challenges, I would like to point out the top three:

• Even though we scheduled the requirements elicitation meetings well in advance and communicated them to the bank, the stakeholders were often not available at the scheduled time and we had to wait for hours. This was going to impact the overall schedule, so we involved senior management and urged them for better participation.
• The customer was tech savvy in general, which was a good thing. But some stakeholders were going overboard in explaining their requirements and giving their wish list as well. We told them it was probably out of scope, but they were not ready to listen. So we decided to handle the out-of-scope items later rather than interrupt the requirements gathering process.
• I also came across different versions of contradictory requirements coming in from different stakeholders.

For interview questions specifically on handling difficult stakeholders, conflicting requirements and similar scenarios, see the behavioural section in our complete BA Interview Questions guide.

This is generally a two-pronged approach.

Firstly, we conduct reviews on the requirements. In one of the projects, the review was conducted by another business analyst who had worked on similar projects in the past. He reviewed the documents and pointed out gaps around logical errors, missing requirements and subjectivity.

Secondly, the requirements were validated by the customer. We created a prototype to demonstrate the system to the customer and discussed each and every screen diligently.

As per the IIBA BABOK Guide, prioritisation provides a framework for business analysts to facilitate stakeholder decisions and to understand the relative importance of business analysis information.

Requirements prioritisation is the process where we allocate requirements to different phases or iterations, based on business urgency, schedule, cost and similar factors. Creating a prioritised requirements list helps in handling requirements in order of their importance to the customer.

There are multiple techniques used for requirements prioritisation, such as:

• MoSCoW Technique
• 100-dollar method
• Requirements Ranking Method
• Five Whys
• Kano Analysis

I’d ask what needs to change and why. There may be a valid reason, such as a new business policy or something we missed earlier.

Then I’d record the request and work with the relevant team members to understand its effect on the existing work, cost and timeline.

I wouldn’t promise that the change would be included immediately. I’d take it through the project’s agreed decision process and update the requirements once a decision had been made.

I’d read the project brief and any available information about the stakeholder’s work. I’d want to understand the purpose of the meeting before preparing my questions.

For example, if we were discussing customer returns, I’d ask how returns are handled today, who approves them and where delays occur. I’d also request a sample return form if one exists.

I’d keep the questions focused, leave room for follow-up questions and confirm the main points before ending the meeting.

I’d use observation when it would help to see how people actually perform a task.

Someone explaining a process may leave out small steps because they do them every day. For example, a receptionist might describe appointment booking but forget to mention that they also maintain a separate notebook for walk-in patients.

Watching the work, with permission, can reveal these details. Afterwards, I’d ask questions to confirm what I saw rather than assume I understood the reason for every step.

UML, or Unified Modelling Language, is a modelling standard in the field of object-oriented software systems. It was developed by Rational Corp (Booch Group) and later standardised by OMG (Object Management Group).

UML is a modelling language that brings together several diagrammatic views which can be used at any stage of the software development life cycle. It was designed to provide a common platform for all stakeholders, end users, analysts, designers and developers, so that miscommunication of requirements and design intent is reduced through one language understandable by everyone.

Use cases are one way to represent requirements from the user perspective.

A use case comprises an actor and the use case itself. An actor is essentially a role, and the use case represents the way in which the actor interacts with the system.

A use case model is a diagrammatic representation of all the use cases and actors of a complete system or a module (logically grouped). A use case model may also show include and extend relationships between the use cases.

In a recent project, I created the use case model for an airport check-in system.

An activity diagram is used in a business system to show the workflow involved, activities happening, and completed actions.

For example, in a company comprising several departments, medical, accounting, human resources, each department typically has its own access privileges to the system. The medical department may only be allowed to access screens related to medical records, while HR will only access HR-relevant screens.

Activity diagrams help show the relationship between specific activities and their relevant departments. During development, coders can refer to these diagrams to implement the right access and behaviour. Designers are similarly guided by activity diagrams.

A wireframe is a simple layout of a screen. It shows where fields, buttons and other information might appear, without spending much time on colours or visual design.

For an appointment booking screen, I might show the doctor selection, available dates, time slots and booking button.

I’d use it to discuss what users need to see and do. It often becomes easier for someone to point out a missing field when they can see a rough screen.

A data dictionary explains what individual data fields mean and how they should be used.

For example, an “Application Date” field could include its definition, data type, whether it is mandatory and any validation rules. We may need to clarify whether it means the date someone started an application or the date they submitted it.

That distinction matters when people build reports or calculate processing time. A data dictionary helps everyone use the same meaning instead of making their own assumptions.

A user story is used to define a software requirement and is mainly used for representing high-level requirements. The typical format of a user story includes the who, what and why of a requirement. There is no fixed standard on the syntax, but a commonly used format is:

As a <business traveller>
I want <to book a flight>
So that I can <attend a business conference>

Even though both are used to represent system requirements from the user perspective, user stories represent user requirements in a more meaningful way. In addition to the user and the requirement, a user story also captures the goal or objective.

Detailed specifications of a use case are captured in a use case specifications document, whereas one of the ways to capture user story details is a user story card.

INVEST is an acronym describing the characteristics of a good user story:

• Independent: The user story should not have any dependency on any other user story.
• Negotiable: User stories can be changed and reframed.
• Valuable: They should add value to the end product.
• Estimable: It should be possible to estimate the size appropriately and prioritise better.
• Small: User stories should be small-sized and manageable.
• Testable: The tester should be able to verify the end result of the user story.

Acceptance criteria are the set of conditions or requirements that must be met for a solution to be accepted by the stakeholders. The acceptance criteria are defined during the requirements gathering phase and should be agreed upon by the stakeholders.

For example, one of the acceptance criteria for a system could be: All the unit test cases should be run successfully by the development team and the results submitted.

I’d first check what each row represents and what the data will be used for. Then I’d look for missing values, duplicates, inconsistent formats and values that don’t make sense.

For a student registration list, I might check for blank student IDs, repeated registrations and dates entered in different formats.

I’d flag doubtful records before changing them. Two students having the same name, for example, doesn’t necessarily mean one record is a duplicate.

Excel can help a BA organise information, check data and prepare simple summaries.

For example, with a list of customer complaints, I could use filters to examine unresolved cases, a pivot table to count complaints by category and formulas to calculate how long cases have been open.

The purpose would be to answer a business question, such as which complaint types take the longest to resolve. In an interview, I’d mention only the Excel features I can actually use and explain with an example.

SQL is a language used to retrieve and work with data in relational databases.

A BA might use it to check how many orders were cancelled, identify customers with multiple complaints or compare monthly sales. It can help verify a business statement against the underlying data.

For example, if someone says cancellations have increased, I could compare cancellation rates across months. I’d check the rate as well as the count, because a higher number of orders could also lead to more cancellations.

User Acceptance Testing, or UAT, is where business users check whether a solution supports their work and meets the agreed business requirements.

As a junior BA, I could help prepare realistic scenarios, organise test data, explain requirements and record issues raised by users.

For a leave application system, users could try applying for leave, approving it and checking the updated balance. My role would be to support the testing and clarify questions. The designated business representatives would make the acceptance decision.

A defect is when the solution doesn’t behave as agreed. A change request asks for something different from, or additional to, the agreed requirement.

Suppose a requirement says users should receive a confirmation email after booking an appointment. If the email isn’t sent, that would be a defect.

If someone now wants an SMS confirmation as well, that would normally be a change request. I’d check the agreed requirements before classifying the issue, because the distinction isn’t always obvious.

I’d compare the results with the business objective agreed at the start.

If an appointment system was introduced to reduce booking errors, I’d look at the error rate before and after implementation. I might also check booking time and feedback from the people using it.

A system going live tells us it has been delivered. We still need to find out whether it has improved the situation. Ideally, we would agree on the measures and collect the starting figures before introducing the change.

I’d explain what the issue means for their work, using familiar language and a concrete example.

Instead of saying, “The API is returning an error,” I might say, “The booking system isn’t receiving confirmation from the payment service, so some customers cannot complete their bookings.”

I’d explain what we know, what is still being investigated and what decision or action is needed from them. If the technical team hasn’t confirmed a resolution time, I wouldn’t guess one.