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.
The questions along with the answers follow:
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.
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.
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.
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.
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 customization 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.
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.
Key elements of an SRS are shown below:
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 recognized by all the stakeholders. E.g. A software will not be compatible with all the versions of all the browsers.
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.
As per IIBA BABOK Guide:
Prioritization provides a framework for business analysts to facilitate stakeholder
decisions and to understand the relative importance of business analysis
Requirements prioritization is the process or stage, where we allocate requirements to different phases or iterations, based on business urgency, schedule, cost etc.
Creating a prioritized requirements list helps in handling requirements in order of their importance to the customer.
There are multiple techniques, which are used for requirements prioritization like:
>> MoSCoW Technique
>> 100-dollar method
>> Requirements Ranking Method
>> Five Whys
>> Kano Analysis & More
You can also buy the book, written by me from Amazon:
Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.
We have a Business analyst training course with domain training in-built into it. This training program offers you the opportunity to get certified with ECBA certification as well as have banking domain understanding.