Essential Analytic, Analytical and Analysis Interview Preparation Guide

Download PDF

► Describe a time when you had to facilitate a requirements gathering activity where your stakeholders were not located in the same city. If you haven't done this before, describe to us how you will deal with this type of situation?
► Describe a situation where you used business analysis techniques to gather business requirements from stakeholders. Which techniques did you use and why did you choose those techniques?
► Describe a time when you were responsible to plan and facilitate a requirements workshop. How did you go about it?
► Describe a time when you had to win a difficult stakeholder over to accept the project change that will affect his/her department. How did you do it?
► Describe a time when you were in a project where change happened constantly without any change control to requirements. How did you deal with this situation and how did you overcome the associated challenges?
► Describe a time when you had to deal with stakeholders at all levels of the organisation. How was the message different?

► Describe a time when you had to deal with a stakeholder that just didn't want to participate in one of your requirements workshops and tried to sabotage it. What did you do?
► Describe a situation when you were unable to deliver one of your requirements documents on time. What did you do?
► Tell us about a time when you needed to gain approval for one of your business requirements documents but a stakeholder kept on delaying or postponing meeting with you?
► As a business analyst, describe your ideal project environment?
► Describe a time when you introduced a new idea or process into a project or department and how it improved the process or situation.
► Describe a situation where you had to mentor a colleague on any tool or concept. How did you approach this?

► What is contained within a typical Requirements Management Plan?
► Describe the phases of the SDLC. Which phases have you worked in?
► Describe the difference between a Waterfall based methodology and an Agile methodology?
► What is a user story in an Agile context and how is it used?
► What is a use case and when would you use it as a Business Analyst?
► What is the difference between a functional specification and a business requirements document? How are they related?
► Describe an effective way to manage change to requirements within a project?

► What is the purpose of the Business Analyst within an organisation?
► What do you believe are good attributes of a Business Analyst?
► What is the difference between a functional requirement and a non-functional requirement?
► What are the attributes of a good business requirement?
► What is the purpose of requirements trace-ability?
► When do you use a RACI or RASCI model?
► How do you ensure your business requirements are of a high quality?

A systems analyst has the ability to look at a program or utility and see the code. They can go in and pinpoint where changes need to be made.

The business analyst must understand IT and also has to understand the stakeholder's needs.

The use case diagram defines the role of each actor that is associated to a particular role or system. A use diagram is also a behavioral diagram and a part of UML.
An example of this is an "Order Management" as the main function, in such a case the person that is given the order is an actor.
Download the questions and answers here right click save as. You can read them on your tablet, mobile phone, e-reader device or anything else that can read PDF documents.

The common tools that can be used by a business analyst are MS office, MS word, MS Excel, Power point, Quality center/test director MS Project. There may be tools that are client specific also, but these will be supplied the client.

The most important responsibilities of a business systems analysts are as a communication conduit between the stakeholders and the team.

There are 2 documents:
► FRD (functional requirement document)
► SDD (system design document) which can also be called TRS (Technical
requirements specifications).

An include is where a specific action has to take place.

An extend is an action that may not necessarily take place.

This is a flow that accounts for an unexpected or unusual result within
the application process. The exception will be handled according to its designed flow.

This is the flow that will come into action, when there is a failure in the
use case system where the expected results haven't come to fruition.

UML in full means Unified Modeling Language. It is the industry standard
language for constructing, visualizing and documenting the different components within a system.

The activity diagram is important because it gives an outline of the work
flow within the business as well as the activities and action completed.
For instance with a company, there is likely to be more than one department. In such a case each department, will have different access levels to the system.
So if there's a Medical, HR and Accounts team they will only have access to screens that relate to each.
The activity diagram will highlight the differences within the departments which will be very helpful for developers when they are designing and coding.

A communication diagram or interaction diagram, is an illustration of the relationships and interactions among software objects in the Unified Modeling Language (UML). The concept is more than a decade old although it has been refined as modeling paradigms have evolved.

► Use case diagram
► Activity diagram
► Collaboration diagram.

The use case model requires a use case diagram. It describes the business
environment. Its primary goal is to show the series of events and actions within any given process that will be performed by an actor.

The flow chart gives a clear graphical representation of an implemented
process. This makes the system simple to understand for all persons involved in the project.

The 4 + 1 View Model is a predefined set of views for organizing the design and architecture of a system. It was developed in 1995 by Philippe Kruchten, formerly the Director of Process Development at Rational Software.

The 4 + 1 View Model gets its name from the 4 primary views and 1 supporting view that are used to capture and communicate different aspects of the system.

The 4 primary views are:

► Logical View: this view describes the functionality of the system in terms of its static structure and dynamic behavior.
► Development View: this view describes the system from a programmer’s perspective and is concerned with the organization of physical code, its main modules, and their dependencies.
► Process View: this view focuses on the runtime behavior of the system and the elements of the system that relate to process performance. It includes aspects important to scalability, throughput, and process response times to name a few.
► Physical View: this view shows the system from a system engineer's point-of-view. It is concerned with the deployment of software components across the physical architecture including computers and devices , as well as communication between these components.

The 1 supporting view is:

► Use Case View: this view describes the functionality of the system from the perspective of external actors.

For any new piece of work a BA (business analyst) needs to know

1. who are the key stakeholders (i.e. those who can kill the project)

2. what are the key stakeholders specific and measurable measures of success (i.e. their objectives) and what VALUE for each objective MUST be achieved in order for the project to be considered a success (e.g. increase sales per order value by 5%)

3. what are the key stakeholders unmeasured measures of success (i.e. their principles that they would like to see happen but aren't going to measure and so the project cannot be assessed by them - e.g. an intuitive solution)

4. what are the key stakeholders high level requirements (i.e. what capabilities do they expect the solution to deliver - e.g. the ability to offer add-on sales during the order taking process)

5. what is in scope of the work in terms of processes, organization units, locations, data, applications, technology

6. what is the scope of the work in terms of time, money, project resources (people and materials)

7. who will the stakeholders nominate for determining further high level requirements and detailed requirements (e.g. subject or domain experts, middle management of operational teams, etc)

The Yourdon introductory class on data flow diagramming used to (still does?) teach that 98% of the required work in requirements specification revolved around a single task. What is that task?

It depends, it depends, and it depends!

As for most questions in business analysis, there isn’t only one answer. Whose job is to create a class diagram depends on the purpose of the class diagram.

First of all, the question implies that there is only one class diagram for a given project: “The Class Diagram”. For the most part, this is not the case. On some projects there may be a multitude of class diagrams while in others there may be none.

Few analysts are brought on to a project at the very beginning. For those that are, they will often have a hand in creating some of the important documents that other analysts should reference when they first join.

First, get your hands on the project charter. The project charter, while high level, will provide critical information on the project.