Business Analyst Interview Questions

Interview Questions
Name the skills which Business Analyst should have?
Good Listener , Quick & continuous learner, Analytical skills, problem solving approach, thinking beyond the box, tech savvy   (can keep updating what are the latest technologies released in market and how those are important). Team or people management, solid communication, documenting skills (written English), team player, devising new solutions, market research etc (if know some more you can add).
What is your understanding on – Risk and Issue?
Risk is something which can be forecasted and can be handled by formulating mitigation plans.
Risk which happened is called Issue. There will be contingency management or issue management to solve issue. Basically we will be not solving the issue but will try making Damage control and take it as learning for other projects
What is an activity diagram and why is it significant?
The purpose of an activity diagram is to provide an outline of work flow in the business, including the action and activities that are completed. For example, with a company there is likely to be more than one department, with various access levels to the system. If there are departments including HR, Medical and Accounting, they only have access to the screens that relate to their work. An activity diagram will be used to highlight the differences in the departments, which is extremely helpful for developers when they are coding and designing.
What documents are used for use cases?
There are 2 documents:
FRD (functional requirement document)
SDD (system design document) which can also be called TRS (Technical requirements specifications)

                                      Tips to grow as a best Business Analyst

• Define one requirement at a time – each requirement should be atomic. Don’t be tempted to use conjunctions like and, or, also, with and the like. This is particularly important because words like these can lead to developers and testers missing out on some of the requirements. One way to achieve this is by breaking the requirement down till it can be considered a discrete test case.
• Avoid using let-out clauses like but, except and if necessary.
• Each requirement must form a complete sentence with no buzzwords or acronyms.
• Each requirement must contain a subject (user/system) and a predicate (intended result, action or condition).
• Avoid describing how the system will do something. Only discuss what the system will do. Refrain from system design. Normally, if you catch yourself mentioning field names, programming language and software objects in the Requirements Specification Document, you’re in the wrong zone.
• Ensure That Requirements Support Your Overall Business Needs: Having a list of business requirements is certainly an integral part of your long journey toward project success. However, before celebrating, you need to be absolutely certain that those requirements support your organization’s overall business objectives.
• Deliver the Right Message to the Right People: The communication of your business requirements is nearly as important as the development of those requirements. To effectively communicate requirements to your stakeholders, you need to develop a communication plan that will determine who will communicate with your stakeholders, what they will say and when and how they will say it.