Are you going for a business analyst job interview? What are the typical entry level business analyst interview questions? In this post, we are presenting some important questions.
These questions are taken from my book Business Analyst interview questions and answers, available on Amazon.
Here are a few top business analysis interview questions with answers.
Why should we consider you for this profile? What do you bring to the table?
This question can be unnerving for you, if you are not prepared for it. This question requires some preparation.
Firstly, you should know about the key responsibilities areas and skills expected for this profile. This can be found in the job description (JD).
Secondly, map your existing skills and/or experience to the required skills and responsibility areas. Let’s take an example to understand the approach to answer this question.
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 have used. It’s possible that you may have used it in more than one project. Be ready for creating one during the interview. So, practice it well.
If you have not used in your project but are familiar with the skill, you can say so. Prepare well with the concepts and examples if possible from your project.
What’s the difference between needs and requirements?
Requirements are the useful representation of the needs. Needs are high level description of the customer needs. Requirements are the expanded and detailed out description of the customer needs.
Let’s take an example of a need:
Only authenticated users can enter the system to access the member only features.
Let’s detail out customer need as requirements:
Create a login screen which will allow the members to enter loginID and password and click on submit button to access the member only area. In case of a wrong loginID and/or password, the system throws an error.
Have you participated in requirements elicitation meetings? What are the major challenges you faced?
Yes, I have participated in the requirements elicitation phase in my last project. This project was for ‘National Bank’ (Change it as per your customer name). We were doing this project for the retail banking group. Though there were several challenges, I would like to point top two:
>> Even though we had scheduled the requirements elicitation meetings, well in advance and had also communicated to the bank, we found that the stakeholders were not available at the scheduled time and we had to wait for hours sometimes. This was going to have an impact on the overall schedule, so we involved the senior management and urged them for better participation.
>> We found this customer to be tech savvy in general and that was a good thing. But some of the stakeholders were going overboard in explaining their requirements. They were also giving their wish list as well. We tried telling them that this was probably out of scope, but they were not ready to listen. So, we decided to handle these out of scope later, as we didn’t want to interrupt the requirements gathering process.
>> I have also come across different versions or contradictory requirements coming in from different stakeholders.
As a business Analyst, which all documents have you prepared?
I have prepared quite a number of documents, some of them are:
>> System Requirements Specifications document
>> Use case Specifications document
>> Requirements Traceability Matrix
>> Change Request Document
>> RACI Matrix
>> Gap Analysis Document
Please use only those, which you are familiar with as you will get follow up questions.
A detailed blog article on documents prepared by a business analyst is also published by us.
What is Gap Analysis?
Gap Analysis is a term used in product implementation lifecycle, generally.
In product implementation, we conduct “AS IS” process study to understand the existing business processes in detail.
Next step is to study the “TO BE” process. The “TO BE” processes represent the desired processes. This is the primary reason why this project is underway.
Once the “TO BE” processes are studied, the product is configured to incorporate the “TO BE” processes in the product, whatever is configurable. Remaining processes are either developed as product customisation or custom build process.
Finally, the configured product is demonstrated to the customer. During this session, all the gaps in the system are identified e.g. custom reports, yet to be implemented business processes, search etc.
What are non-functional requirements? Did you capture them in SRS? Why are they important?
Non-functional requirements represent the characteristics of the application under development (AUD) rather than the behaviour of the system.
These requirements are related to performance, user interfaces, security, auditing etc. 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/resources outside the project team.
What are the key elements of an SRS?
Key elements of an SRS are shown below:
- Scope of Work
- Assumptions, Constraints and Dependencies
- Functional Requirements
- Data Model
- Non-Functional Requirements
- Acceptance Criteria
You mentioned Assumptions & constraints? Why are they important and what’s the difference?
Assumptions, Constraints and dependencies are important aspects of any software project as they represent the context and constraints within which, the project has to be executed.
The schedule is created considering the assumptions and constraints and if any of the assumptions becomes invalid, it might have an adverse impact on the project. So, identifying them in the Requirements specifications document becomes important.
Difference between Assumptions & constraints
>> Assumptions are scenarios and situations that are considered to be as facts for the project under development. E.g. The customer will provide access to a test PayPal system for testing payment process.
>> Constraints are restrictions that are agreed upon and recognised by all the stakeholders. E.g. A software will not be compatible with all the versions of all the browsers.
How did you make sure that requirements were good to go for next stage?
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 project in the past.
He reviewed the documents and pointed out gaps about logical errors, missing requirements, subjectivity etc.
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.
What is requirements prioritisation and why it’s important?
As per IIBA BABOK Guide:
Prioritisation provides a framework for business analysts to facilitate stakeholder decisions and to understand the relative importance of business analysis
Requirements prioritisation is the process or stage, where we allocate requirements to different phases or iterations, based on business urgency, schedule, cost etc.
Creating a prioritised requirements list helps in handling requirements in order of their importance to the customer.
There are multiple techniques, which are used for requirements prioritisation like:
>> MoSCoW Technique
>> 100-dollar method
>> Requirements Ranking Method
>> Five Whys
>> Kano Analysis & More
Another post in this blog provides some scenario based questions for business analysts.
You can also buy the book, written by me from Amazon: