business analyst doc

1. Business analyst
A Business Analyst (BA) analyzes the organization and design of businesses, government
departments, and non-profit organisations; they also assess business models and their
integration with technology.
There are at least four tiers of business analysis:
1. Planning Strategically - The analysis of the organisation business strategic needs
2. Operating/Business model analysis - the definition and analysis of the organisations
policies and market business approaches
3. Process definition and design - the business process modelling (often developed
through process modelling and design)
4. IT/Technical business analysis - the interpretation of business rules and requirements
for technical systems (generally IT)
Within the systems development life cycle domain (SDLC), the business analyst typically
performs a liaison function between the business side of an enterprise and the providers of
services to the enterprise. A Common alternative role in the IT sector is business analyst,
systems analyst, and functional analyst, although some organizations may differentiate
between these titles and corresponding responsibilities.
The Australian Institute for Business Analysis defines the role of the business analyst more
broadly than the more technically focused systems business analyst as "business analysis is
the capability to analyse the issues that need to be solved to deliver intended business
outcomes."
BCS, The Chartered Institute for IT, proposes the following definition of a business analyst:
"An internal consultancy role that has responsibility for investigating business systems,
identifying options for improving business systems and bridging the needs of the business
with the use of IT."
In its book A Guide to the Business Analysis Body of Knowledge (BABOK), the International
Institute of Business Analysis (IIBA) describes the role as: "the set of tasks and techniques
used to work as a liaison among stakeholders in order to understand the structure, policies,
and operations of an organization, and to recommend solutions that enable the organization to
achieve its goals."
Typical Deliverables

2. Depending on the level of thinking about business analysis, the areas range from the technical
Business Analysis role (converting detailed business rules into system requirements), to
conversion of shareholder return and risk appetite into strategic plans.
The following section focuses on the IT sector perspective around business analysis, where
much of the deliverables are around requirements. The BA will record requirements in some
form of requirements management tool, whether a simple spreadsheet or a complex
application.
Business Requirements
(project initiation document), what the needed achievements will be, and the quality
measures. They are usually expressed in terms of broad outcomes the business
requires, rather than specific functions the system may perform. Specific design
elements are usually outside the scope of this document, although design standards
may be referenced.
Example: Improve the readability of project plans.
Functional requirements
describe what the system, process, or product/service must do in order to fulfill the
business requirements. Note that the business requirements often can be broken up
into sub-business requirements and many functional requirements. These are often
referred to as System Requirements although some functionality could be manual and
not system based, e.g., create notes or work instructions.
An example that follows from previous business requirement example:
1. The system shall provide the ability to associate notes to a project plan.
2. The system shall allow the user to enter free text to the project plan
notes, up to 255 characters in length.
User (stakeholder) requirements
are a very important part of the deliverables, the needs of the stakeholders will have to
be correctly interpreted. This deliverable can also reflect how the product will be
designed, developed, and define how test cases must be formulated.
Quality-of-service (non-functional) requirements
are requirements that do not perform a specific function for the business requirement
but are needed to support the functionality. For example: performance, scalability,
quality of service (QoS), security and usability. These are often included within the
System Requirements, where applicable.
Implementation (transition) requirements
are capabilities or behaviors required only to enable transition from the current state
of the enterprise to the desired future state, but that will thereafter no longer be
required.
Report specifications
define the purpose of a report, its justification, attributes and columns, owners and
runtime parameters.
The traceability matrix
is a cross matrix for recording the requirements through each stage of the
requirements gathering process. High level concepts will be matched to scope items

3. which will map to individual requirements which will map to corresponding
functions. This matrix should also take into account any changes in scope during the
life of the project. At the end of a project, this matrix should show each function built
into a system, its source and the reason that any stated requirements may not have
been delivered.
Prerequisites
There is no defined way to become a business analyst. Often the BA has a technical
background, whether having worked as a programmer or engineer, or completing a Computer
Science degree. Others may move into a BA role from a business role - their status as a
subject matter expert and their analytical skills make them suitable for the role. Business
analysts may overlap into roles such as project manager or consultant. When focused on
specific systems, the term Business Systems Analyst may be used.
A BA does not always work in IT-related projects, as BA skills are often required in
marketing and financial roles as well.
The Australian Institute of Business Analysis provides a certification approach for business
analysts that provides multiple levels of comptency evaluation.
The International Institute of Business Analysis provides a certification program for business
analysts (Certified Business Analyst Professional or CBAP), as well as providing a body of
knowledge for the field (Business Analysis Body of Knowledge or BABOK).
A few consulting companies provide BA training courses and there are some consulting
books on the market (UML, workshop facilitation, consultancy, communication skills). Some
helpful text books are:
Customer-Centered Products by Ivy F. Hooks and Kristin A. Farry (Amazon, USA,
2001).
UML for the IT Business Analyst: A Practical Guide to Object-Oriented
Requirements Gathering by Howard Podeswa,
Writing Effective Use Cases by Alistair Cockburn and
Discovering Real Business Requirements for Software Project Success by Robin F.
Goldsmith.
Business Modeling with UML by Eriksson &Penker
BAs work in different industries such as finance, banking, insurance, telecoms, utilities,
software services, and so on. Due to working on projects at a fairly high level of abstraction,
BAs can switch between industries. The business domain subject areas BAs may work in
include workflow, billing, mediation, provisioning and customer relationship management.
The telecom industry has mapped these functional areas in their Telecommunications
Operational Map (eTOM) model.
Finally, Business Analysts do not have a predefined and fixed role as they can take a shape in
operations (technology architect or project management) scaling, sales planning, strategy
devising or even in developmental process. Hence they get a different name for the played

4. role. Even the International Institute of Business Analysis and its associates have had several
editions of the roles and responsibilities of a person undertaking the BA role.
Benefits of including Business Analysts in software
projects
The role of the BA is key in software development projects. Typically, in organizations
where no formal structure or processes exist, the Business Owners and Developers
communicate directly. This can present a problem: the goal of the Business Owner is to get
what they want very quickly, and the goal of the Developer is to give the Business Owner
what they want as quickly as he/she can give it to him/her. This leads to creating changes in a
vacuum, not necessarily taking the needs of all users of the system into account. There is
rarely any detailed definition of the requirements, and many times, the real reason for the
request may not make good business sense. There tends to be no emphasis on long term,
strategic goals that the business wants to achieve via Information Technology. The Business
Analyst can bring structure and formalization of requirements into this process, which may
lead to increased foresight among Business Owners.[3]
In recent years, there has been an upsurge of using analysts of all sorts: business analysts,
business process analysts, risk analysts, system analysts. Ultimately, an effective project
manager will include Business Analysts who break down communication barriers between
stakeholders and developers
Business analysis

5. Business analysis is the discipline of identifying business needs and determining solutions to
business problems. Solutions often include a systems development component, but may also
consist of process improvement or organizational change or strategic planning and policy
development. The person who carries out this task is called a business analyst or BA.
Those BAs who work solely on developing software systems may be called IT Business
Analysts, Technical Business Analysts, or Systems Analysts.
Business analysis sub-disciplines
Business analysis as a discipline has a heavy overlap with requirements analysis sometimes
also called requirements engineering, but focuses on identifying the changes to an
organization that are required for it to achieve strategic goals. These changes include changes
to strategies, structures, policies, processes, and information systems.
Examples of business analysis include:
Enterprise analysis or company analysis focuses on understanding the needs of the business
as a whole, its strategic direction, and identifying initiatives that will allow a business to meet
those strategic goals.
Requirements planning and management involves planning the requirements development
process, determining which requirements are the highest priority for implementation, and
managing change.
Requirements elicitation describes techniques for collecting requirements from stakeholders
in a project.
Requirements analysis describes how to develop and specify requirements in enough detail to
allow them to be successfully implemented by a project team.
Requirements communication describes techniques for ensuring that stakeholders have a
shared understanding of the requirements and how they will be implemented.
Solution assessment and validation describes how the business analyst can verify the
correctness of a proposed solution, how to support the implementation of a solution, and how
to assess possible shortcomings in the implementation.
Business analysis techniques
There are a number of techniques that a Business Analyst will use when facilitating business
change. These range from workshop facilitation techniques used to elicit requirements, to
techniques for analysing and organising requirements.
Some of these techniques include:
PESTLE
This is used to perform an external environmental analysis by examining the many different
external factors affecting an organisation.
The six attributes of PESTLE:
Political (Current and potential influences from political pressures)
Economic (The local, national and world economy impact)

6. Sociological (The ways in which a society can affect an organisation)
Technological (The effect of new and emerging technology)
Legal (The effect of national and world legislation)
Environmental (The local, national and world environmental issues)
MOST
This is used to perform an internal environmental analysis by defining the attributes of
MOST to ensure that the project you are working on is aligned to each of the 4 attributes.
The four attributes of MOST
Mission (where the business intends to go)
Objectives (the key goals which will help achieve the mission)
Strategies (options for moving forward)
Tactics (how strategies are put into action)
SWOT
This is used to help focus activities into areas of strength and where the greatest opportunities
lie. This is used to identify the dangers that take the form of weaknesses and both internal and
external threats.
The four attributes of SWOT:
Strengths - What are the advantages? What is currently done well?
Weaknesses - What could be improved? What is done badly?
Opportunities - What good opportunities face the organisation?
Threats - What obstacles does the organisation face?
CATWOE
This is used to prompt thinking about what the business is trying to achieve. Business
Perspectives help the Business Analyst to consider the impact of any proposed solution on the
people involved.
There are six elements of CATWOE
Customers - Who are the beneficiaries of the highest level business process and how
does the issue affect them?
Actors - Who is involved in the situation, who will be involved in implementing
solutions and what will impact their success?
Transformation Process - What processes or systems are affected by the issue?
World View - What is the big picture and what are the wider impacts of the issue?
Owner - Who owns the process or situation being investigated and what role will they
play in the solution?
Environmental Constraints - What are the constraints and limitations that will impact
the solution and its success?
De Bono 6Hat

7. This is often used in a brainstorming session to generate and analyse ideas and options. It is
useful to encourage specific types of thinking and can be a convenient and symbolic way to
request someone to “switch gear. It involves restricting the group to only thinking in specific
ways - giving ideas & analysis in the “mood” of the time. Also known as the Six Thinking
Hats.
White: Pure, facts, logical.
Green: Creative, emotional
Yellow: Bright, optimistic, positive.
Black: Negative, devil‟s advocate.
Red: Emotional.
Blue: Cold, control.
Not all colours / moods have to be used
Five Why's
Five Whys is used to get to the root of what is really happening in a single instance. For each
answer given a further 'why' is asked.
MoSCoW
This is used to prioritise requirements by allocating an appropriate priority, gauging it against
the validity of the requirement itself and its priority against other requirements.
MoSCoW comprises:
Must have - or else delivery will be a failure
Should have - otherwise will have to adopt a workaround
Could have - to increase delivery satisfaction
Would like to have in the future - but won't have now
VPEC-T
This technique is used when analyzing the expectations of multiple parties having different
views of a system in which they all have an interest in common, but have different priorities
and different responsibilities.
Values - constitute the objectives, beliefs and concerns of all parties participating.
They may be financial, social, tangible and intangible
Policies - constraints that govern what may be done and the manner in which it may
be done
Events - real-world proceedings that stimulate activity
Content - the meaningful portion of the documents, conversations, messages, etc. that
are produced and used by all aspects of business activity
Trust - trusting (or otherwise) relationship between all parties engaged in a value
system
Roles of Business Analysts

8. As the scope of business analysis is very wide, there has been a tendency for business
analysts to specialize in one of the three sets of activities which constitute the scope of
business analysis.
Strategist
Organizations need to focus on strategic matters on a more or less continuous basis in
the modern business world. Business analysts, serving this need, are well-versed in
analyzing the strategic profile of the organization and its environment, advising senior
management on suitable policies, and the effects of policy decisions.
Architect
Organizations may need to introduce change to solve business problems which may
have been identified by the strategic analysis, referred to above. Business analysts
contribute by analyzing objectives, processes and resources, and suggesting ways by
which re-design (BPR), or improvements (BPI) could be made. Particular skills of this
type of analyst are "soft skills", such as knowledge of the business, requirements
engineering, stakeholder analysis, and some "hard skills", such as business process
modeling. Although the role requires an awareness of technology and its uses, it is not
an IT-focused role.
Three elements are essential to this aspect of the business analysis effort: the redesign
of core business processes; the application of enabling technologies to support the
new core processes; and the management of organizational change. This aspect of
business analysis is also called "business process improvement" (BPI), or
"reengineering".
Systems analyst
There is the need to align IT Development with the systems actually running in
production for the Business. A long-standing problem in business is how to get the
best return from IT investments, which are generally very expensive and of critical,
often strategic, importance. IT departments, aware of the problem, often create a
business analyst role to better understand, and define the requirements for their IT
systems. Although there may be some overlap with the developer and testing roles,
the focus is always on the IT part of the change process, and generally, this type of
business analyst gets involved, only when a case for change has already been made
and decided upon.
In any case, the term "analyst" is lately considered somewhat misleading, insofar as analysts
(i.e. problem investigators) also do design work (solution definers).
Business process improvement
A business process improvement (BPI) typically involves six steps:
1. Selection of process teams and leader
Process teams, comprising 2-4 employees from various departments that are involved in the
particular process, are set up. Each team selects a process team leader, typically the person
who is responsible for running the respective process.
2. Process analysis training
The selected process team members are trained in process analysis and documentation
techniques.

9. 3. Process analysis interview
The members of the process teams conduct several interviews with people working along the
processes. During the interview, they gather information about process structure, as well as
process performance data.
4. Process documentation
The interview results are used to draw a first process map. Previously existing process
descriptions are reviewed and integrated, wherever possible. Possible process improvements,
discussed during the interview, are integrated into the process maps.
5. Review cycle
The draft documentation is then reviewed by the employees working in the process.
Additional review cycles may be necessary in order to achieve a common view (mental
image) of the process with all concerned employees. This stage is an iterative process.
6. Problem analysis
A thorough analysis of process problems can then be conducted, based on the process map,
and information gathered about the process. At this time of the project, process goal
information from the strategy audit is available as well, and is used to derive measures for
process improvement.
Goal of business analysts
Ultimately, business analysts want to achieve the following outcomes:
Reduce waste
Create solutions
Complete projects on time
Improve efficiency
Document the right requirements
One way to assess these goals is to measure the return on investment (ROI) for all projects.
Keeping score is part of human nature as we are always comparing ourselves or our
performance to others, no matter what we are doing. According to Forrester Research, more
than $100 billion is spent annually in the U.S. on custom and internally developed software
projects. For all of these software development projects, keeping score is also important and
business leaders are constantly asking for the return or ROI on a proposed project or at the
conclusion of an active project. However, asking for the ROI without really understanding
the underpinnings of where value is created or destroyed is putting the cart before the horse.
Reduce waste and complete projects on time
Project delays are costly in three different dimensions:
Project costs – For every month of delay, the project team continues to rack up costs
and expenses. When a large part of the development team has been outsourced, the
costs will start to add up quickly and are very visible if contracted on a time and
materials basis (T&M). Fixed price contracts with external parties limit this risk. For
internal resources, the costs of delays are not as readily apparent, unless time spent by

10. resources is being tracked against the project, as labor costs are essentially „fixed‟
costs.
Opportunity costs – Opportunity costs come in two flavors – lost revenue and
unrealized expense reductions. Some projects are specifically undertaken with the
purpose of driving new or additional revenues to the bottom line. For every month of
delay, a company foregoes a month of this new revenue stream. The purpose of other
projects is to improve efficiencies and reduce costs. Again, each month of failure
postpones the realization of these expense reductions by another month. In the vast
majority of cases, these opportunities are never captured or analyzed, resulting in
misleading ROI calculations. Of the two opportunity costs, the lost revenue is the
most egregious – and the impacts are greater and longer lasting.
N.B. On a lot of projects (particularly larger ones) the project manager is the one tasked with
ensuring that a project is completed on time. The BA's job is more to ensure that if a project
is not completed on time then at least the highest priority requirements are met.
Document the right requirements
Business analysts want to make sure that they define the application in a way that meets the
end-users‟ needs. Essentially, they want to define the right application. This means that they
must document the right requirements through listening carefully to „customer‟ feedback, and
by delivering a complete set of clear requirements to the technical architects and coders who
will write the program. If a business analyst has limited tools or skills to help him elicit the
right requirements, then the chances are fairly high that he will end up documenting
requirements that will not be used or that will need to be re-written – resulting in rework as
discussed above. The time wasted to document unnecessary requirements not only impacts
the business analyst, it also impacts the rest of the development cycle. Coders need to
generate application code to perform these unnecessary requirements and testers need to
make sure that the wanted features actually work as documented and coded. Experts estimate
that 10% to 40% of the features in new software applications are unnecessary or go unused.
Being able to reduce the amount of these extra features by even one-third can result in
significant savings.
Improve project efficiency
Efficiency can be achieved in two ways: by reducing rework and by shortening project
length.
Rework is a common industry headache and it has become so common at many organizations
that it is often built into project budgets and time lines. It generally refers to extra work
needed in a project to fix errors due to incomplete or missing requirements and can impact
the entire software development process from definition to coding and testing. The need for
rework can be reduced by ensuring that the requirements gathering and definition processes
are thorough and by ensuring that the business and technical members of a project are
involved in these processes from an early stage.
Shortening project length presents two potential benefits. For every month that a project can
be shortened, project resource costs can be diverted to other projects. This can lead to savings

11. on the current project and lead to earlier start times of future projects (thus increasing revenue
potential).