BUSINESS ANALYST PROCESS

This document defines the solution development process that a business analyst
follows from identification of a problem in the business community to the
implementation of a solution in that same business community. The process is
fully described in the book Business Analysis: A Systems Approach to Solving
Business Problems.

I. Define the Problem and Product Scope

A. Define the problem owner

– The person or department that has authority to seek a solution to the
problem; can identify or describe the real problem; can approve the
problem definition; and can voice or approve the vision

B. Prepare an information gathering plan to determine the problem

– What information is needed to define the real problem
– Where can the information be found
– How can the information be acquired
– What is the order of acquisition of the information

C. Elicit information about the problem

– Talk to the problem owner and managers and observe the problem
domain to determine what the real problem is

D. Analyze the information

– Make sure the stated problem is really a problem
– Make sure the problem is aligned with the organization mission and
strategies

E. Determine the real problem to be solved

– Make sure the problem is the real one that needs to be solved and that
it is the correct problem
– Make sure the solution of the problem satisfies all issues presented by
the customer (manage expectations)

F. Confirm with the problem owner (or executive decision maker)

– Make sure that the real problem that has been defined is the one that
management wants solved
– When management needs justification to solve the problem (or when
organizational policy dictates), perform the requisite analyses: ROI
analysis, cost/benefit analysis and/or feasibility studies

Copyright Steve Blais, 2008-2010 Page 1 of 4

Business Analyst Process

G. Define the product scope

– Obtain the vision of the solution and acceptance criteria from the
problem owner
– Determine the product stakeholders
– Identify the business risk of not solving the problem and the potential
impact to the organization when the problem is solved and any other
identified business risks
– Determine the justification for solving the problem
– Identify any business or product constraints that may be imposed on
the solution
– Identify any functional goals or business objectives that must be
achieved in solving this problem. Break the product into incremental
deliveries based on functional goals where possible.

H. Create a formal or informal decision document

– Combine the product scope with other required information and
produce a business case and/or project charter or other document(s)
that the organization may require to make a final decision to solve this
problem

II. Define the Solution

A. Prepare an information gathering plan to determine the solution

– What information is needed to define the solution
– Where that information can be found
– How the information can be acquired
– What is the order of acquisition of the information
– Classify user communities when they are large
– Identify hidden, indirect, and disadvantaged users when possible

B. Elicit information about the problem domain

– Understand completely why the problem exists and what the conditions
are causing the problem
– Use information gathering techniques such as Interviews, meetings,
use case sessions, observation, etc.
– Confirm with the process workers supplying the information that you
have understood the information they provided completely and
accurately

C. Analyze the information to determine potential solutions for the problem

– Categorize and filter the information and requirements
– Model or diagram the problem domain, business processes in the
problem domain, and the applicable environment

Copyright Steve Blais, 2008-2010 Page 2 of 4

Business Analyst Process

– Identify the conditions in the problem domain that are causing the
problem
– Analyze and model the solution
– Data intensive systems might be modeled with an entity relationship
diagram
– You might model process-intensive systems with a data flow or activity
diagram
– Systems with high user interaction might be best rendered in use
cases
– Continually confirm your analysis with the affected product
stakeholders that the part of the solution that affects them will work and
is acceptable

D. Document the solution

– Record the results of your analysis so that you can verify with the
product stakeholders wherever they are
– Confirm with the stakeholders that the solution completely and
accurately solves the problem
– Get parts of the solution confirmed as you define them
– Check technical and project feasibility with the solution team

E. Write the Solution Document

– Render the solution in a form that is understandable to the product
stakeholders and business management and is in a form acceptable to
the solution team

1. Validate the requirements with peers

• Use peer review or inspection as the format to validate
• Review the requirements document with the solution team

2. Get Solution Document approved by executive decision maker

III. Keep Requirements up to Date throughout Software Development

A. Review systems requirements and/or design to identify changes to

requirements or variations from defined solution
– When the solution varies from definition and business expectations
without technological rationale suggest conforming to the business
expectation of the solution
– When the solution varies from definition and business expectations
justifiably, change the solution document accordingly and confirm the
change with the affected product stakeholders

B. Create process to review any changes to the evolving system that may
affect requirements

Copyright Steve Blais, 2008-2010 Page 3 of 4

Business Analyst Process

IV. Prepare acceptance tests based on the defined acceptance criteria that
will prove to business analyst and stakeholders that the problem has been
solved

A. Write acceptance test scenarios, scripts or cases that prove the problem
has been completely solved
– Tests should be executable by users or users’ representatives
– Results should be understandable by users or product stakeholders
– Final results should be understandable by problem owner or business
management to prove problem was solved

B. Participate in the acceptance testing phase

– Execute the tests and share the results with the stakeholders, and/ or
– Supervise the users or users’ representatives in the execution of the
acceptance testing, and/or
– Work with quality assurance or quality control to ensure tests prove
that the problem is solved
– Record changes, alterations, and modifications to the requirements as
a result of software changes due to acceptance testing (there should
be very few)
– Record suggested or recommended changes for post release
consideration

V. Enable the Transition of Solution into Production

A. Prepare the business community for the solution

– Make sure process workers get appropriate training and
documentation where necessary
– Remove, reduce, or identify any final resistance to the solution in the
business community so that the solution can be given a fair chance to
succeed

B. Evaluate the solution in production

– Observe the solution in use to ensure that the problem is solved
completely
– Record any suggestions for improvement or defects that are reported
during the first period of use

VI. Start over again

Copyright Steve Blais, 2008-2010 Page 4 of 4

 THE PRINCIPLES OF THE BUSINESS ANALYST

Excerpt from: Business Analysis: A Systems Approach to Solving

Business Problems

PRINCIPLE 1 – FOCUS ON THE PRODUCT ...................................................................2

PRINCIPLE 2 – FIRST DEFINE THE PROBLEM AND THEN THE SOLUTION ........................2
PRINCIPLE 3 – USERS DO NOT HAVE REQUIREMENTS................................................2
PRINCIPLE 4 – FOCUS ON INFORMATION NOT INDIVIDUALS..........................................3
PRINCIPLE 5 – SEPARATE ELICITATION FROM ANALYSIS .............................................3
PRINCIPLE 6 – IMPROVE THE PROCESS FIRST, THEN ADD TECHNOLOGY .....................3
PRINCIPLE 7 – COMMUNICATE, COOPERATE, COLLABORATE.......................................4
PRINCIPLE 8 – THE BUSINESS ANALYST OWNS THE SOLUTION REQUIREMENTS............6
PRINCIPLE 9 – GAIN ACCEPTANCE AS WELL AS APPROVAL..........................................7
PRINCIPLE 10 – MAKE THE BUSINESS COMMUNITY READY FOR THE PRODUCT .............7
PRINCIPLE 11 – MEASURE TWICE, CUT ONCE ...........................................................7

Essence: As in most occupations and roles in the organization, there are a

number of principles that apply to the successful completion of the job. Some of
the principles are high-level and generic while others are specific to an area of
concern. The following is a list of such principles that apply to the role of
business analyst.

The newest computer can merely compound, at speed, the oldest

problem in the relations between human beings, and in the end
the communicator will be confronted with the old problem, of what
to say and how to say it.

– Edward R. Murrow

The business analyst is a role that can be played by any job or position, from
developer to upper-level management, and must be a role that is played in any
successful business problem-solving effort. The tenets in this book are aimed at
those who must play that role so that they may play the role successfully. The
following represents a summation of those tenets and principles.

The Principles of a Business Analyst Page 1 of 8

Copyright Steve Blais 2008 - 2010
 The Principles of the Business Analyst

Principle 1 – Focus on the Product

The business analyst focuses on the product not on the project

The project is the domain of the project manager and the solution team. The
product is the result of that project. The business analyst starts with the end in
mind [Covey89] and keeps it focused. The business analyst’s responsibility is to
solve the problem, and get that product into the business environment.

Understand what a solution is worth to the business

At any time the business analyst can tell anyone the value of the change being
made to the organization, and, for the most part, to any component of that
change. Each feature and function created by the solution team plays a part in
the overall solution and each has its intrinsic value. The business analyst always
knows “why”.

Principle 2 – First Define the Problem and Then the Solution

Requirements describe the solution to a defined, understood and approved

business problem

Here is a complaint from a senior business analyst: “Most projects are in design-
mode long before they have established what the problem that they are trying to
solve has been defined as. Too often I see project teams discussing how the
screen is going to look and what push buttons are going to do before anyone
knows what business problem we are trying to fix.”

The set of requirements that the business analyst creates describes the solution
to the business problem in terms that the business community can understand
and agree will completely and accurately solve their problem. The technical
community can also understand what needs to be done so they can completely
and accurately create the software to solve the problem.

Principle 3 – Users Do Not Have Requirements

Users do not have requirements; stakeholders do not have requirements –

they just have information

The business analyst seeks that information and analyzes it to produce the
solution document containing the requirements.

Copyright Steve Blais 2008 – 2010 Page 2 of 8

The Principles of the Business Analyst

Principle 4 – Focus on Information Not Individuals

Start by determining what information you need to solve the problem. Use the
information gathering plan to help structure the information gathering process.
Always keep the focus of the elicitation on gathering information.

No part of the solution should be based on only one source; all parts of the
solution should be verified, confirmed and validated, preferably by someone or
something other than the source of the information that produced that part of the
solution.

Principle 5 – Separate Elicitation from Analysis

When eliciting information, do not analyze; when in analysis, do not create

information

While eliciting information, the business analyst focuses only on getting as much
information as possible. Analyzing the information as it is acquired appears as
though the business analyst is judging the responder and will stem the flow of
information. During analysis, the opposite is true. Any new information created
while analyzing is a business analyst’s assumption. The facts only come from
the business.

Principle 6 – Improve the Process First, Then Add Technology

Evaluate non-IT solutions first before resorting to computers and software

to solve the business problem

Since most business analysts come from IT, there is a natural tendency to
assume that all business solutions can be solved with information technology and
that the only solution to a business problem is by applying the use of computers.
Many times, however, there are much more elegant and simple solutions to
business problems: changing processes, relocating process workers,
redistributing the work, and so forth.

Focus on the business, and how IT can be used to improve and enhance
the business’s status quo

Look for human solutions rather than technical ones. IT will come up with the
technical solution to support the human business interaction. The business
analyst has to make sure that the technology will be used comfortably by human
beings. Keeping focused on the human aspects of the solution keeps the
business analyst focused on the business as much as the technology and that
balances the solution.

Copyright Steve Blais 2008 – 2010 Page 3 of 8

 The Principles of the Business Analyst

Constantly review and appraise the organization’s processes and

operations to determine where changes can be made that will add value to
the organization

Every solution is the source of new problems. Every problem has ancillary and
dependent problems. Focus first on the real problem to solve now, and keep
your eyes open for other problems that exist or that may exist when a solution is
applied.

Take a holistic view of the organization and apply inductive reasoning to the
environment surrounding the stated problem to discover any other problems. By
looking at the whole problem domain instead of only focusing on the immediate
issue, the business analyst:

Gets a wider view of the problem in context,

Identifies ancillary problems and issues,
Gets a better view of the impacts that may attend a given solution, and
Is able to grasp different views of the problem and the conditions that
cause the problem.

Principle 7 – Communicate, Cooperate, Collaborate

Keep communications flowing in all directions

Step out of the way of the communication and let it flow naturally. That is, let the
solution team talk to the product stakeholders and vice versa. Only step in
between to clarify, ameliorate, document (as in taking notes), facilitate (as in
moving the discussion along), or mediate.

Do what is necessary to promote the flow of information amongst all parties of

the solution. Do not, however, force reticent team members to communicate
against their personality or coerce information from recalcitrant individuals.

Live on the Feedback

Organize your communication efforts around obtaining feedback from all parties.
Keep announcements, status reports, and one-way communiqués to a minimum.
When one of your communications does not receive feedback, consider that your
communication failed and seek another way of transferring the information more
successfully.

Checkpoints

There are a few checkpoint meetings that you want to hold formally or informally
with one or more participants. The primary purpose of the checkpoints is to
make sure the solution is moving in the right direction. The checkpoints are not
status meetings or “this is what I have done” meetings”.

Copyright Steve Blais 2008 – 2010 Page 4 of 8

The Principles of the Business Analyst

Problem Owner Confirmation

Perform a quick check of the defined problem statement with the problem owner
to make sure the problem is correct and it is the problem that should be solved.
At that time, you ask three questions:

Is this the problem you want solved?

What is your vision of the solution?
What do you need to see to know we have solved the problem?

Checkpoint Alpha – Confirmation of Product Scope

This checkpoint is a preview of coming attractions for the solution team,

assuming there is one assigned, and/or the product stakeholders. The purpose
of the meeting is to validate the starting point for the solution life cycle and get an
initial verification of product scope feasibility. The questions to be answered at
this checkpoint are:

Is this product scope feasible?

Is there anything I missed?
Does this make sense?

Checkpoint Beta – Confirmation of Good Requirements

The second meeting which could be informal or formal comes after the good
requirements have been confirmed, when you have the solution to the problem
that the process workers and/or customer agree to, and before you start the
validation process of turning the solution into a formal set of requirements or
solution document. The purpose is to technically confirm the solution and
uncover any technical infeasibility, and to let the solution team know what is
coming.

The questions you ask at this checkpoint are:

Is there anything in the solution I missed?

Does this solution make sense?
Is it still feasible?
Do you understand what the solution document is saying?

Copyright Steve Blais 2008 – 2010 Page 5 of 8

 The Principles of the Business Analyst

Checkpoint Charley – Review of Design

The third meeting, which is formal, is done after the technical team has defined a
technical solution. The technical team presents its solution to the business
analyst. The business analyst makes sure the solution still solves the business
problem and updates the business solution to include any variations that result
from the technical solution. The questions to be answered at this checkpoint are:

How does the technical solution solve the business problem?

Are there any technical changes that affect the solution document?
What do I need to change in the solution document to keep the
document synchronized with the solution?

Do not let documentation substitute for communication and collaboration

The requirements documentation should be the distillation or results of the

process and all the communication that is part of the process. Confirmation
activities should not be focused on getting the document approved, but on getting
the solution correct. Approval will then follow naturally.

Principle 8 – The Business Analyst Owns the Solution Requirements

Once you have defined the solution and the business community has agreed that
it solves their problem, you are the only one who has the authority to physically
change the approved requirements. When you change them, the person(s) who
signed the original document should also agree with, if not re-sign, with the
changes made.

Requirements are written for those who create the solution not for those
who have the problem

The final target audience for the requirements is the solution team. While the
users or stakeholders need to agree that the requirements completely and
accurately solve the problem, the requirements are written for those who are
actually going to build the solution.

The solution document must match the delivered solution

Throughout the development process, there will be changes to the product.

There will be trade-offs during systems analysis and design. There will be
technical changes due to the build process. Testing may introduce changes.
While the business analyst must evaluate all the changes in light of a valid
solution to the problem, many changes will be acceptable or unavoidable. The
business analyst’s obligation is to modify the requirements to reflect the changed
vision of the product.

Copyright Steve Blais 2008 – 2010 Page 6 of 8

The Principles of the Business Analyst

The requirements state the solution to the business problem. The system
delivered must do what the requirements say. The system delivered must solve
the problem.

There is certainly a lot of discussion in the agile communities about the value of a
formal set of requirements. There is no argument among the agilists about the
value of a well maintained and documented code base. Business analysts derive
the same benefit from documenting and maintaining complete requirements, as
developers do from maintaining their code base.

Analyze, Analyze, Analyze

Your last name is “analyst” and everything you do is about analysis, from
preparing decision papers for upper-level management to analyzing problem
statements to determine what the real problem is. You do not accept anything as
fact without analyzing to make sure it is fact. Your ability to analyze is what
separates you from the requirements recorders.

Principle 9 – Gain Acceptance as well as Approval

Getting the solution document approved by the appropriate authorities on the

business and solution sides is not enough for the business analyst. The solution
document must be accepted by all. That means that the product stakeholders
accept the changes that are going to be made to their environment, and the
solution team understands and accepts the statement of solution and agrees that
they can affect the solution.

Principle 10 – Make the Business Community Ready for the Product

You do not want to create a solution that nobody uses. The solution might be
elegant and satisfy all requirements; however, when it is not used, it fails as a
solution. The business analyst makes sure the product stakeholders, those
affected by the problem and those impacted by the solution, have the requisite
training and documentation, and are prepared for the change to their
environment.

Principle 11 – Measure Twice, Cut Once

Measure the problem domain to establish the depth and breadth of the problem
as part of our justification. Then implement the change. Once the problem is
solved, perform the exact same measurement so that you can show the
improvement.

Place the post implementation measurement into the product. In this way, you
can continue to ensure the product continues to solve the problem and provide
an indicator of future problems. It also establishes your first measurement the
next time you change the system.

Copyright Steve Blais 2008 – 2010 Page 7 of 8

 The Principles of the Business Analyst

Measuring also provides a continuing justification and proof that the proposed
changes are worthwhile and increases the trust that management has in you as a
business analyst.

Copyright Steve Blais 2008 – 2010 Page 8 of 8

 GUIDELINES TO VALID REQUIREMENTS

Extracted from: Business Analysis: A Systems Approach to Solving

Business Problems

1. Single sentence (paragraph) per requirement

Explanations differentiated (different font/size, indented)

Explanations can be included in a requirements document provided it is absolutely

clear that it is an explanation and not a requirement. Make things easier for all
readers of the requirements by setting explanations off from the requirements by
placing the explanation in parentheses, in a different font/size, indented, in a
different color, and so forth. It might also help to make it clear in the front of the
document what is being used to distinguish the explanations from the
requirements.

2. Numbered (identified)
Each requirement must be identified with a unique number or label.

3. CompleteSelf-contained, stand-alone

Every requirement must be self-contained and stand-alone. The understanding of a

requirement must not depend on the content of another requirement.
Understanding may depend on language defined in the glossary.

Where completeness cannot be obtained (information not

available, decisions not made, etc.) the requirement can be
“defined later”, but needs a date or a point in time (or process)
by which it will be defined.

When dealing with an approved or baselined set of requirements, removing the

“TBD” and replacing it with the real requirements requires a new version.

4. ConsistentLists only WHAT is required, not HOW

Does not conflict with any other requirements
Use same terminology throughout

Lack of consistency in requirements is one of the major reasons for failures due to
requirements errors. When inconsistency exists, assumptions will be made and
chances are the assumptions could be wrong.

5. TestableUsing inspection, demonstration, execution or analysis

Single test per requirement with pass/fail results

Copyright Steven P. Blais, Parkson International, Inc., 2010 Page 1 of 5

Guidelines to Valid Requirements

6. Feasible
In scope
States no requirements for anything or anyone not in the system
Technologies
Does the technology exist to do what is needed?
Can the technology be accessed/acquired (Buy. Build. Borrow)?
Can the software team actually do it?
Economic (e.g., Cost / Benefits Analysis)
Legal and regulatory
Do all the requirements meet or conform to all applicable regulations?
Usability
Will the user actually be able to understand and use the feature to solve
the business problem?
Feasible means that it is possible to implement each requirement within the
capabilities and limitations of the known technical and operational environment.
7. Traceable
Traceable to scope, concept of operations, etc.
Traceable to source of requirements
8. Written for the correct audience
User requirements UserFunctional requirements User /
customerSystems requirements Architect / designerSoftware
requirements Analyst / designer / developerProgram
requirements Developer / testerHardware requirements
Analyst / procurement / testers

9. Word Choice
Precision
Precision in professional language has two purposes: to make communication with
fellow professionals specific and unambiguous, and to inform people on the outside
meaningfully and clearly [Holmes, Neville, “In Praise of Professional Precision”, IEEE
Computer, 4/2006].

Choice of words is important. There are a number of imprecise words that we think
are precise. These words should be avoided. (See next page). Technical words or
jargon tend to obfuscate, and should be avoided unless defined specifically in the
glossary.

Ambiguity
Ambiguity exists when any word or phrase may be interpreted in more than one
possible way. This can be verified by having another Business Analyst read the
requirements aloud or have a Business Analyst paraphrase what she or he thinks the
requirement is saying. If the meaning varies from the author’s intended meaning,
ambiguity exists and must be eliminated by rewording the requirement. Note that

Copyright Steven P. Blais, Parkson International, Inc., 2007 Page 2 of 5

Guidelines to Valid Requirements

the requirement itself may not need to be changed to eliminate the ambiguity. A
clearly defined and unambiguous entry in the glossary may eliminate the problem.

Use rule-based verbs – “will”, “must”, active verbs

Avoid statements of volition –
May might
Should could
If can

Use present rather than future tense, if possible

No conjunctions: “and”, “but”, semicolon, “or”

(“and” may be used as a connector only)

Positive voice

Avoid hyphenated phrases

Well-organized Fully-automated
Trouble-free State-of-the-art
Working-condition User-friendly
Use nouns rather than pronouns or proper nouns

Consistent (not contradictory – same use of word)

Use Glossary for consistency

Avoid vague or imprecise words

ability about
acceptable adequate all
appropriate approximately around
aspect
case characteristic* current
communicate comprehensive convenient
detect different*
easy efficient employ
enable
enough every everyone
factor fast function
feature* high immediate
instantaneously kind
large logical low
many matter measure(n)
modern note (v) numerous
operate
perform practical present (adj)
present (v)* quick
realistic reasonable run*
satisfactory set simple
several safe small

Copyright Steven P. Blais, Parkson International, Inc., 2007 Page 3 of 5

Guidelines to Valid Requirements

sort substantial successfully

sufficient
thing type
usable useful various
*without qualifying attribute
**unless dealing with mathematical specifics

Avoid “automatic” words (without glossary definition)

accessible* accessibility* application

apply artifact
architecture architectural availability*
automate(d) automation asynchronous
batch build(n)
check (v) client communication*
component concurrent connection(s)
database* decode* design*
deployment disk* display*
documentation drive(n)
effective efficient element
encode* entity executable
execute
feature field firmware
function functional functionality
generate gui
header implementation
input (n) input (v) interface
infrastructure implement
install integrate* integration
maintain manual
middleware module monitor (v)
network
operation(s) output (n) output (v)
phase port (v) package
part partition populate
provide
read* real-time record
relationship robust runtime
scale(v) scan screen
seamless secure (v) secure (n)
segment server serviceable
set simultaneously supply
support survey(v) switch (n)
synchronize synchronous
transaction unit* update
write*

Copyright Steven P. Blais, Parkson International, Inc., 2007 Page 4 of 5

Guidelines to Valid Requirements

*without qualifying attribute(s)

Phrases to avoid

more or less network layer physical design

present time real-time round-trip
the ability to throw an error user friendly
web-based

Avoid comparative adjectives or phrases

a little as little as* as much as* bad

best better bigger cheaper
considerable considerably definitely
easier enough exceeding(ly) excessive(ly)
extremely
faster good highest huge
large larger least less
lowest mega-** meta-** minimum*
maximum* more most overly
really
smaller smallest somewhat too
very worse
*without a qualifying quantity (e.g., a minimum of twelve will be allowed)
**when referring to size rather than quantity

Copyright Steven P. Blais, Parkson International, Inc., 2007 Page 5 of 5

BUSINESS ANALYST’S VIEW OF SOFTWARE DEVELOPMENT LIFE
CYCLE MODELS

Table of Contents

GENERAL APPROACH ..............................................................................................2

LINEAR OR PHASED APPROACHES ...........................................................................3
W ATERFALL ..................................................................................................................3
V MODEL ......................................................................................................................4
INCREMENTAL DEVELOPMENT ........................................................................................6
STAGED DELIVERY ....................................................................................................6
ITERATIVE APPROACHES..........................................................................................8
SPIRAL .........................................................................................................................8
RATIONAL UNIFIED PROCESS .......................................................................................10
AGILE APPROACHES .............................................................................................12
RAPID APPLICATION DEVELOPMENT .............................................................................12
DSDM .......................................................................................................................12
EXTREME PROGRAMMING ............................................................................................14
XP PRINCIPLES .......................................................................................................16

List of Figures

Figure 1. Example of a Typical Waterfall Approach ............................................3

Figure 2. Example of a Typical V Model (IEEE) ..................................................5
Figure 3. Example of the Staged Approach ........................................................7
Figure 4. Example of the Spiral Model ................................................................9
Figure 5. Example of the Rational Unified Process ...........................................11
Figure 6. Example of DSDM Process................................................................13
Figure 7. Example XP Process .........................................................................14

Copyright Steve Blais, 2008-2010 Page 1 of 18

 BA View of SDLC Models

General Approach
Regardless of the time an activity takes whether they are done simultaneously or
in long planned phases fraught with documentation and approvals, the software
development life cycle (SDLC) must answer certain questions about the product
being developed.

What is the business problem being solved? Concept Phase

What is the solution to that problem? Requirements
How are we going to affect the solution? Logical Design
What are the elements of that solution? Physical Design and Coding
How do we know our solution is right? Unit, Integration and System
Testing
How do we know we have the right solution? Acceptance Testing
Will it work in the environment with the actual users? Implementation

Each of the life cycle models includes activities, tasks, or phases that answer
these questions, although not necessarily in the direct format given above.

Copyright Steve Blais, 2008-2010 Page 2 of 18

 The Essence of the Business Analyst

Linear or Phased Approaches

Waterfall
While the Waterfall Model presents a straight-forward view of the software life
cycle, this view is only appropriate for certain classes of software development.
Specifically, the Waterfall Model works well when the software requirements are
well understood (e.g., software such as compilers or operating systems) and the
nature of the software development involves contractual agreements. The
Waterfall Model is a natural fit for contract-based software development since
this model is document driven; that is, many of the products such as the
requirements specification and the design are documents. These documents
then become the basis for the software development contract.

There have been many waterfall variations since the initial model was introduced
by Winston Royce in 1970 in a paper entitled: “Managing the Development of
Large Software Systems: Concepts and Techniques”. Barry Boehm, developer
of the spiral model (see below), modified the waterfall model in his book Software
Engineering Economics [Prentice-Hall, 1987]. The basic differences in the
various models are in the naming and/or order of the phases.

The basic waterfall approach looks like the illustration below. Each phase is
done in a specific order with its own entry and exit criteria and provides the
maximum in separation of skills, an important factor in government contracting.

Figure 1. Example of a Typical Waterfall Approach

Copyright Steve Blais, 2008-2010 Page 3 of 18

 BA View of SDLC Models

While some variations on the waterfall theme allow for iterations back to the
previous phase, “In practice most waterfall projects are managed with the
assumption that once the phase is completed, the result of that activity is cast in
concrete. For example, at the end of the design phase, a design document is
delivered. It is expected that this document will not be updated throughout the
rest of the development. You cannot climb up a waterfall.” [Murray Cantor,
Object-Oriented Project Management with UML, John Wiley, 1998.]

The waterfall is the easiest of the approaches for a business analyst to

understand and work with and it is still, in its various forms, the operational SDLC
in the majority of US IT shops. The business analyst is directly involved in the
requirements definition and/or analysis phases and peripherally involved in the
succeeding phases until the end of the testing phase. The business analyst is
heavily involved in the last stages of testing when the product is determined to
solve the business problem. The solution is defined by the business analyst in
the business case and requirements documents. The business analyst is also
involved in the integration or transition phase assisting the business community
to accept and incorporate the new system and processes.

V Model
The "V" Model (sometimes known as the "U" Model) reflects the approach to
systems development wherein the definition side of the model is linked directly to
the confirmation side. It specifies early testing and preparation of testing
scenarios and cases before the build stage to simultaneously validate the
definitions and prepare for the test stages.

It is the standard for German federal government projects and is considered as

much a project management method as a software development approach.

“The V Model, while admittedly obscure, gives equal weight to testing rather than
treating it as an afterthought. Initially defined by the late Paul Rook in the late
1980s, the V was included in the U.K.'s National Computing Centre publications
in the 1990s with the aim of improving the efficiency and effectiveness of
software development. It's accepted in Europe and the U.K. as a superior
alternative to the waterfall model; yet in the U.S., the V Model is often mistaken
for the waterfall…”

“In fact, the V Model emerged in reaction to some waterfall models that showed
testing as a single phase following the traditional development phases of
requirements analysis, high-level design, detailed design and coding. The
waterfall model did considerable damage by supporting the common impression
that testing is merely a brief detour after most of the mileage has been gained by
mainline development activities. Many managers still believe this, even though
testing usually takes up half of the project time.” [Goldsmith and Graham, “The
Forgotten Phase”, Software Development, July 2002.]

Copyright Steve Blais, 2008-2010 Page 4 of 18

 The Essence of the Business Analyst

As shown below, the model is the shape of the development cycle (a waterfall
wrapped around) and the concept of flow down and across the phases. The V
shows the typical sequence of development activities on the left-hand (downhill)
side and the corresponding sequence of test execution activities on the right-
hand (uphill) side.

Figure 2. Example of a Typical V Model (IEEE)

The primary contribution the V Model makes is this alignment of testing and
specification. This is also an advantage to the business analyst who can use the
Model and approach to enforce early consideration of later testing. The V Model
emphasizes that testing is done throughout the SDLC rather than just at the end
of the cycle and reminds the business analyst to prepare the test cases and
scenarios in advance while the solution is being defined.

The business analyst’s role in the V Model is essentially the same as the
waterfall. The business analyst is involved full time in the specification of the
business problem and the confirmation and validation that the business problem
has been solved. This is done at the acceptance test stage. The business
analyst is also involved in the requirements phases and provides advice during
the system test stage which is typically performed by independent testers – the

Copyright Steve Blais, 2008-2010 Page 5 of 18

 BA View of SDLC Models

quality assurance group or someone other than the development team. The
primary business analyst involvement in the system test stage is keeping the
requirements updated as changes occur and providing “voice of the customer” to
the testers and development team. The rest of the test stages on the right side
of the Model are done by the development team to ensure they have developed
the product correctly. It is the business analyst’s job to ensure they have
developed the correct product.

Incremental Development
The incremental approach is a generic method of delivering a working part of a
total product or solution. It is the basis of most agile and iterative methods
including Rational Unified Process (RUP). The agile concept of “timeboxing” is
an incremental delivery approach.

Similar to the V Model, incremental development is as much a management

approach to software development as a development approach, probably more
so. “Incremental development is a scheduling and staging technique nicely
suited to projects using technology and techniques new to an organization...[It is]
a scheduling and staging strategy that allows pieces of the system to be
developed at different times or rates and integrated as they are completed.
Specifically intended is that between increments, additions could be made to the
requirements, process changes could be incorporated, or the schedule could be
improved and revised. Incremental is distinguished from iterative development in
that the latter supports "predicted rework" of parts of the system. A good grasp
of incremental development helps in applying iterative development...” [Alistair
Cockburn, “Unraveling Incremental Development”]

Staged Delivery

The staged delivery model initially advanced by Tom Gilb and later championed
by Steve McConnell applies the principles of incremental delivery to the waterfall
model. It is a development approach that emphasizes project planning and risk
reduction by using multiple software releases.

During the first phases of the staged delivery process, the overall problem is
defined and the solution specified. The second phase consists of creating an
architecture for the overall solution. After that, the product is partitioned into
interim or successive deliveries and each delivery goes through its own
development life cycle as shown in the following diagram. The goal of each
stage is to advance toward a complete and robust product on time and within
budget. Typically each stage has its own budget and deliverable schedule that
may be refined based on previous deliverables. The duration of each successive
stage is generally similar. The number of planned stages for achieving a final
release is dependent upon the functionality, application complexity, and so forth.

Copyright Steve Blais, 2008-2010 Page 6 of 18

 The Essence of the Business Analyst

Figure 3. Example of the Staged Approach

[From Steve McConnell, Software Project Survival Guide, Microsoft Press]

At the core of successful staged delivery is the customer review that occurs
between stages and is typically based on using the software in the business
environment. This is what Alistair Cockburn calls the “breathing space”. It allows
for customer feedback and adjustments to the architect, requirements, and
process for successive stages.

The staged and any incremental delivery approach presents extra challenges for
the business analyst. After the problem has been defined and the product
requirements specified, the business analyst then may be handling requirements
changes for multiple stages, or addressing the user or stakeholder feedback from
previously installed software while assisting with the development and testing of
succeeding stages. Especially when multiple development teams are involved,
the business analyst activities in a staged or incremental delivery life cycle are
best handled in a team effort with multiple business analysts assigned to different
stages and product deliverables.

Copyright Steve Blais, 2008-2010 Page 7 of 18

 BA View of SDLC Models

Iterative Approaches

Spiral
The spiral model was defined by Barry Boehm, now at the University of Southern
California, as an early example of an iterative approach to software development.
It was not the first model to discuss iteration, but it was the first model to explain
why the iteration matters. As originally envisioned, the iterations were typically
six months to two years long.

Each phase of the spiral starts with a design goal (such as a user interface
prototype as an early phase) and ends with the client (which may be internal)
reviewing the progress and determining if the next spiral will take place.

The primary difference between the spiral model and the other life cycle models
is the emphasis of risk assessment as evidenced by the following illustration.
Each cycle through the phases ends with an evaluation by the customer and an
assessment of the risk of going ahead with the next iteration or stopping and
completing the delivery of the product.

Once the product is deemed ready for development based on customer feedback
and risk assessment, the process becomes a standard waterfall approach. The
difference is that the high-level design and specifications have been completed
and the construction phase has a prototype to follow. This makes the
implementation faster and of higher quality.

While the spiral model in its pure form is not used much outside the US Military, it
sets the pattern for most of the agile and iterative approaches that follow it.
There are also a multitude of “spiral” variations for all or parts of the solution life
cycle, such that spiral has almost become synonymous with iterative.

Copyright Steve Blais, 2008-2010 Page 8 of 18

 The Essence of the Business Analyst

Figure 4. Example of the Spiral Model

[From Boehm, B.W. “A Spiral Model of Software Development and Enhancement.” IEEE
Software Engineer and Project Management, 1987]

The steps in the spiral model can be generalized as follows:

1. The new system requirements are defined in as much detail as possible. This
usually involves interviewing a number of users representing all the external
or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design.
This is usually a scaled-down system and represents an approximation of the
characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure: (a) evaluating the first
prototype in terms of its strengths, weaknesses, and risks; (b) defining the
requirements of the second prototype; (c) planning and designing the second
prototype; and, (d) constructing and testing the second prototype.
5. At the customer's option, the entire project can be aborted if the risk is
deemed too great. Risk factors might involve development cost overruns,
operating-cost miscalculation, or any other factor that could, in the customer's
judgment, result in a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous
prototype, and, if necessary, another prototype is developed from it according
to the fourfold procedure outlined above.

Copyright Steve Blais, 2008-2010 Page 9 of 18

 BA View of SDLC Models

7. The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.
8. The final system is constructed based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is
carried out on a continuing basis to prevent large-scale failures and to
minimize downtime.

The business analyst’s role in the spiral is further extended into the development
life cycle. In addition to the requirements definition and liaison activities, the
business analyst is typically quite involved with the prototyping efforts and the
risk assessment stages. The business analyst also works with the customer
during the evaluations and sometimes represents the customer in evaluating the
applicability of the product at that point.

Rational Unified Process

The Rational Unified Process (RUP) was developed by Ivar Jacobson, Grady
Booch, and Jim Rumbaugh at Rational Software Corporation after they had
defined the Unified Modeling Language (UML). Both the UML and the Unified
Process were handed over to the Object Management Group (OMG) to be
established as object-oriented development standards. The approach assumes
the development will be done using object-oriented analysis, design, and
programming as a basis.

“RUP is a software engineering process. It provides a disciplined approach to

assigning tasks and responsibilities within a development organization. Its goal
is to ensure the production of high-quality software that meets the needs of its
end users within a predictable schedule and budget…The Rational Unified
Process is also a process framework that can be adapted and extended to suit
the needs of an adopting organization.” [Philippe Krutchen, RUP: An
Introduction, 3rd edition, Addison-Wesley, 2003.]

The RUP is organized around phases and disciplines in a matrix (see the
illustration that follows) that emphasizes the iterative nature of the process. Each
of the disciplines iterates a number of times through each of the phases until the
exit criteria for that phase are achieved. The phases are not defined so much by
activities, but by goals and outcomes:

Inception: agreement among the team and customer as to what will be

built,
Elaboration: agreement within the team as to the architecture and
design needed to deliver the agreed system behavior,
Construction: the iterative implementation of a fully functional system,
Transition: delivery, defect correction, and tuning to ensure customer
acceptance.

Copyright Steve Blais, 2008-2010 Page 10 of 18

 The Essence of the Business Analyst

Figure 5. Example of the Rational Unified Process

[From Rational Software Corporation]

The RUP is a use-case driven, UML-based iterative development approach that

delivers software incrementally.

The business analyst is usually deeply involved as the “voice of the customer”
throughout all the iterations and phases, more so, of course, in the inception and
elaboration phases.

Copyright Steve Blais, 2008-2010 Page 11 of 18

 BA View of SDLC Models

Agile Approaches

Rapid Application Development

Rapid Application Development (RAD) is also a generic term for a range of
evolutionary prototyping approaches. Many of the approaches have been
developed over the years and are used within organizations and by consulting
firms to produce software results on a more rapid basis than the structured linear
methods. RAD is now in vogue due to the increasing demand for web-based
software to be developed at high speed.

Most RAD approaches nowadays are object-oriented because of the speed

object-oriented languages and tools provide. However, RAD approaches have
been successfully applied to speed up structured analysis, design and
programming efforts.

DSDM
The Dynamic Systems Development Method (DSDM) is a framework of controls
for the development of IT systems to tight timescales. It is independent of any
particular set of tools and techniques. It can be used with object-oriented,
structured analysis, and design approaches in environments ranging from the
individual PC to global distributed systems. DSDM has been used successfully
by organizations in both the public and private sectors.

DSDM provides a generic process which must be tailored for use in a particular
organization dependent on the business and technical constraints. DSDM
outlines a five-phase process:

1. Feasibility Study
The feasibility study assesses the suitability of the application for a
RAD approach and checks that certain technical and managerial
conditions are likely to be met. The feasibility study typically lasts a
matter of weeks.

2. Business Study
The business study scopes the overall activity of the project and
provides a sound business and technical basis for all future work. The
high-level functional and non-functional requirements are baselined, a
high-level model of the business functionality and information
requirements is produced, the system architecture is outlined and the
maintainability objectives are agreed upon.

Copyright Steve Blais, 2008-2010 Page 12 of 18

 The Essence of the Business Analyst

3. Functional Model Iteration

The bulk of development work is in the two iteration phases where
prototypes are incrementally built towards the tested system which is
placed in the user environment during the implementation phase.

4. Design and Build Iteration

During the design and build iteration, the focus is on ensuring that the
prototypes are sufficiently well engineered for use in the operational
environment.

5. Implementation
Implementation consists of putting the latest increment into the
operational environment and training the users. The final step in
implementation is a review of what has been achieved.

Principles of DSDM are:

Active user involvement is imperative,

DSDM teams must be empowered to make decisions,
The focus is on frequent delivery of products,
Fitness for business purpose is the essential criterion for acceptance of
deliverables,
Iterative and incremental development is necessary to converge on an
accurate business solution,
All changes during development are reversible,
Requirements are baselined at a high level,
Testing is integrated throughout the life-cycle,
A collaborative and co-operative approach between all stakeholders is
essential.

Figure 6. Example of DSDM Process

[From Stapleton, Jennifer. DSDM: The Method in Practice. Addison-Wesley, 1997]

Copyright Steve Blais, 2008-2010 Page 13 of 18

 BA View of SDLC Models

Extreme Programming
Extreme Programming (XP) is the poster child for the agile approaches. The
process was developed by Kent Beck, Ward Cunningham, and Ron Jeffries.
When people think of agile they usually think in terms of XP. Extreme
Programming is a software development methodology that represents a
throwback to the very earliest and purest days of software development when
technicians ran the show. Then, software engineers enjoyed greater autonomy
largely because there were few in the management ranks who understood the
task at hand.

XP is the highest risk approach and requires the greatest skill, knowledge and
experience to run it successfully. According to the founders, all the principles of
XP must be adhered to be successful; adapting several of the principles and
trying to do XP will not work.

Figure 7. Example XP Process

The XP process as shown above starts with a project's requirements which are
laid out as individual stories typically written on 3x5 index cards. These stories
have test cases which are written by the customer and developer working as a
team. A test case includes the test and the desired results which, if met, indicate
that that story is complete.

Copyright Steve Blais, 2008-2010 Page 14 of 18

 The Essence of the Business Analyst

The project is done in iterations. At the end of an iteration, the next iteration is
planned out in an iteration planning meeting called the Planning Game. The
customer (with the developers' guidance, of course) decides what stories are to
be implemented in the next iteration, based on what is most important to them,
and what is most practical to implement next.

It is important that all iterations take the same amount of time. This is so that
metrics can be retained that let the XP team know what their velocity (speed of
development) is. The time that it took to complete a given story is recorded so
that the programmers get a good feel for how much effort it takes to do that type
of work.

The stories are broken down into tasks, which are the steps needed to implement
a given user story. Developers then sign up to do those tasks.

On the completion of an iteration, acceptance tests are done to ensure that the
test cases defined in that story have been met. The acceptance tests include
both automated unit testing and customer testing. This ensures that all
requirements are reached since the development is based around those
requirements for which there are definite indicators that tell whether a given
requirement is met. It also breaks down the project into reachable goals rather
than having programmers work away forever on an ever-expanding scope.

Some XP Precepts:

XP calls for short release cycles, a few months at most, so the scope
of any slip is limited. Within a release, XP uses one- to four-week
iterations of customer-requested features for fine-grained feedback
about progress. Within an iteration, XP plans with one- to three-day
tasks, so the team can solve problems even during an iteration.

XP asks the customer to choose the smallest release that makes the
most business sense, so there is less to go wrong before going into
production and the value of the software is greatest.

XP creates and maintains a comprehensive suite of tests, which are

run and re-run after every change (several times a day), to ensure a
quality baseline.

XP calls for the customer to be an integral part of the team. The

specification of the project is continuously refined during development,
so learning by the customer and the team can be reflected in the
software.

Copyright Steve Blais, 2008-2010 Page 15 of 18

 BA View of SDLC Models

XP asks programmers to accept responsibility for estimating and

completing their own work, gives them feedback about the actual time
taken so their estimates can improve, and respects those estimates.
[Kent Beck, Extreme Programming Explained, Addison-Wesley, 2004]

XP Principles

The following principles from Kent Beck’s book Extreme Programming Explained
constitute the essence of XP. Many are the same as principles already
described for other agile processes or in general. Some were initiated by XP and
some were adopted by XP.

1. The Planning Game: Business and development cooperate to produce

the maximum business value as rapidly as possible. The Planning
Game happens at various scales but the basic rules are the same:

– Business comes up with a list of desired features for the system.

Each feature is written out as a user story, which gives the feature
a name, and describes in broad strokes what is required. User
stories are typically written on 3x5 cards.
– Development estimates how much effort each story will take and
how much effort the team can produce in a given time interval.
– Business then decides which stories to implement in what order, as
well as when and how often to produce a production release of the
system.

2. Small Releases: XP teams practice small releases in two important

ways:

– First, the team releases running, tested software, delivering

business value chosen by the customer, [at] every iteration. The
customer can use this software for any purpose, whether evaluation
or even release to end users. The most important aspect is that the
software is visible, and given to the customer, at the end of every
iteration.
– Second, XP teams release to their end users frequently as well.
XP web projects release as often as daily, in-house projects
monthly or more frequently.

3. Simple Design: XP uses the simplest possible design that gets the job
done. The requirements will change tomorrow, so only do what's
needed to meet today's requirements. Design in XP is not a one-time
thing but an all-the-time thing. There are design steps in release
planning and iteration planning, plus teams engage in quick design
sessions and design revisions through refactoring throughout the
course of the entire project.

Copyright Steve Blais, 2008-2010 Page 16 of 18

 The Essence of the Business Analyst

4. Metaphor: Extreme Programming teams develop a common vision of

how the program works which we call the "metaphor". At best, the
metaphor is a simple description of how the program works. XP teams
use a common system of names to be sure that everyone understands
how the system works and where to look to find the correct
functionality you're, or to find the right place to put the functionality
you're about to add.

5. Continuous Testing: XP teams focus on validation of the software at

all times. Programmers develop software by writing tests first, and
then writing code that fulfills the requirements reflected in the tests.
Customers provide acceptance tests that enable them to be certain
that the features they need are provided.

6. Refactoring: XP Team refactors out any duplicate code generated in a

coding session. Refactoring is simplified due to extensive use of
automated test cases.

7. Pair Programming: All production code is written by two programmers

sitting at one machine. This practice ensures that all code is reviewed
as it is written and results in better design, testing, and code.

– Some programmers object to pair programming without ever trying

it. It does take some practice to do well, and you need to do it well
for a few weeks to see the results. Ninety percent of programmers
who learn pair programming prefer it, so it is recommended to all
teams. Pairing, in addition to providing better code and tests, also
serves to communicate knowledge throughout the team.

8. Collective Code Ownership: No single person "owns" a module. Any

developer is expected to be able to work on any part of the codebase
at any time.

9. Continuous Integration: All changes are integrated into the codebase

at least daily. The unit tests have to run 100% both before and after
integration. Infrequent integration leads to serious problems on a
software project. First of all, although integration is critical to shipping
good working code, the team is not practiced at it, and often it is
delegated to people who are not familiar with the whole system.
Problems creep in at integration time that are not detected by any of
the testing that takes place on an unintegrated system. Also weak
integration process leads to long code freezes. Code freezes mean
that you have long time periods when the programmers could be
working on important shippable features but that those features must
be held back.

Copyright Steve Blais, 2008-2010 Page 17 of 18

 BA View of SDLC Models

10. 40-Hour Work Week: Programmers go home on time. In crunch

mode, up to one week of overtime is allowed. But multiple consecutive
weeks of overtime are treated as a sign that something is very wrong
with the process and/or schedule.

11. On-Site Customer: Development team has continuous access to the

customer who will actually be using the system. For initiatives with lots
of customers, a customer representative (i.e., Product Manager) will be
designated for Development Team access.

12. Coding Standards: Everyone codes to the same standards. The

specifics of the standard are not important: what is important is that all
the code looks familiar, in support of collective ownership.

The business analyst has a place in the solution development effort regardless of
the development approach or methodology used by the solution team.

Copyright Steve Blais, 2008-2010 Page 18 of 18

 CONTEXT-FREE PROBLEM DEFINITION QUESTIONS

1. What is the problem?

2. What is the business justification for solving the problem?
3. What are the risks associated with the issues?
4. What if we don’t solve the problem, or don’t solve it within the deadline, if
a deadline is stated?
5. What are the impacts to the business for any given solution?
6. Are there any business constraints?
7. Who is affected by the problem?
8. Who owns the problem?
9. When does the problem occur (intermittent, constant, chronic, etc.)?
And how long has it been going on?
10. What does it look or feel like when the problem is solved (what is the
vision)? (How will we know that the problem is solved?) Where in the
organization does the problem exist?
11. How (when) do you know it’s a problem?
12. What is the alignment of the problem? What business strategy,
objectives, etc. is the problem/opportunity related to?
13. Who is the executive decision maker or sponsor of this project?

Copyright Steven P. Blais, Parkson International, Inc., 2010 Page 1 of 1

 COMPARISON OF THE ROLES OF BUSINESS ANALYST,
PROJECT MANAGER, AND SYSTEMS ANALYST

Comparison of the roles of business analyst, systems analyst, and project

manager

“Since I am doing all three roles, what is the difference between the project
manager, the systems analyst, and the business analyst?”

Business Analyst Project Manager Systems Analyst

Primary Communicate with Communicate with Communicate with
Communication business and everyone the technical and
product solution teams
stakeholders and
the project
manager
Define Solution Define solution to Define solutions to Define solutions to
business problem project problems technical
problems
Identify Problem Identify business Identify project Identify technical
problem problem(s) problem(s)
Provide Justify the problem Justify the project Justify the solution
Justification solving effort by and changes to design and
defining or creating the project scope: technical
the business plan, time or resources changes
C/BA, ROI analysis,
project charter
Scope Definition Define Product Define Project Define Technical
Scope Scope Scope
Address Trade- Confirm business Handle project Identify design or
offs trade-offs or trade- trade-offs, e.g., technical trade-
offs that affect the budget, schedule, offs
product scope, risk
Create Change Be an agent of Be an agent of Be an agent of
change for the change for both change for
organization business and technical aspects
technical aspects and architecture
Analyze and/or Define and manage Define and Define and
Manage Risk product risks and manage risks to manage technical
risks to the the project risks
business
Plan Plan the Plan the entire Plan the technical
requirements project solution
definition

Copyright Steven Blais 2006 – 2010 Page 1 of 3

 Comparison of the Roles of BA, PM, SA

Business Analyst Project Manager Systems Analyst

Monitor and Monitor and
Control control staff and
resources
Analyze and Define and manage Define and
Manage product manage project
Stakeholders stakeholders stakeholders
Manage Manage Mange Mange technical
Expectations customer/user/ management (IT expectations
business and business)
expectations expectations
Identify Identify business Identify project Identify system
Requirements requirements requirements: and technical
(WHAT) resources, skills, requirements
etc. (HOW)
Analyze Impact Analyze product / Analyze project Analyze technical
business impact impact impact
Test Test the product Test the project Technical testing
(acceptance plan
testing)
Evaluate Evaluate business Evaluate project Evaluate
Alternatives solution alternatives alternatives technical
alternatives
Estimate Estimate the time Estimate the time Estimate the time
and effort to define and effort to and effort to
the product successfully develop the
complete the Technical
Project aspects of the
implementation
Perform Project Conduct business Conduct project Conduct
Close Activities analyst close and technical
retrospective and retrospective retrospective and
requirements Project lessons lessons learned
definition lessons learned
learned
Perform Pre- Conduct product Manage project Define technical
Deployment training and turnover activities changes
Activities familiarization to necessary for
ensure smooth deployment
transition (migration,
conversion, etc.)
Perform Assess Manage project Handle technical
Deployment organizational cut-over into issues during cut-
Activities readiness to production over
receive product

Copyright Steven Blais 2006 – 2010 Page 2 of 3

Comparison of the Roles of BA, PM, SA

Business Analyst Project Manager Systems Analyst

Perform Post Assess use of
Deployment product in the
Activities business
environment
Mediate Mediate Product Mediate Project Mediate
disputes among disputes among Technical issues
business, IT and team members among team
upper-level and others members or other
management technical
personnel
Obtain Sign off Obtain sign off for Obtain sign off for Obtain sign off for
solution document project technical solution
and for final completion
deliverable product
Analyze Analyze business Analyze project Analyze technical
processes and processes and processes and
status status status
Report Report status of Report status of Report status of
product and project to upper- technical solution
solution to level management to project
business and and others manager and
project manager others

As can be seen by the table above, the business analyst, project manager, and
systems analyst or technical lead basically perform the same activities with few
exceptions. This is where all the confusion arises. A business analyst does risk
analysis and so does the project manager and systems analyst. The project
manager defines scope, but so do the business analyst and systems analyst.

The difference among the three roles is one of focus. The business analyst
focuses his activities and tasks on the business or product. The project manager
focuses her activities and tasks on the project. The systems analyst focuses his
activities and tasks on the technical aspects of the solution.

The project manager has the overall authority and responsibility for the project
and its success. The systems analyst or technical lead is responsible for the
technical aspects of the implemented solution. The business analyst is
responsible to ensure that the originally defined business problem has been
solved completely and at the expected quality.

Copyright Steven Blais 2006 – 2010 Page 3 of 3