Business analyst

For the ESRI software product, see ArcGIS Business Analyst.

The term Business Analyst (BA) is used to describe a person who practices the discipline of business analysis. A business analyst or "BA" is responsible for analyzing the business needs of clients to help identify business problems and propose solutions. Within the systems development life cycle domain, the business analyst typically performs a liaison function between the business side of an enterprise and the providers of services to the enterprise. Common alternative titles are business analyst, systems analyst, and functional analyst, although some organizations may differentiate between these titles and corresponding responsibilities.

The International Institute of Business Analysis has the following definition of the role: "A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals." The Business Analysis Body of Knowledge (BABOK) describes common activities, tasks and deliverables of the BA.

The British Computer Society 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."

Typical deliverables

Business Requirements constitute specifications of what the business wants, the purposes of initializing a specific project (Project Initialization 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 fulfil 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. System must provide the ability to associate notes to a project plan.
  2. System must allow the user to enter free text to the project plan notes, up to 255 characters in length.

User 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. The Business Analyst will record requirements in a Requirements Management Tool; this can be a simple spreadsheet or a complex application.

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.

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.

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

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.

See also

• Business analysis
• Business process reengineering
• Information technology
• International Institute of Business Analysis
• Systems analysis
• Information Architect
• Use case
• Spreadmart

External links

• International Institute of Business Analysts (IIBA)
• Business analysis and the project lifecycle in practice - a briefing study guide
• Business Analyst Career Path