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?

Putative Questions:

Asks about a situation in a way that tests your model of the domain

Types of questions as Tools:

Whyusually leads to deeper Motivations, Information on structure.

WhatUsually Leads to Facts.

HowUsually Leads to a Discussion of Process, not Structure.

Ask Questions to Obtain information

Build Information into Your Model

Figure out where the ambiguity or

Problem Is Pose Putative Questions

Wrong

Answer

Answer

Matchs

CouldMaximally 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.