BUSINESS ANALYST INTERVIEW PREPARATION



I have been working as a Business Analyst for the past 5 years in various domains like Mortgage, Banking, Insurance and Broking Management and human resources.

As a BA I have gained an in depth knowledge of the business process and the different phases of the software development life cycle. (This included requirements, analysis, design, modeling, development, testing, change and configuration management).

Being a BA I have always got to interact with people, its about being apeople person which I enjoy doing the most. Most of my projects required me interacting with the business area experts, Developers, Management, Support Staff and other stakeholders and facilitated communication between the client and IT department and have thus developed excellent co-ordination, negotiation and interpersonal skills.

From job perspective over the years I have improved my skills in requirement gathering, understanding my users rather understanding their needs, next I am also comfortable in creating and maintaining documentation. I had to think of the best format to communicate with the Information Technology Team and the best format for communicating with the business area experts.

(I divided the documentation into categories like functionality specification and detail design specification.) This came along with the tasks of ensuring that business needs were met and I used

MS Project and Rational Requisite Pro for this purpose.

I would also like to add that since most of my projects were as per the RUP methodology

I have gained an in depth knowledge of the subject due to my continued use of the concept. I have made use case diagrams and I have also made activity diagrams in Rational Rose, UML and MS Visio. I also modeled the flow of logic in a visual manner using sequence diagrams.

Well these were some skills regarding the job perspective, but apart from that being a BA has in may ways tuned my personal qualities too, I have a good verbal written skills. And excellent interpersonal skills it has in many ways improved my business approach and made me a problem finder and a creative resolver

with excellent interpersonal and communication skill. I never was involved in solving a problem but aided in many by forming a platform between the user community and the technical community.

.

As a part of my job I have got an opportunity to meet a lot of people and learn form them and with each commming day improve myself with all my skills.

In this 5 years I have worked through all the phases in the Software lifecycle.

As a BA I have gained an in depth knowledge of the business process and the different phases of the software development life cycle. (This included requirements, analysis, design, modeling, development, testing, change and configuration management).

Being a BA I have always got to interact with I have also interacted with the business area experts, Developers, Management, Support Staff and other stakeholders and facilitated communication between the client and IT department and have thus developed excellent co-ordination, negotiation and interpersonal skills.

I am also good with user requirement gathering

I had to interact with the systems analyst, management, and all the stakeholders involved in the project.

I used to talk and interview the end users and understand their business process and see how they actually performed their duties.

I used to organize informal meetings if there are two or more people to discuss the particular topic at hand. In some cases I also used surveys and questionnaires for this purpose. The most detailed questions are asked and then I wrote the User Requirements Document.

I clearly understood the business rules and effectively implemented them in Business Process Flow

I have also conducted JAD sessions for Requirement Analysis and Risk Analysis with the management and IT teams.

Sometimes these JAD sessions would be separate for the management team and IT team as the management team did not need to know details like the working of the application itself.

They would be interested in the business impact of the project and deadlines. So sometimes I would need to put a separate JAD session for them.

Usually this involved the use of power point presentations with graphs, process flow diagrams and use case diagrams.

I was involved in creating and maintaining documentation. I had to think of the best format to communicate with the Information Technology Team and the best format for communicating with the business area experts. Usually most companies had their standard documentation format which I followed. (I divided the documentation into categories like functionality specification and detail design specification.) This came along with the tasks of ensuring that business needs were met and I used MS Project and Rational Requisite Pro for this purpose.

Usually I try to identify the scope of what I am trying to model and usually only if the logic is too complex I go ahead and begin modeling.

Most of my projects were as per the RUP methodology

I have gained a in depth knowledge of the subject due to my continued use of the concept. I have made use case diagrams and I have also made activity diagrams in Rational Rose, UML and MS Visio. I also modeled the flow of logic in a visual manner using sequence diagrams.

I have also had past experience in defect tracking and maintaining history of bugs using Clear Quest. I tracked defects and change requests to target the most important enhancements in the product

I am a creative problem finder and conflict resolver with excellent interpersonal and communication skill. I never was involved in solving a problem but aided in many by forming a platform between the user community and the technical community.

On the whole, I think I have definitely had quite an all around experience with the entire project development cycle and I am sure my experience would prove to be a beneficial addition to the progress of the project.

PERSONAL QUALITIES

• A business outcome approach

• An ability to conceptualise and think creatively

• A capacity to articulate visions

• Very good oral and written communications skills

• Interpersonal skills to evoke commitment from the client

• A high standard of ethics and integrity in all dealings

• Effective selling, negotiation and customer management skills

• Sound administrative skills and good analytical and reporting abilities

• Effective time management and personal organization skills

• An understanding of user needs

How will u go ahead in gathering requirement?

▪ Firstly I would identify the key users who would be using the system. These would be users who have been affiliated to the system for a long period of time or who are currently using the system and have enough experience with using the existing system. Eg officers, loan agents, underwriters at Valley National and LoanGiant. Gather reqs from them through personal interviews, telephone conferences

▪ I used to build a JAD team to perform brainstorming sessions to collect as many ideas as we can.

What are the problems involved with obtaining requirements?

• Requirements can come from many sources.

• Requirements are not always easy to express clearly in words.

• There are many different types of requirements at different levels of detail.

• The number of requirements can become unmanageable if not controlled.

• Requirements are related to one another and also to other deliverables of the software engineering process.

• There are many interested parties, which means requirements need to be managed by cross-functional groups of people, scheduling conflicts

• Requirements change.

What is traceability?

Traceability is used to refer to the relationships between the requirements and other artifacts. It shows how one requirement traces into another.

Traceability can be used to answer questions like

• What is the impact of changing a requirement?

• Where is a requirement implemented?

• What need is addressed by a requirement?

• What test will be used to verify a requirement?

• How do I interpret this requirement?

What is requirement management?

Requirements management is a systematic approach to finding, documenting, organizing and tracking the changing requirements of a system

Keys to effective requirements management include maintaining a clear statement of the requirements, along with applicable attributes for each requirement type and traceability to other requirements and other project artifacts.

How do u get everybody to agree on the goals of the project?

Requirements are gathered thru interviews and JAD sessions. If there are conflicting requirements then I use JAD sessions to come up with a solution. In which case, we discuss the req in detail and come for an acceptable solution for both parties.

If a consensus cannot be reached then system functions are prioritized and less important requirements may be dropped.

If not possible then the possibility of creating multiple releases of the system, customized for each of the parties is considered. If it is feasible economically and there is adequate time for dev then this option may be chosen.

What is RUP?

Rational Unified Process is a generic business process for (object oriented) software engineering. It provides an approach to assign tasks and responsibilities to members of a development team. It is a set of ordered steps intended to reach a goal, to build a software product or to enhance an existing one.

Rational Unified Process has two dimensions

• Horizontal axis representing phases, iterations and milestones

• Vertical axis representing core workflows

What is an actor?

An actor is someone or something outside the system that interacts with the system. To fully understand the system's purpose you must know who the system is for, that is, who will be using the system. Different user types are represented as actors.

An actor is anything that exchanges data with the system. An actor can be a user, external hardware, or another system.

What is an artifact?

Activities have inputs and outputs called artifacts. Roles use artifacts to perform activities and produce artifacts in the course of performing activities. Artifacts can be

• A model such as a use case model

• A document such as a business case or software architect document

• Source code or executables.

Different Core Workflows involve different types of artifacts

Business Analyst: He works with the business processes and is mainly independent of technology. He holds meetings with the stakeholders, and all the teams involved in the project to manage the activities of the project and to communicate the user requirements. He also holds JAD sessions to discuss the scope of the project, resolve any conflicts, clarify any miscommunications in the requirements between departments and make sure the entire business process of the product is going smoothly.

Business Analyst/ system analyst

A business analyst works with business processes/flows, typically independant of technology. While a business analyst cares about inputs to a application, and outputs from an entire system or application, they are thinking at a higher level which includes automated steps as well as manual steps in a process. They aren't as concerned with the internals of an application - as long as they get the required result. They should treat a computer as a black box. They are spend more time focussed on the people side of the equasion.

The business analyst typcially does their work in the project definition/requirements phase. They might model the old process, look at the high level requirements and create a new process.

To be a business analyst you need broad exposure to various aspects of a business. You need interviewing skills - as you discover that to do your job you need to document things that aren't documented. You need to understand IT at a high level - but not down to the systems level.

System Analyst

More involved in the technical aspects of the process. A systems analyst on the other hand, is more concerned with what is going on within that black box. They need to be able to document how data goes from one system to another, what transformations data undergoes at what stage, what the relationships between database elements are and so on. Using class diagrams

The systems analyst needs a high level understanding of programming and a deeper understanding of data flows, data structures, and communications between systems.

Business Process

A business process is a collection of activities designed to produce a specific output for a particular customer or market. It is thus a specific ordering of work activities across time and place, with a beginning, an end and clearly defined inputs and outputs

Business Process Flow

Business Process Flow is a high level to explain a business process in detail. It is a schematic view of how a business process progresses from start to finish. To model a workflow process, one simply models the events that occur to start it off, the actions that get performed during it, and the end results of the process. Business decisions and conditional branching of the process is modelled using decision nodes.

Phases of SDLC

This included requirements, analysis, design, modeling, development, testing, change and configuration management

MS Project

MS Project is used to eliminate constraints and ensure that business needs are met. It is used to manage project schedules, tasks, resources, scopes and deadlines

Use Case Diagram

A use case illustrates a unit of functionality provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. The set of all use cases show the entire functionality of the software system. Initially - List all the different roles a user can play with respect to the software.

Use-case diagrams generally show groups of use cases — either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality (e.g., all security administration-related use cases).

To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram (and just in case you're wondering, some people draw prettier stick people than others).

Class Diagram

Used to display the main concepts of the software and their relationships. The class diagram shows how the different entities (people, things, and data) relate to each other; in other words, it shows the static structures of the system. A class diagram can be used to display logical classes, which are typically the kinds of things the business people in an organization talk about — rockbands, CDs, radio play; or loans, home mortgages, car loans, and interest rates. Class diagrams can also be used to show implementation classes, which are the things that programmers typically deal with. An implementation class diagram will probably show some of the same classes as the logical classes diagram.

Sequence diagram

Shows how the objects collaborate to achieve a use case or a small set of use cases. Sequence diagrams show a detailed flow for a specific use case or even just part of a specific use case. They are almost self explanatory; they show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects.

A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages/calls in the time order that they occur; the horizontal dimension shows the object instances to which the messages are sent.

Statechartdiagram

The statechart diagram models the different states that a class can be in and how that class transitions from state to state. It gives a better understanding of the lifetime behavior of a single object in the software. It can be argued that every class has a state, but that every class shouldn't have a statechart diagram. Only classes with "interesting" states — that is, classes with three or more potential states during system activity — should be modeled.

Activitydiagram

Activity diagrams show the procedural flow of control between two or more class objects while processing an activity. Activity diagrams can be used to model higher-level business process at the business unit level, or to model low-level internal class actions. In my experience, activity diagrams are best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business. This is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly.

Business Rules

Business Rules are a kind of requirement. There is no precise definition for a business rule as it may mean different things to different people. In some cases, a business rule refers to a sequence of events the system must provide; these are expressed as steps in a use-case description. In other cases, business rules refer to validation rules about key business entities

RUP Phases

Each phase is distinct in it's goal. Different workers can work on any workflow in any iteration, e.g., your programmer can implement a prototype in the inception phase, but it is not itself the goal for that phase.

Inception

What does the customer really want?

What is our plan for this entire release? Is it feasible?

How long will it take?

how much will it cost?

E.g., 6 weeks for v1.0.0, and 2 weeks for minor versions

Elaboration

How will the system work?

Prove to ourselves that the design is good enough.

E.g., 10 weeks for v1.0.0, and 2 weeks for minor versions

Construction

Build and test the system.

Fix problems as they are found.

Create all documentation, data, etc.

E.g., 20 weeks for v1.0.0, and 9 weeks for minor versions

Transition

Finish up the system and package it.

Prepare the customer accept it, and our company's departments to support it.

Actually ship it and support it.

E.g., 5 weeks for v1.0.0, and 1 week for minor versions

Rational ClearQuest

Tracked defects and change requests to target the most important enhancements in the product, created user/site specific charts and reports to reflect the current state of the project.

Customized and defined queries, fields, activities and states specific to application development.

Created queries and filters to monitor defect and change request records

analyzed data using Distribution( by priority, owner, severity etc) Trend (defect counts over time: month, week) and Aging (state of defects with time: defects that have been open, closed, submitted or resolved )charts.

{

Used ClearQuest designer to create custom DBs and manage the ClearQuest database.

JAD Sessions

A JAD session is a Joint Application Development Session. These JAD sessions were headed by the Program Manager of our team. It includes the PM, BAs, SAs, reps from development and QA teams, end users and other stakeholders.

The aim of the JAD sessions was to review and define the scope of Project, gather requirements for project to design a solution and discuss any other issues pertaining to the project (conflict management, req clarification)

Risk Analysis

A technique to identify and assess factors that may jeopardize the success of a project or achieving a goal. This technique also helps define preventive measures to reduce the probability of these factors from occurring and identify countermeasures to successfully deal with these constraints when they develop.

Gap Analysis

AS Is and to be by preparing a baseline to compare the situation.

Vision

Features, scope and constraints of the business.

Vision Document

Scope, features and constraints of a project.

Scope is the basic objective of the project and it defines the end goals and tasks of the project along with the work required to achieve them.

Scope: Basic objective of the project. Defines the characteristics of the project's end product as required by the sponsor. The combination of all project goals and tasks and the work required to accomplish them

Constraints: limitations, restrictions; limiting factors that should be taken into account when identifying and preparing a project proposal e.g. lack of available materials, skills, funds.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download