1. As a Business Analyst, how does your typical day look like?
You can tailor your response based on your past experience. Here’s an example based on a maintenance project:
“Currently, I’m working on a maintenance project, and a typical day involves working on change requests shared by the customer or following up on ongoing change requests. My day usually consists of the following:
- Communicating with the customer to understand new requirements or follow up on previous changes
- Coordinating with the development team to track the progress of ongoing changes
- Preparing specifications and documentation including process diagrams, prototypes, and business rules
- Conducting functional testing before the change request moves to UAT (User Acceptance Testing)
This routine ensures efficient tracking, clarity of expectations, and successful delivery.”
2. Describe how you approach a project
This question helps employers understand your project management and analytical thinking. Here’s an example answer:
“My approach to any project starts with understanding the client’s articulated goals. I ensure that I listen actively during the initial stages to align with stakeholder expectations.
After that, I move into detailed planning and documentation. This includes preparing:
- A communication plan
- Requirements management plan
- Business analysis approach (plan-driven or change-driven depending on the project)
- Work Breakdown Structure (WBS)
I also apply business analysis techniques and modeling (like BPMN, use cases, user stories) based on project needs. Every client and project is unique, so I always strive to adapt my methods accordingly, rather than using a one-size-fits-all approach.”
You can also ask follow-up questions about their team structure and workflows to show your interest.
3. As a Business Analyst, which documents have you prepared?
Business Analysts are responsible for a wide range of documentation. Common examples include:
- Business Requirements Document (BRD)
- System Requirements Specification (SRS) – also referred to as FRD or FRS
- Use Case Specifications
- Requirements Traceability Matrix (RTM)
- Gap Analysis Document
- Change Request Logs and Documentation
- Impact Analysis Document
- RACI Matrix (Responsible, Accountable, Consulted, Informed)
These documents ensure clarity between stakeholders and the development team and form the foundation for successful project execution.
4. Elucidate the difference between Assumptions and Constraints
- Assumptions are factors considered to be true for planning, even though they may not be verified.
Example: Assuming continuous internet availability for an application with an online payment feature. - Constraints are actual limitations or restrictions affecting the solution.
Example: Time limitations in an Agile sprint that reduce the scope for full regression testing.
Assumptions and constraints are critical for project planning and are usually documented in the SRS for risk management and scheduling purposes. If an assumption proves false, it may impact the project’s timeline or quality.
5. What are Functional Requirements?
Functional requirements define the specific behavior or functions of a system—essentially, what the system should do.
Examples:
- Allowing users to register on a website
- Enabling customers to place an order on a food delivery app
These requirements are usually derived from user expectations and business needs, and they form the core of system development and testing.
