Business analyst

[edit] Typical Deliverables

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. However, stakeholders may not always
be users of a system.

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

[edit] 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 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
• Discovering Real Business Requirements for Software Project Success by Robin F. Goldsmith.
• Business Modeling with UML by Eriksson & Penker
• Software Requirements, 2nd Edition by Karl E. Wiegers (Microsoft Press, 2003)

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
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. One resource that describes typical
BA skills, knowledge needed, and job responsibilities is the
"Requirements Analyst Job Description" [1].

[edit] 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.^[4]