Business Analyst - Typical Deliverables

Typical Deliverables

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 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 (e.g., KPIs 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 in order 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 will be 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 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.

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.