Business Analyst Interview Questions
How do you define the role of a BA in an organization?
A business analyst is a liaison between different stakeholders in an organization. He acts as a bridge, a connector and helps the complete project teamwork as a tightly integrated unit.
Since stakeholders belong to different domains (e.g. finance, business, marketing) it’s very important for a business analyst to be able to sort and balance the needs of these stakeholders while fulfilling the business objectives at the same time.
How do you define a requirement?
A requirement is a capability possessed by a solution to solve a problem or achieve an objective. Requirements are input to various stages of SDLC and must be properly documented and validated by the business users/stakeholders.
What is your requirement elicitation strategy?
The elicitation strategy depends upon the type of the project.
One can take advantage of direct collaboration with the client and have facilitated workshops, interviews and observe the end users. In conjunction, we can use techniques that provide us with more precise information like prototype and scenario building.
Could you describe the main qualities of a good requirement?
The golden rule to measure the quality of a good requirement is the ‘SMART’ rule. According to this rule, a requirement should be:
Specific: The requirement should be specific so that it could be properly documented
Measurable: We should be able to measure the success criteria of the requirement by different parameters
Attainable: The requirement should be possible to attain with the given resources
Relevant: The requirement should be in line with the project’s business case
Timely: The requirement should be posted in time i.e. early in the project lifecycle.
When do you know that you have gathered all the requirements?
Once the requirements are gathered, they are validated by the business users/client. It is only after the approval of the business users, the requirements are considered as to be completed. Additionally, it should be validated that:
They are elicited from all the stakeholders from all the key stakeholders of the project.
They align with the project’s business case.
When they could be done with the resources available i.e. attainable.
When the stakeholders of the project are in consensus with the elicited requirements.
All the requirements which pass the above four criteria, they are considered to be as formal and final. These requirements are then documented and become a part of the project scope.
What is a typical day of your BA job like?
Interviewers often ask this question to ascertain your work experience, how you handle multiple things and your perception of the job.
You should stress upon depicting that there is no typical day for a BA and how varied your work is, through the day. Show your rich experience by explaining how you respond to the emails, meeting with the subject matter experts, clarification of the business flow to the technical team, discussion with the project manager over the project status, preparation, and review of functional documents.
To get an idea of how you should effectively portray your typical day, read our post on A typical Day of a Business Analyst
What are the documents that you have prepared as a Business Analyst?
Through the course of a project, a BA is constantly striving to help technology achieve the business requirements and in this pursuit, he prepares a number of documents. They are :
Project vision document
Requirement Management Plan
Business Requirement Document
Requirement traceability matrix (RTM)
Functional requirement specification (FRS)/ Functional Specification Document (FSD)
System requirement specification (SRS)/ System Requirement Document (SRD)
What are the best practices you follow while writing a use case?
The following are the best practices that are followed to write a clear and well-documented use case:
Capture both functional and non-functional requirements in a use case.
Include use case diagrams along with the use case.
Include the UI details/notes in the use case.
What do you know about scope creep?
Scope creep, also known as requirement creep is a term that denotes uncontrolled changes/deviation in the project’s scope without an increase in the other resources (schedule, budget) of the project.
Scope creep is a risk to the project and is usually caused by poor project management, improper documentation of project’s requirements and poor communication between the project’s stakeholders.
What are the skills that a business analyst must possess?
A business analyst must possess fundamental skills such as elicitation skills, problem-solving skills, communication, and management skills. Alongside, he must have knowledge of IT skills, Software development understanding and domain knowledge regarding the domain he is working in.
How do you avoid scope creep?
Scope creep is a hindrance to the project’s success and could be avoided by:
Clearly documenting the scope of the project.
Following proper change management.
Informing the effects of the change to the affected parties before making a change.
Documenting the new requirements in the project log.
Refrain from adding additional features to the existing functionalities (also called Gold Plating)
Tell us the difference between an alternate flow and an exception flow of a use case?
Alternate flow are the alternative actions that can be performed apart for the basic flow and might be considered as an optional flow whereas Exception flow is the path traversed in case of the error or an exception being thrown. For e.g. on a Login page the ‘Forgot password’ is the alternate flow and system showing ‘404 error’ when correct username and password are entered is exception flow.