5 business analysis deliverables

Below is a list of what I think are the 5 major business analysis deliverables for defining and designing a technological solution for business.

This list follows the classic approach – not an agile approach – to implementation. However, these deliverables, or components of them, can be used in agile methodologies.

Business Analysis Deliverables

1. Business Analysis Plan

If you’re planning a business analysis effort then the following deliverables are required.

• Business Analysis Approach. This approach document contains the following key elements:
  • Background. Describes the purpose of the project and some background information.
  • Business Drivers. The business drivers, or the reasons why, for the proposed initiative. These help formulate the high level business requirements which determine the scope and purpose of the project.
  • Problem Statement. The problem statement describing the reasons for the project in practical business related terms using real examples to emphasise the need for the new initiative.
  • Vision. An aspirational description of what the organisation would like to achieve or accomplish as an outcome of the project.
  • Scope. The scope and boundaries of the change required. This includes what is exclude from scope.
  • Dependencies. Dependencies establish the links, and the type of links, between all the tasks of a project. There are also dependencies with other projects.
  • Key Roles and Responsibilities. Defines the roles and responsibilities of the people involved in the project.
• Stakeholder Engagement Plan. This document describes a list of stakeholders required for further consultation, who you’ll be eliciting requirements from and how.

2. Business Requirements Specification

The business requirements document will include the business drivers and problem statement, and the following.

• Business Drivers. The business drivers identified in the planning are refined as new information is gathered.
• Problem Statement. The problem domain is better understood after consultation with stakeholders.
• Stakeholder Model. The stakeholder model describes the internal workers (i.e., roles and entities that work within the system) and the external actors (those who interact externally with the system).
• Business Domain Model. Business domain model are the structural representation of the business shows the high level view of the business objects and entities within the problem domain.
• Business Use Cases. Business use cases identify the functional areas of the business that will be modelled.
• Business Activity Diagrams. Business activity diagrams are the behavioural representation of the business and are developed for each business use case.
• Business Requirements. Business requirements are platform independent, relevant, and traceable. They are realised against the business use cases.

3. Business Case

If it’s required, my preference is that a business case is developed after writing the business requirements. This is because a lot of information has been gathered about how the business currently works (current state) and what improvements can be made (future state). With this information tangible and financial benefits can be accurately measured and presented as the case for change. The key elements of a business case are:

• Background. Describes the purpose of the business case and some background information.
• Current Situation / Problem Statement. The current situation describes the problem and associated risks with the current situation.
• Options Analysed. Describes the options analysed and key findings.
• Recommendation. Based on the options analysed, this is the recommendation including what the approvers and funders need to do.
• Costs and Benefits. The costs and benefits describe the basis on which the benefits were identified and/or calculated (if financial). It details the financial and other benefits of the recommendation.
• Risks. Identifies any risks, constraints, shortcomings or limitations of the recommended approach.

The business case deliverable can occur before the business requirements specification, or after. Often I’ve worked on projects where the business case was developed after the business requirements stage. This was in situations where the business case needed to assess options for technology or process implementation and/or implementation approach. In this case, the information gathered during the business requirements stage provided valuable tangible benefits (and costs). For example, the benefits of how the automation of a manual process (or several processes) will create substantial savings and opportunities for an organisation. This is information that could not have been known without first developing the business requirements.

4. Functional Specification

The key elements of the functional specification are:

• System Use Cases. System use cases identify the function or service that a system will provide.
• User Requirements. These are traceable user requirements which are realised against the system use cases.
• System Activity Diagrams. System activity diagrams are the behavioural representation of the system and describe the interactions between an actor and the system.
• Class Diagrams. Class diagrams are the structural representation of the system and show the domain concepts traced back to the use cases.
• Functional Requirements. These are the functional requirements and features that are platform dependent and testable.

5. Non-Functional Specification

Non-functional requirements must be associated with specific project functionality/deliverables. The key elements of the non-functional requirements specification are:

• Hardware Requirements. Includes a detailed description of specific hardware requirements including such as type of hardware, brand name, specifications, size, and security.
• Software Requirements. Software requirements includes a detailed description of specific software requirements such as in-house development or purchasing, security, coding language, version numbering, functionality, data, interface requirements, brand name, and specifications.
• Performance Requirements. Includes a detailed description of specific performance requirements and associate them to specific project functionality/deliverables. Include information such as cycle time, speed per transaction, test requirements, minimum bug counts, speed, reliability, and utilisation.
• Supportability Requirements. Describes all of the technical requirements that affect supportability and maintainability such as coding standards, naming conventions, maintenance access, and required utilities.
• Security Requirements. Describes all of the technical requirements that affect security such as security audits, cryptography, user data, system identification/authentication, and resource utilisation.
• Interface Requirements. Describes all of the technical requirements that affect interfaces such as protocol management, scheduling, directory services, broadcasts, message types, error and buffer management, and security.
• Availability Requirements. Describes all of the technical requirements that affect availability such as hours of operation, level of availability required, down-time impact, and support availability.
• Compliance Requirements. Describes the existing compliance environment as it affects project requirements.

Often functional and non-functional specifications are written in the one document, but can be produced as separate deliverables as shown above. The format of deliverables can vary across different organisations. Even terminology varies from one organisation to another. For instance, one organisation may determine meaning of a business requirement to be quite different to the meaning that’s stated in the BABOK. So it’s important to spend time speaking with the client to ensure an understanding of the required deliverables, and what should be contained within them.