Entry Level Business Analyst Interview Questions and Answers

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 practice 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.

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 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

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 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.