Business Analyst Documentation

Documentation on Business Analyst
Contents:
1. Who is business analyst? What are the job responsibilities of
Project Analyst?
2. What is business analysis?
3. Do's and Don’ts of BA?
4. Skills Required for BA?
5. What is SDLC and How BA is involve in each Phase?
6. UML Diagrams?
7. Tools used by BA?

Who is business analyst? What are the job responsibilities of Project
Analyst?
A project analyst is an individual that analyzes reviews and documents the requirements of a
project throughout its lifecycle. He or she helps the entire project team complete the project
within its planned scope, schedule and budget, while serving as a liaison for the project's
technical, functional and non-functional teams.
Project analyst job responsibilities include:
 Creating, managing and disbursing reports related to the project
 Maintaining project assets, communications and related database(s)
 Evaluating and monitoring the overall project
 Reviewing and reporting the project’s budget and finances
 Routinely performing complete or component analysis
 Notifying the entire project team about abnormalities or variances
What is business analysis?
Business analysis is a research discipline of identifying business needs and determining
solutions to business problems. Solutions often include a software-systems development
component, but may also consist of process improvement, organizational change or strategic
planning and policy development. The person who carries out this task is called a business
analyst or BA.
Business analysts do not work solely on developing software systems. Those who attempt to do
so, run the risk of developing an incomplete solution
Do's and Don’ts of BA?
#1 – Good Business Analysts Have the Basics Covered
Good BAs are good communicators, problem-solvers, and think critically. They can create
requirements specifications, analyze requirements, create visual models, facilitate elicitation
sessions, and use the necessary business analyst tools.
This is the foundation…But then you must do a little more.
#2 – Good Business Analysts are Resourceful
Business analysts know how to find the answers to questions and don’t wait for the answers to
come to them. They find alternative paths through the organization and involve the right people

at the right time. Good business analysts rarely get stopped for long and can often work through
challenging situations to come through to a solution.
#3 – Good Business Analysts Grow their Toolbox of Skills
Good business analysts are not content to do the same things the same way every time. For a
long time, I applied use cases in every requirements situation. Gaining confidence to apply wide
variety of business analysis techniques increased my marketability and made me more efficient.
Good BAs select the right tool for the job instead of relying on their go-to tools and making it
work for every situation.
#4 – Good Business Analysts Create Alignment and Ownership around the
Solution
It’s really easy to be the one who writes down what the stakeholders ask for. And as a new BA,
you might be in a role where you are expected to do this or where it’s the biggest contribution
you can make at first.
But good business analysts do more. And this means that you are in the middle of resolving
conflicts and ensuring that when the solution is delivered, the business truly owns that this is
what they wanted and is prepared to use it.
Understanding the business process or the underlying problem to be solved can lead you in this
direction. So can creating clarity, which we’ll talk about next.
#5 – Good Business Analysts Create Clarity
Business analysts bring a unique blend of critically important soft skills and analysis skills.
Together these two skill sets help the business analyst create clarity. And clarity does not simply
mean that you get sign-off on the spec.
A good business analyst doesn’t rely on sign-offs and hundred-page documents. They use
analysis techniques to drill into details and ask relevant questions. They get, not just sign-off,
during the verification and validation process. And they get into the appropriate details to ensure
true clarity emerges.
#6 – Good Business Analysts Don’t Rely on Cookies
Yes, developers and stakeholders like cookies. Who doesn’t? It’s nice to feel appreciated for all
of your hard work. But good business analysts don’t rely on bribes to build and sustain positive
relationships.

 They use active listening techniques to ensure stakeholders feel heard.
 They set clear expectations as a way to build trust, consistently follow through on their
commitments, and don’t make promises they can’t keep.
 They honor confidentiality agreements, never talk behind anyone’s back, and are generally seen
as above office gossip.
Good business analysts are both professional and good to work with.
#7 – Good Business Analysts Have a Strong Dash of Project Management
This might sound like a bit of heresy, so let me explain. Good BAs are not only not project
managers but they understand with perfect clarity why they are not project managers .
That being said, good business analysts know how to manage within business analysis.
 They are proactive and dependency aware.
 They manage themselves to commitments and deadlines.
 They get stakeholders involved at the right times and in the right ways and keep everything
moving.
And more than all of this, good business analysts have a strong eye for scope. While it can be fun
to figure out what we might pack if everything but the kitchen sink fits into the car, good
business analysts realize that implementation constraints nearly always get in the way of
achieving the full vision the first time out. And so they keep a close eye on value and feasibility
and guide their stakeholders toward a set of requirements that can actually get implemented.
What Important Business Analyst Skills are required for new BA?
What follows is the list of the most critical business analysis skills for new business analysts to
bring to the table – organized into the categories of core skills, business analysis skills, soft
skills, and skills that can be required for specific types of BA jobs.

Core Skills
Typically if business analysis is a good career choice, you’ll be able to tick off these skills (or be
extremely excited to go to work right away on improving these skills just because they sound
interesting).
Communication Skills
Business analysts must be good communicators. This means they can facilitate working
meetings, ask good questions, listen to the answers (really listen), and absorb what’s being
said. In today’s world, communication does not always happen face-to-face. The ability to be a
strong communicator in a virtual setting (via conference calls or web meetings) is equally
important.
Problem-Solving Skills
No project is without problems. In fact, the entire project is a solution to a problem. At the
highest level, BAs facilitate a shared understanding of the problem, the possible solutions, and
determine the scope of the project. You’ll also find BAs in the midst of facilitating teams to
solve technical challenges, especially when they involve negotiation between multiple business
or technical stakeholders.
Critical Thinking Skills
Business analysts are responsible for evaluating multiple options before helping a team settle on
a solution. While discovering the problem to be solved, business analysts must listen to
stakeholder needs but also critically consider those needs and ask probing questions until the real
need is surfaced and understood. This is what makes critical thinking and evaluation skills
important for new business analyst.
While communication, problem-solving, and critical thinking skills are core to being a good BA,
they are not all that’s required. Let’s look at the skills specific to the business analysis profession
next.
Business Analysis Skills
The following skills are specific to the business analyst role, but even as a new business analyst
or someone looking to enter the profession, you’ll see it’s possible you have related transferable
experience (and therefore skills) doing similar work under a different title.
(By the way, this is something I can help you do a deep dive into. a virtual, self-study course
that walks you through the 8-step business analysis process.)

Documentation and Specification Skills
While documentation or writing could be considered a subset of written communication, it’s
really its own skill set for a BA. Here I include the ability to create clear
and concise documentation (the latter becoming increasingly necessary in a lean or agile world).
As a new business analyst, you may not have experience in a variety of business analyst
specifications (that comes with time and a variety of project experiences) but it’s quite possible
that your strong general documentation and writing skills will get you started.
And it will be easier to get into your first BA role if you can correlate your past experience
in something very similar to a formal BA specification to the kinds of specifications required for
any given position. And this is possible even if you’ve never worked in a formal environment.
Analysis Skills
Business analysts use a variety of techniques to analyze the problem and the solution. As a new
BA, you might find that you naturally see gaps that others gloss over and identify the
downstream impact of a change or new solution. As you mature as a BA, you’ll use a variety of
techniques to conduct analysis and deconstruct the problem or solution. Examples include use
cases, business process models, and decision models.
In this skill area, we see many cases where professionals have related experience in analyzing
problems using different techniques. Your experience is transferable and can be expanded by
applying some of the BA techniques in your current work.
Visual Modeling
A close sister to many analysis techniques is the ability to create visual models, such as work-flow
diagrams or wireframe prototypes. For any given analyst role, there could be specific
models you need to create. As a general skill set, it’s important to be able to capture information
visually – whether in a formal model or a napkin drawing.
Facilitation and Elicitation Skills
BAs facilitate specific kinds of meetings. The most common kinds of elicitation sessions a BA
facilitates are interviews and observations. In some more advanced roles, the meetings are called
“JAD sessions” or “requirements workshops.”
Most new BAs have experience running very similar meetings or facilitating discussions that can
is transferable into elicitation experience.

Business Analysis Tools
As a new business analyst, the ability to use basic office tools such as Word, Excel, and
PowerPoint should be sufficient to get you into the profession.
Other technical skills include the ability to use modeling tools, such as Visio or Enterprise
Architect, requirements management tools, such as DOORS or Caliber, or project and defect
management tools (there are really too many to list these days). It’s unlikely you’ll find these to
be required skills for a large number of positions and they will be skills you learn on-the-job.
And as important as it is to have specific business analyst skills, no list of BA skills would be
complete without the soft skills required to be successful as a BA. Let’s discuss those next.
Key Soft Skills for Business Analysts
Like the core skills, you might find that you already have many of these skills in your repertoire.
However, these skills are listed separately because they may not be intrinsic to the roles you’ve
had in the past. You may need to actively seek out improving in these areas as you move into
your first business analyst role.
Relationship-Building Skills
First and foremost on the list of soft skills is the ability to forge strong relationships, often
called stakeholder relationships. A stakeholder is simply anyone who has something to
contribute to your project and often you’ll work with many stakeholders from both the business
and the technical teams.
This skill involves building trust and often means stepping into a leadership role on a project
team to bridge gaps.
Self-Managing
While BAs are not project managers, the most successful BAs manage the business analysis
effort. This means that the BA is proactive and dependency-aware. It also means they manage
themselves to commitments and deadlines; a skill set which can involve influence, delegation,
and issue management.
A Thick Skin
BAs receive a barrage of feedback – on their documentation and proposed solutions. To succeed
as a business analyst you need to be able to separate feedback on your documents and ideas from
feedback on you personally.

A Paradoxical Relationship with Ambiguity
Deep down, business analysts despise ambiguity. Ambiguities in requirements specifications
lead to unexpected defects. Ambiguities in conversation lead to unnecessary conflict. At every
stage of a project, you’ll find a BA clarifying and working out ambiguities.
Elicitation Technics?
Ask Questions to Obtain information
Putative Questions:
Answer
Matchs
Asks about a situation in a way that tests your model of the domain
Types of questions as Tools:
Whyusually leads to deeper Motivations, Information on structure.
WhatUsually Leads to Facts.
HowUsually Leads to a Discussion of Process, not Structure.
Build Information into Your Model
Figure out where the ambiguity or
Problem Is
Pose Putative Questions
Wrong
Answer

CouldMaximally Open, Might lead to no Data.
REQUIREMENT ELICITATION
• Collecting the information and the requirements using various techniques like
a) Interviewing the client (requirements)
b) Brain storming sessions (finalising the documents)
c) Questionnaires (open ended - detailed / closed ended - single word)
d) Workshop (activity discussion)
e) Prototyping (look & feel of how the end product should be)
f) JAD sessions (bringing business users and IT team together on a common platform)
What is SDLC and How BA is involve in each Phase?
System Development Life Cycle is the process of developing, implementing, and retiring
information systems through a multistep process from initiation, analysis, design,
implementation, and maintenance to disposal. It helps in establishing a system project plan,
because it gives an overall list of processes and sub-processes required for developing a system,
which means that it is a combination of various activities. In the System Analysis
and Design terminology, the system development life cycle also means software development
life cycle.

BA has its own role to play in each phase if SDLC:
a. Analysis: The most important phase for a BA, where he-she does lot of analysis around the
requirement feasibility, requirements elicitation, requirements validation, stakeholder analysis
(identification, classification, engagement), requirements management, use case analysis,
documentation etc.
b. Design Phase: Here, BA actually gives shape, present the requirements in an user friendly
interface. The process can be started by initial level of wireframes preparation by BA himself
and later on converting them into HTMLs with the help of web designers.
c. Implementation: Here, the development of the requirements actually starts and BA ensures
that whether the development is as per the requirement or not. The BA reviews the development
from time to time with managers.
d. Verification: Once the QA process is completed by the related team, the final Business User
Acceptance is performed by the BA so as to make sure that everything looks fine.
e. Maintenance: BA here actually does the requirement management and prepares for the next
phase or changing requirements.
Various System Development Life Cycle models are:
1. Waterfall Software Development Life Cycle Model

2. Prototyping Software Development Life Cycle Model
3. Iterative Enhancement Model
4. The Spiral Model
5. Object Oriented Methodology
6. V- Model Methodology
7. Joint application development (JAD)
8. Rapid application development (RAD)
Waterfall Model:
The Waterfall Model is a popular version of the Systems Development life cycle model for
Software Engineering. It is a linear sequential model. Waterfall development has different goals
for each phase of development. Once a phase of development is completed, the development
proceeds to the next phase and there is no backtracking. The basic steps involved in this model
are:
The stages of the Waterfall Model are:
1. Analysis/Requirement Gathering
This step is the most important of the entire model because it involves gathering
information about customer requirements and defining them in the clearest possible
terms, the problem that the product is expected to solve. This step includes understanding
customer's business context and constraints, functions that must be performed by product
and the external systems it must be compatible with. The result obtained from the

analysis done is typically captured in a formal requirement specification that later on
serves as input to the next step.
2. Designing
This step includes "defining the hardware and software architecture", components,
modules, interfaces and data to satisfy given requirements". It also involves specifying
performance and security parameters, selecting the IDE and programming language and
indicating strategies to deal with issues such as exception handling, resource management
and interface connectivity. The result of this stage is used in the next stage of
implementation.
3. Coding
In this step, the work is intended to set up the defined modules or units and the actual
coding begins. The system is first developed in smaller portions. These smaller portions
are called "units". Later on these units are integrated to form the complete software
package.
4. Testing
In this stage, both individual components and the integrated whole are methodologically
verified to ensure that they are error free and fully meets the requirements defined in the
first step "Analysis/Requirement Gathering". Three types of testing is done: unit testing
of single code modules, system testing of integrated products and acceptance testing
formally done by or on behalf of the customer. If defects are found then they are logged
and feedback is provided to the implementation team for correction.
5. Implementation
This step includes the actual construction of the product as per the design specification
developed in the previous steps. In this step, programmers, interface designers and other
specialists are involved using tools such as compilers, debuggers, interpreters and media
editors. The output of this step is one or more product components, built according to a
pre-defined coding standard and debugged, tested and integrated to satisfy the system
architecture requirements.
6. Maintenance
This step occurs after installation and involves making modifications to the system or an
individual component to alter attributes or improve performance. These modifications
arise either due to change requests initiated by the customer, or defects uncovered during
live use of the system. Every change made to the product during the maintenance cycle is

recorded and a new product release is performed to enable the customer to gain the
benefit of the update.
Advantages
The Waterfall Model is the oldest and most widely used model in the field of software
development. There are certain advantages of this model that makes it, one of the most widely
used models as yet. Some of them are:
 Being a linear model, so easy to understand and implement.
 Fixed requirements.
 The amount of resources required to implement this model is minimal.
Disadvantages
With so many advantages at hand, the Waterfall Model has some disadvantages. Here are a few:
 For long duration projects, requirements may change, therefore there is a potential
reduction of the acceptability of the product.
 Testing is postponed to the later stage until coding is completed.
 The working model is not seen until later stages.
Iterative Enhancement Model:
In Iterative model, iterative process starts with a simple implementation of a small set of the
software requirements and iteratively enhances the evolving versions until the complete system
is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which is
then reviewed in order to identify further requirements. This process is then repeated, producing
a new version of the software at the end of each iteration of the model.
Iterative Model design
Iterative process starts with a simple implementation of a subset of the software requirements
and iteratively enhances the evolving versions until the full system is implemented. At each
iteration, design modifications are made and new functional capabilities are added. The basic
idea behind this method is to develop a system through repeated cycles (iterative) and in smaller
portions at a time (incremental).
Following is the pictorial representation of Iterative and Incremental model:

Iterative and Incremental development is a combination of both iterative design or iterative
method and incremental build model for development. "During software development, more than
one iteration of the software development cycle may be in progress at the same time." and "This
process may be described as an "evolutionary acquisition" or "incremental build" approach."
In incremental model the whole requirement is divided into various builds. During each iteration,
the development module goes through the requirements, design, implementation and testing
phases. Each subsequent release of the module adds function to the previous release. The process
continues till the complete system is ready as per the requirement.
The key to successful use of an iterative software development lifecycle is rigorous validation of
requirements, and verification & testing of each version of the software against those
requirements within each cycle of the model. As the software evolves through successive cycles,
tests have to be repeated and extended to verify each version of the software.
Iterative Model Application
Like other SDLC models, Iterative and incremental development has some specific applications
in the software industry. This model is most often used in the following scenarios:
 Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some functionalities or requested enhancements
may evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development team while working on
the project.
 Resources with needed skill set are not available and are planned to be used on contract basis for
specific iterations.
 There are some high risk features and goals which may change in the future.

Agile Model:
Agile SDLC model is a combination of iterative and incremental process models with focus on
process adaptability and customer satisfaction by rapid delivery of working software product.
Agile Methods break the product into small incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves
cross functional teams working simultaneously on various areas like planning, requirements
analysis, design, coding, unit testing, and acceptance testing.
At the end of the iteration a working product is displayed to the customer and important
stakeholders.
What is Agile?
Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In agile the tasks are divided to time
boxes (small time frames) to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each
build is incremental in terms of features; the final build holds all the features required by the
customer.
Here is a graphical illustration of the Agile Model:

Agile thought process had started early in the software development and started becoming
popular with time due to its flexibility and adaptability.
The most popular agile methods include Rational Unified Process (1994), Scrum (1995), Crystal
Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven
Development, and Dynamic Systems Development Method (DSDM) (1995). These are now
collectively referred to as agile methodologies, after the Agile Manifesto was published in 2001.
Following are the Agile Manifesto principles
 Individuals and interactions - in agile development, self-organization and motivation are
important, as are interactions like co-location and pair programming.
 Working software - Demo working software is considered the best means of communication
with the customer to understand their requirement, instead of just depending on documentation.
 Customer collaboration - As the requirements cannot be gathered completely in the beginning
of the project due to various factors, continuous customer interaction is very important to get
proper product requirements.
 Responding to change - agile development is focused on quick responses to change and
continuous development.
Agile Vs Traditional SDLC Models
Agile is based on the adaptive software development methods whereas the traditional SDLC
models like waterfall model are based on predictive approach.
Predictive teams in the traditional SDLC models usually work with detailed planning and have a
complete forecast of the exact tasks and features to be delivered in the next few months or during
the product life cycle. Predictive methods entirely depend on the requirement analysis and
planning done in the beginning of cycle. Any changes to be incorporated go through a strict
change control management and prioritization.
Agile uses adaptive approach where there is no detailed planning and there is clarity on future
tasks only in respect of what features need to be developed. There is feature driven development
and the team adapts to the changing product requirements dynamically. The product is tested
very frequently, through the release iterations, minimizing the risk of any major failures in
future.
Customer interaction is the backbone of Agile methodology, and open communication with
minimum documentation are the typical features of Agile development environment. The agile
teams work in close collaboration with each other and are most often located in the same
geographical location.

UML Diagrams:
We prepare UML diagrams to understand a system in better and simple way. A single diagram is
not enough to cover all aspects of the system. So UML defines various kinds of diagrams to
cover most of the aspects of a system.
There are two broad categories of diagrams and then are again divided into sub-categories:
 Structural Diagrams
 Behavioral Diagrams
Use case Diagram:
Use case diagrams are a set of use cases, actors and their relationships. They represent the use
case view of a system.
A use case represents a particular functionality of a system.
So use case diagram is used to describe the relationships among the functionalities and their
internal/external controllers. These controllers are known as actors.
Overview:
To model a system the most important aspect is to capture the dynamic behavior. To clarify a bit
in details, dynamic behavior means the behavior of the system when it is running /operating.
So only static behavior is not sufficient to model a system rather dynamic behavior is more
important than static behavior. In UML there are five diagrams available to model dynamic
nature and use case diagram is one of them. Now as we have to discuss that the use case diagram
is dynamic in nature there should be some internal or external factors for making the interaction.
These internal and external agents are known as actors. So use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the system/subsystem of
an application. A single use case diagram captures a particular functionality of a system.
So to model the entire system numbers of use case diagrams are used.
Purpose:
The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition
is too generic to describe the purpose.
Because other four diagrams (activity, sequence, collaboration and Statechart) are also having
the same purpose. So we will look into some specific purpose which will distinguish it from
other four diagrams.

Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. So when a system is
analyzed to gather its functionalities use cases are prepared and actors are identified.
Now when the initial task is complete use case diagrams are modeled to present the outside view.
So in brief, the purposes of use case diagrams can be as follows:
 Used to gather requirements of a system.
 Used to get an outside view of a system.
 Identify external and internal factors influencing the system.
 Show the interacting among the requirements are actors.
How to draw Use Case Diagram?
Use case diagrams are considered for high level requirement analysis of a system. So when the
requirements of a system are analyzed the functionalities are captured in use cases.
So we can say that uses cases are nothing but the system functionalities written in an organized
manner. Now the second things which are relevant to the use cases are the actors. Actors can be
defined as something that interacts with the system.
The actors can be human user, some internal applications or may be some external applications.
So in a brief when we are planning to draw an use case diagram we should have the following
items identified.
 Functionalities to be represented as an use case
 Actors
 Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we have to follow the following guidelines to draw an efficient use
case diagram.
 The name of a use case is very important. So the name should be chosen in such a way so
that it can identify the functionalities performed.
 Give a suitable name for actors.
 Show relationships and dependencies clearly in the diagram.
 Do not try to include all types of relationships. Because the main purpose of the diagram
is to identify requirements.
 Use note whenever required to clarify some important points.
The following is a sample use case diagram representing the order management system. So if we
look into the diagram then we will find three use cases (Order, Special-order and Normal Order)
and one actor which is customer.

The Special-order and Normal Order use cases are extended from Order use case. So they have
extends relationship. Another important point is to identify the system boundary which is shown
in the picture. The actor Customer lies outside the system as it is an external user of the system.
Where to Use Case Diagrams?
As we have already discussed there are five diagrams in UML to model dynamic view of a
system. Now each and every model has some specific purpose to use. Actually these specific
purposes are different angles of a running system.
So to understand the dynamics of a system we need to use different types of diagrams. Use case
diagram is one of them and its specific purpose is to gather system requirements and actors.
Use case diagrams specify the events of a system and their flows. But use case diagram never
describes how they are implemented. Use case diagram can be imagined as a black box where
only the input, output and the function of the black box is known.
These diagrams are used at a very high level of design. Then this high level design is refined
again and again to get a complete and practical picture of the system. A well-structured use case
also describes the pre-condition, post condition, exceptions. And these extra elements are used to
make test cases when performing the testing.
Although the use cases are not a good candidate for forward and reverse engineering but still
they are used in a slight different way to make forward and reverse engineering. And the same is
true for reverse engineering. Still use case diagram is used differently to make it a candidate for
reverse engineering.

In forward engineering use case diagrams are used to make test cases and in reverse engineering
use cases are used to prepare the requirement details from the existing application.
So the following are the places where use case diagrams are used:
 Requirement analysis and high level design.
 Model the context of a system.
 Reverse engineering.
 Forward engineering.
Activity Diagram:
Activity diagram describes the flow of control in a system. So it consists of activities and links.
The flow can be sequential, concurrent or branched.
Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared
to capture the entire flow in a system.
Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have
an idea of how the system will work when executed.
Note: Dynamic nature of a system is very difficult to capture. So UML has provided features to
capture the dynamics of a system from different angles. Sequence diagrams and collaboration
diagrams are isomorphic so they can be converted from one another without losing any
information. This is also true for state chart and activity diagram.
Overview:
Activity diagram is another important diagram in UML to describe dynamic aspects of the
system.
Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system.
So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent. Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.
Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behavior of the system. Other four diagrams are used to show the message flow from
one object to another but activity diagram is used to show message flow from one activity to
another.

Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing dynamic nature of a system but they are also used to construct the executable system
by using forward and reverse engineering techniques. The only missing thing in activity diagram
is the message part.
It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.
So the purposes can be described as:
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.
How to draw Activity Diagram?
Activity diagrams are mainly used as a flow chart consists of activities performed by the system.
But activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.
Before drawing an activity diagram we must have a clear understanding about the elements used
in activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how
they are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:
 Activities
 Association
 Conditions
 Constraints
Once the above mentioned parameters are identified we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.
The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.
The following diagram is drawn with the four main activities:
 Send order by the customer
 Receipt of the order
 Confirm order

 Dispatch order
After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.
Where to use Activity Diagrams?
The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does not include
messages.
The activity diagram is suitable for modeling the activity flow of the system. An application can
have multiple systems. Activity diagram also captures these systems and describes flow from one
system to another. This specific usage is not available in other diagrams. These systems can be
database, external queues or any other system.
Now we will look into the practical applications of the activity diagram. From the above
discussion it is clear that an activity diagram is drawn from a very high level. So it gives high
level view of a system. This high level view is mainly for business users or any other person who
is not a technical person.
This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.
Following are the main usages of activity diagram:

 Modeling work flow by using activities.
 Modeling business requirements.
 High level understanding of the system's functionalities.
 Investigate business requirements at a later stage.
swimlane diagram
A swimlane diagram (also sometime called a cross-functional diagram) documents the
steps or activities of a process flow or workflow. More specifically, a swimlane diagram
groups these activities into swimlanes which are horizontal or vertical columns that contain
all of the activities which fit into the category represented by that swimlane.
Swimlanes can represent many categories of information such as actors which perform
the activities (i.e., role or department), the stage of the process in which the activity takes
place, or whatever else the creator of the document feels should be emphasized and
communicated by the swimlane diagram. The term swimlane was adopted due to the visual
similarity between the horizontal rows of the diagram to that of the swimlanes found within a
swimming pool.
Tools used by BA:
Business analytics is a fast growing field and there are many tools available in the market
to serve the needs of organizations. The range of analytical software goes from relatively simple
statistical tools in spreadsheets (ex-MS Excel) to statistical software packages (ex-KXEN,
Statistica) to sophisticated business intelligence suites (ex-SAS, Oracle, SAP, IBM among the
big players). Open source tools like R and Weka are also gaining popularity. Besides these,
companies develop in-house tools designed for specific purposes.
Here is a list of 10 most popular analytic tools used in the business world.
Commercial software
MS Excel: Almost every business user has access to MS Office suite and Excel. Excel is an
excellent reporting and dash boarding tool. For most business projects, even if you run the heavy
statistical analysis on different software but you will still end up using Excel for the reporting
and presentation of results.

While most people are aware of its excellent reporting and graphing abilities, excel can be a
powerful analytic tool in the hands of an experienced user. Latest versions of Excel can handle
tables with up to 1 million rows making it a powerful yet versatile tool.
SAS: SAS is the 5000 pound gorilla of the analytics world and claims to be the largest
independent vendor in the business intelligence market. It is the most commonly used software
in the Indian analytics market despite its monopolistic pricing. SAS software has wide ranging
capabilities from data management to advanced analytics.
SPSS Modeler (Clementine): SPSS Modeler is a data mining software tool by SPSS Inc., an
IBM company. It was originally named SPSS Clementine. This tool has an intuitive GUI and its
point-and-click modeling capabilities are very comprehensive.
Statistica: is a statistics and analytics software package developed by StatSoft. It provides data
analysis, data management, data mining, and data visualization procedures. Statistica supports a
wide variety of analytic techniques and is capable of meeting most needs of the business users.
The GUI is not the most user-friendly and it may take a little more time to learn than some tools
but it is a competitively priced product that is value for money.
Salford systems: provides a host of predictive analytics and data mining tools for businesses.
The company specializes in classification and regression tree algorithms. Its MARS algorithm
was originally developed by world-renowned Stanford statistician and physicist, Jerome
Friedman. The software is easy to use and learn.

KXEN: is one of the few companies that are driving automated analytics. Their products, largely
based on algorithms developed by the Russian mathematician Vladimir Vapnik, are easy to use,
fast and can work with large amounts of data. Some users may not like the fact that KXEN
works like a ‘black box’ and in most cases, it is difficult to understand and explain the results.
Angoss: Like Salford systems, Angoss has developed its products around classification and
regression decision tree algorithms. The advantage of this is that the tools are easy to learn and
use, and the results easy to understand and explain. The GUI is very user friendly and a lot of
features have been added over the years to make this a powerful tool.
MATLAB: is statistical computing software developed by Math Works, MATLAB allows
matrix manipulations, plotting of functions and data, implementation of algorithms and creation
of user interfaces. There are many add-on toolboxes that extend MATLAB to specific areas of
functionality, such as statistics, finance, image processing, bioinformatics, etc. MATLAB is not
free software. However, there are clones like Octave and Scilab which are free and have similar
functionality.
Open Source Software
R: R is a programming language and software environment for statistical computing and
graphics. The R language is an open source tool and is widely used by the academia. For
business users, the programming language does represent a hurdle. However, there are many
GUIs available that can sit on R and enhance its user-friendliness.

Weka: Weka (Waikato Environment for Knowledge Analysis) is a popular suite of machine
learning software, developed at the University of Waikato, New Zealand. Weka, along with R, is
amongst the most popular open source software used by the business community. The software
is written in the Java language and contains a GUI for interacting with data files and producing
visual results and graphs.

Business Analyst Documentation

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Business Analyst Documentation (20)

More from Yaswanth Babu Gummadivelli (20)

Recently uploaded (20)

Business Analyst Documentation