Business Analyst helps businesses in improving processes, products, services and software through data analysis, research and then making recommendations about the best feasible solutions. For the Business Analyst job interview, there may be three different rounds. The first round will be telephonic. In the second and third rounds, there may be a group of interviewers like HR, stakeholders of a technical team, higher management authorities, etc.

1. What are the main qualities of a good requirement?

Answer: Requirement quality can be measured on basis of SMART or DEEP rule.

SMART:

• Specific: The requirement should be specific enough so that it can be documented properly.
• Measurable: Should be able to measure the success criteria of the requirement by different parameters.
• Attainable: The requirement should be feasible within the scope of the given resources.
• Relevant: The requirement should be in line with the project’s business case.
• Timely: The requirement should be communicated timely i.e. early in the project lifecycle.

DEEP:

• Detailed Enough—acceptance criteria to get started
• Emergent—The Product Backlog is never “complete”; it is refined over time
• Estimated Relatively—sized in terms of effort
• Prioritized Ordered—by value, risk, cost, dependencies, etc.

2. How do you handle unfavorable situation when you had to convince Business Representative to change their decision?

Answer: As a business analyst I was involved in research and then making recommendations about the best feasible solutions. In this question the hiring manager wants to see how you can handle this situation. Standing up to a business or client and convincing them to use a different approach requires a substantial amount of skill, especially if you are sharing something the decision-maker doesn’t want to hear.

• Situation: Briefly explain the issue you were dealing with in a positive, constructive way.
• Task: Explain your role in the situation.
• Action: Explain what you did to resolve or address the situation.
• Result: Explain your learnings and how your actions resulted in a positive impact for the business.

e.g. The Business Representative is from technical background and he wants to use a particular technology which he is comfortable with but is an old technology with less flexibility and scalability. I approached the Business Representative and explained, supporting my position with data, that the technology would actually hinder productivity not just in the short-term but in the long-term as well. 

3. What are the best practices you follow while writing a use case?

Answer: The following are the best practices that are followed to write a clear and well-documented use case:

1. Capture both functional and non-functional requirements in a use case.
2. Include use case diagrams along with the use case.
3. Include the UI details/notes in the use case.

Tips for Writing Successful Use Cases

1. Develop Your Use Cases Iteratively 
2. Involve Users Directly
3. Depict Your Use Cases Visually
4. Use Your Use Cases to Harvest Nonfunctional Requirements
5. Prioritize Your Use Cases and Use Case Scenarios
6. Trace Your Use Cases
7. Verify Your Use Cases

4. What is your requirement elicitation strategy?

Answer: Elicitation is a practice of collecting requirements from end customers and stakeholders; it is a requirement-gathering process. Direct collaboration with the client, facilitated workshops, interviews, and observe the end-users are the key elicitation strategy. In conjunction, we can use techniques that provide us with more precise information like prototype and scenario building. Here are the 9 elicitation techniques defined by the BABOK for business analysts:

• Brainstorming
• Document Analysis
• Focus Groups
• Interface Analysis
• Interviews
• Observation
• Prototyping
• Requirements Workshops
• Survey/Questionnaire

5. When do you know that you have gathered all the requirements?

Answer: 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 to be completed. Additionally, it should be validated that:

• They are elicited from all the stakeholders from all the critical stakeholders of the project.
• Description of which capabilities will and will not be included in the project scope.
• They align with the project’s business case.
• Rules concerning operational decision-making that must be taken into consideration by the solution.
• 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.
• The criteria to be used to judge the quality of the solution outside its specific behaviors (requirements on response time, capacity, reliability, usability, etc.).
• The interfaces to other systems and external entities within the project scope.
• The requirements meet your organization’s test for quality. 

All the requirements which pass the above criteria are considered to be formal and final. These requirements are then documented and become a part of the project scope.

6. What is scope creep, causes & how to avoid it?

Answer:Scope creep or  requirement creep is defined as the uncontrolled or sudden changes or deviations in the project’s scope without changes in other resources (schedule, budget) of the project. Scope creep is a risk to the project and is usually caused by 

1. Ambiguous or unrefined scope definition.
2. Lack of any formal scope or requirements management.
3. Improper documentation of project’s requirements.
4. Poor estimation & lack of prioritization of features.
5. Poor communication with business sponsor & stakeholders resulting in lack of sponsorship and stakeholder involvement
6. Lack of client agreement on the scope.
7. Project length

Scope creep is a hindrance to the project’s success and could be avoided by:

• Clearly documenting the scope of the project. e.g. Scope statements should include both features in and out of scope. Use progressive elaboration.
• Following proper requirement & change management e.g. processes for scope modeling, analysis, prioritization, traceability, and 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)
• Engage business sponsor & stakeholders. e.g. Sponsors should develop project charters to keep ownership where it belongs. Project status should be reported to engages sponsors & bring focus on progress towards the deliverables 
• Decompose projects into smaller sub-projects. Educate sponsors to chunk projects into shorter sub-projects and to focus on tight deliverables.

7. What all steps are included in developing a product from a basic idea?

Answer: In the process of developing a product from an idea, there are many steps to be followed as enlisted below,

• Market Analysis: This is a business plan through which the characteristics of a market have been studied, like how the market changes and behaves dynamically.
• SWOT Analysis: This is a process through which the Strengths, Weaknesses, Opportunities, and Threats of an organization are identified.
• Personas: These are typical users of websites or intranet who represents the goals and characteristics of various large groups of users. Personas replicate the real users in functional design.
• Competitor Analysis: Evaluation of the strengths and weaknesses of outside competitors.
• Strategic Vision and Feature set: The process of developing the goals in present and planning to achieve the same in the future by moving towards the vision.
• Prioritize Features: All the features of the product that is to be developed are prioritized by the product management to help the development team.

8. Explain the business analysis process flow.

Answer: The process of Business Analysis is generally divided into multiple steps with each step involving specific tasks to perform, principles to follow and documents to produce. 

1. Gather Background Information – PESTLE Analysis, Porter’s Five Forces framework 
2. Identify the key stakeholders – Stakeholder Matrix (Owners, Managers, Employees, Regulators, Suppliers, Partners, Customers, Competitors)
3. Discover business objective – Business Objectives List  (Benchmarking, SWOT Analysis , Focus groups and brain storming, Making business objectives SMART etc)
4. Evaluate available options – Business Case Document (Cost-benefit analysis, Impact analysis, Risk analysis etc)
5. Scope definition – Scope Definition Document
6. Define the delivery plan – Delivery Plan
7. Define project requirements – Functional & Non-functional Requirements (Interviewing the stakeholders, Requirements defining techniques etc)
8. Implementation by SDLC
9. Evaluate Value Added By Project – Actual progress across the timeline and business objectives

9. What are the various diagrams that you know about?

Answer: There are various types of diagrams that BA’s use in their work.

Few important diagrams among them are,

a) Activity Diagram: This represents the flow from one activity to the other activity. Activity refers to the operation of the system.

b) Data Flow Diagram – Graphical representation of the flow of data into and out of the system. This diagram represents how data is shared between organizations.

c) Use case Diagram: This diagram describes the set of actions that systems perform with one or more actors (users) of the systems. Use Case diagram is also called as a Behavioral diagram.

d) Class Diagram: This is the structural diagram that represents the structure of the system by showing its classes, objects, methods or operations, attributes, etc. A class diagram is the main building block for detailed modeling which is used for programming.

e) Entity Relationship Diagram – ER Diagram is the graphical representation of entities and the relationships between them. This is a data modeling technique.

f) Sequence Diagram: Sequence diagram describes the interaction between the objects like how they operate and in what time sequence the messages flow from one object to the other.

h) Collaboration Diagram: Collaboration diagram represents the communication that occurs between the objects by showing the messages flow among them.

10. What is business modeling & business process modeling?

Answer:A project will involve a set of activities from start to finish. A critical path is the set of activities which includes the longest path in the whole project. So, a critical path analysis is a key component in reducing project timelines and controlling cost.

Business modeling is identifying the value proposition for a business and then building a step-by-step approach for operating the business. This step-by-step approach is known as business modeling. It includes vision, mission, and strategies to achieve the goals.

11. What is an Activity Diagram?

Answer:Activity Diagrams describe how activities are coordinated to provide a service which can be at different levels of abstraction. Typically, an event needs to be achieved by some operations, particularly where the operation is intended to achieve a number of different things that require coordination, or how the events in a single use case relate to one another, in particular, use cases where activities may overlap and require coordination. It is also suitable for modeling how a collection of use cases coordinate to represent business workflows

1. Identify candidate use cases, through the examination of business workflows
2. Identify pre- and post-conditions (the context) for use cases
3. Model workflows between/within use cases
4. Model complex workflows in operations on objects
5. Model in detail complex activities in a high level activity Diagram

12) Differentiate an alternate flow and exception flow of a use case diagram?

Answer: Basic flow represents the activities carrying out in order as required by the business. Alternate flow represents actions that are performed apart from the basic flow and also be considered as an optional flow. Whereas Exception flow is executed in a case or any errors.

Example: When we open a login page of any website, there is a link “forgot password” to retrieve the password. This is called an alternate flow.

In the same login page if we enter the correct username and password, sometimes we get an error message stating “404 error”. This is called the exception flow.

13. Why would the Business Analyst use Kano Analysis?

Answer: Kano Analysis refers to the process of analyzing a product or system requirements to determine what the perceived impact will be on customer satisfaction.

The Kano model categorizes product attributes or system requirements into 3 categories to determine the perceived customer satisfaction.

Unexpected Delights: These are attributes of a product or system that the customer doesn’t even know they need or want.  The absence of these has no impact on customer perception or satisfaction.  However, the existence of these results can delight customers and drive premium pricing.

Performance Attributes: These are attributes of a product or system that follow a fairly direct correlation to customer satisfaction levels, either positive or negative.  If these attributes are missing or of poor quality then customers will be dissatisfied.  However, the better these attributes are the more the customer’s satisfaction levels rise.

Must Have Attributes: These are attributes of a product or system that if missing would be considered unacceptable and result in dissatisfaction.  However, the existence of the attribute or improvement on it wouldn’t increase customer satisfaction in any meaningful way.

14. What is meant by Benchmarking?

Answer: The entire process of measuring the quality of policies, programs, products, rules and many other measures of a company against the standard measures set for those attributes or against the other similar companies is termed as benchmarking in BA.

15. What is UML modeling & objective of using UML in business analysis?

Answer: UML is a Unified Modelling Language. UML is normal that the business practices for envisaging, recording, and building numerous components of a system. It is a modelling standard cast-off mainly for software development, but can also be used for additional theoretical models such as relating job roles, occupational procedures, and administrative functions.

For Business Analysts, UML is able to signify necessities with use cases, class plan, and state drawings. For Business Analysts, the significant part of considering UML is in thoughtful the drawing tools and when and in what way to use them greatest.

UML business analysis is needed for the following reasons:

• To define the system behavior.
• To detect the errors.
• To propose design plans to stakeholders.

16. What is the difference between a Data Analyst and a Business Analyst? 

Answer:

• A data analyst has more problem-solving skills, while a business analyst has decision-making skills.
• A data analyst generally plays an operational role, and business analyst plays a strategic role in an organization.
• A data analyst should know statistics, SQL, data mining, etc., while a business analyst should be familiar with BI, analytics, data warehouse, etc.

17. Mention a few important agile metrics to consider by business analysts? 

Answer:

• Velocity
• The sprint Burn-down matrix
• The priority of the work
• Work category allocation
• The cumulative flow diagrams
• Defect removal awareness
• Business value delivered
• Time coverage
• Defect resolution time

18. What are the popular techniques for requirement prioritization?

Answer: Here are the following techniques that can be used for the requirement prioritization.

• MoSCoW Technique
• Requirements Ranking Method
• 100-dollar method
• Kano Analysis & More
• Five Whys

19. Differentiate between Risk and Issue?

Answer: Risk: Risk is something which you can forecast and can handle by formulating mitigation plans.

Issue: Risk which happened is known as Issue. Once the problem has occurred, it is solved by contingency management or Issue management. Generally, issues are not resolved, but you can get a lesson from there for other projects.

Example: On some roads, few caution boards are stating that “Road under repair, take diversion”. This is called Risk.

If we travel through the same route which is under construction, then this may cause some damage to the vehicle. This is called an issue

20. How Would You Make Most Sense Out Of The Business Requirements To The Developers?

Answer : The following steps will detail out the procedural way of professionally dealing with this:

• Identify the scope of the project.
• Take out the key features expected by the client. Reason out the most critical aspects of the system that has to be built.
• Depict the business use oriented UML diagram and derive it further to the specificity of what is needed from the technology side of development.
• Detail out the use cases that will make the input from client clear to the developers. Refinement should always be done with peer discussions.
• Activity, work-flow and data-flow diagrams are of immense importance in detailing out the requirement. Identifying the best modeling technique and representation of the deciphered Client input will finally go through to the Development team across series of meetings

21. What is the difference between a Business Requirements Documents (BRD), a Functional Requirements Document (FRD) and a Technical Requirements Document (TRD)?

Answer : This is a tricky question! Be cautious here, as there is a movement away from the idea of building a one-off big BRD, FRD or TRD, in favour of “just in time” evolution of detail (This is the Agile approach). In general terms (as there is not a one-size-fits-all standard):

• A BRD explains what the business requirements are.
• A FRD explains the business requirements in more detail and may describe how they can be achieved.
• A TRD is the Technical Designer’s detailed interpretation of how, technically, the requirements will be met.

22. What does INVEST stand for? What can you tell me about MoSCoW prioritization?

Answer : INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized Appropriately and Testable. It is a way to check the effectiveness of User Stories by building them to these criteria. Bill Wake is the author to note in association with this.

MoSCoW is a time-dependent way of looking at requirements priorities in terms of:

• Must Have
• Should Have
• Could Have
• Won’t Have this time

It is fully described as a part of the DSDM Agile Project Framework but widely used by other agile approaches.

23. What are the skills that a business analyst must possess?

Answer: We can broadly categorize the skills of a business analyst in three types:

• Fundamental skills
• Technical skills
• Business Analysis skills

For each of the above categories a business analyst should possess some skills as mentioned below:

24. Are you aware of JAD?

Answer : Joint Application Development (JAD) consists of a structured workshops session between end user/client, project manager, business analyst, technical team and subject matter experts (SME) to facilitate the design and development of the product.

Applications developed through JAD development approach has higher customer satisfaction and less number of errors as the end user is directly involved in the development process.

25. What are the different testing techniques you use?

Answer : The aim of testing is to verify and validate the quality of a developed functionality according to the project requirements. A BA does various types of testing, which are:

Black box testing: This is a functional testing where a BA validates that the output generated by the system is as per the requirements/use case

Unit Testing: A BA does unit testing on a developer’s machine to make sure the requested functionality is being achieved.

Integration Testing: This type of testing is done when more than one piece of code are integrated to realize a functionality. A BA does integration testing to make sure than the system is performing as expected after different modules are integrated.

Functional Testing: A BA is expected to conduct functional testing to validate that the system is achieving the functionality specified in the use case/functional requirement specification document (FRS).

Acceptance Testing: A BA along with the client, does the acceptance testing to validate that the system is performing as per the business requirements and the product’s acceptance criteria. Regression Testing: Regression testing is done after a modification has been made to the existing system. Its aim is to make sure that all the system functionalities are working as expected.

Beta Testing: A BA along with the testing team, does the beta testing and it is done on a pre-production version of the product. This testing is done to make sure that the functional and non-functional requirements of the system are met.

Interview Q & A: Click Here