Business analyst

From Wikipedia, the free encyclopedia - View original article

Jump to: navigation, search

A Business Analyst (BA) is someone who analyzes the existing or ideal organization and design of systems, including businesses, departments, and organizations. BAs also assess business models and their integration with technology.


There are at least four tiers of business analysis:

  1. Strategic planning—the analysis of the organization's strategic business needs identification
  2. Operating and business model analysis—defining and analyzing the organization's policies and market business approaches
  3. Process definition and design—the business process modeling (often developed through process modeling and design)
  4. Technical business analysis—the interpretation of business rules and requirements for technical systems (generally within IT, sometimes referred to as systems analysis)

Alternative descriptions[edit]

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."[1]

The International Institute of Business Analysis (IIBA) describes the role 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."[2]

The Certified Software Business Analyst (CSBA) Common Body of Knowledge, defines this as: "uniquely placed in the organization to provide a strong link between the Business Community and Information Technology (IT)."[citation needed]

The role of Business Analyst has evolved from someone who was a part of the business operation and worked with Information Technology to improve the quality of the products and services being delivered by the IT organization to someone who apart from gathering Business requirements, also assists in Integration and Acceptance Testing, supports the development of training and implementation material, participates in the implementation, and provides post-implementation support. Business Analysts today are also involved in the development of project plans and often provide project management skills when these skills are not available in other project participants..

Typical deliverables[edit]

Depending on the level of involvement of business analysis and the goal of the Project sponsor, the deliverable areas range from the Business requirements definition, Functional requirements definition (converting detailed business rules into system requirements), As-Is process definition, To-Be process definition to Business case (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 records requirements in some form of requirements management tool, whether a simple spreadsheet or a complex application.

Business requirements
(project initiation document), what the project must achieve, and according to what quality measures (e.g., key performance indicators or tangible objectives). They are usually expressed in terms of broad outcomes the business requires (e.g., Ability statements), 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: The ability to accept and process customer feedback about the provided service.
Functional requirements
describe what the system, process, or product/service must do to fulfill the business requirements (i.e. the system shall ...). 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. A system does not necessarily mean an IT or computer program. A system could be a non-IT program (e.g., ICMS: a system based program used within fire fighting, with which fire fighters use a plastic card system to indicate that they are combating an incident. This provides the Incident Controller with a means of tracking resources and safety).
  • An example of a Functional Requirement:
    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 must be correctly documented. This deliverable can also reflect how the product is designed and developed, and define how test cases must be formulated. Remember, 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. A few examples are (not an exhaustive list): performance, scalability, security and usability. These are often included within the System Requirements or Functional 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 thereafter are no longer 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 that records requirements through each stage of the requirements gathering process. It matches high level concepts to scope items, which map to individual requirements, which map to corresponding functions. This matrix takes into account changes in scope during the project life. At the end of a project, this matrix shows each function built into a system, its source, and the reason that any stated requirements may not have been delivered.

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.


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), and defines a body of knowledge for the field (Business Analysis Body of Knowledge or BABOK). However this is not well established yet in the Industry. Few BA jobs require that candidates be certified.

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, Banking in the Information Framework (IFW) and Emergency agencies in the Prevention Preparation Response and Recovery model (PPRR).

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.

Benefits and drawbacks of business analysts in software projects[edit]

The role of the BA is key in software development projects, especially at the inception of the project. They serve as the mediator or the bridge between the Technical and Business end of stakeholders. Typically, in organizations where no formal structure or processes exist, the Business Owners and Developers communicate directly. Assuming that Developers have no organizational skills or time to spend attention to this topic, this can present a problem: the goal of the Business Owner is to solve a problem very quickly, and the goal of the Developer is to discover all underlying needs and provide an answer as quickly as possible. This can lead to creating changes in a vacuum, not necessarily taking the needs of all users of the system into account, depending on the organizational skills of the involved Developers.

This can lead to a situation where there are no or 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 (i.e. Methodology to gather requirements: As-Is process baseline, To-Be process, workshops) and formalization of requirements (i.e. gather the required Capabilities) into this process, which may lead to increased foresight or outcome among Business Owners. It is very helpful in business development.[3]

Drawbacks include situations where the Business Analyst just works as 'man in the middle', without helping Business Owner, Subject Matter experts and Developers to streamline the long term goals results in ab loss of time as well as information.[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 includes business analysts who break down communication barriers between stakeholders and developers.[4]

See also[edit]


  1. ^ Paul, Debra; Donald Yeates, Keith Hindle (April 2006). Business analysis. BCS. p. 4. ISBN 978-1-902505-70-1. 
  2. ^ IIBA (March 2009). Kevin Brennan, ed. A Guide to the Business Analysis Body of Knowledge (2.0 ed.). IIBA. p. 3. ISBN 978-0-9811292-1-1. 
  3. ^ a b "Business analyst role key in SOA software development projects". TechTarget. Retrieved 2008-08-26. 
  4. ^ "Rethinking the Role of Business Analysts". Retrieved 2008-08-26. 

External links[edit]