It is commonly said that ‘To fail to prepare, is to prepare to fail’ and Business Analyst interview is no exception.
Preparing for an interview beforehand gives you a flavor of the type of questions that might be asked in an interview, helps you understand what the interviewer would want to listen and prepares you in giving answers that are relevant based on your experience and skill-set.
We have consolidated a number of frequently asked questions in the BA interview process and have also elaborated the answers that are expected by a seasoned business analyst.
To get an access to all the 60+ interview question (along with detailed answers), don’t forget to Download the Free PDF e-book at the end.
1. 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 team work 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.
2. How do you define a requirement?
A requirement is the 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.
You can learn more about requirements here.
3. What is your requirement elicitation strategy?
The elicitation strategy depends upon the type of the project.
One can take advantage of direct collaboration with 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.
4. 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 posed in time i.e. early in the project life cycle.
5. 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 they 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 re then documented and become a part of the project scope.
6. 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 about 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 responds 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
7. 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
- Use cases
- User stories
- Business Requirement Document
- Requirement traceability matrix (RTM)
- Functional requirement specification (FRS)/ Functional Specification Document (FSD)
- System requirement specification (SRS)/ System Requirement Document (SRD)
- Test case
All these documents are explained here.
8. 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.
9. 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.
10. 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.
There is a detailed post on the key skills of a BA here.
11. How do you avoid scope creep?
Scope creep is a hindrance to the project’s success and could be avoided by:
- Clearly document the scope of the project.
- Following proper change management.
- Informing the effects of 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)
12. 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 logic page the ‘Forgot password’ is the alternate flow and system showing ‘404 error’ when correct username and password are entered is exception flow.
>> Want to be better prepared for your next BA interview? – Download the Free e-book
Don’t you wish to show up a confident face for your next Business Analyst Interview and be prepared for each and every question asked by the Interviewer?
Download our Free ‘Business Analyst Interview Questions and Answers’ e-book which contains detailed answers to 60+ tough BA interview questions. What’s more – the e-book contains a special section on Agile questions along with comprehensive answers.