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 coordination, 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.