The structure of business analysis documents isn't a commonly discussed topic. This article will show what documents are produced by a BA and the main sections they contain.
These are the main documents produced by a BA over the course of a project:
The diagram below shows the attributes common to all documents:
Current State Analysis
Once a project has been mandated and the Project Initiation document (PID) is drafted, a business analyst can start to work on requirements gathering. In my experience the best way to tackle this task is to start from current state analysis. It helps understand the business need, primary pain points, business processes affected, the stakeholders involved in these processes, and so on.
The area of the current state analysis is illustrated below:
The main purpose of the analysis is to present the “AS IS” state: the existing business context, background, business functions and existing business processes, and finally stakeholders involved in these business processes. Depending on the project nature, some components of the underlying infrastructure can be included in the document as well.
A Current State Analysis document lists the key pain points within the identified business processes and tasks within them, and highlights the areas where a change is expected.
The last section of the document is about presenting recommendations. It recaps the key findings and lists the key changes expected. Any caveats should be presented here as well.
The content structure of the Current State Analysis document is presented below:
This document serves as a foundation or a reference point for other artifacts produced by a business analyst. The other documents will be discussed in the following articles.
Project Vision
The Project Vision is a document which is shared by a project manager and business analyst. They work together to outline the problem statement, determine the desired state, describe the criteria of business acceptance of the deliverables and how project success will be measured. The document contains a section with stakeholder analysis which shows all the parties involved along with their responsibilities and needs:
The business analyst adds the high level requirements which are within the scope of the project, and marks each requirement as compulsory or optional. To clearly define the project scope and avoid ambiguity, all out-of-scope requirements are also listed at the end of the section.
Based on the results of the current state analysis the business analyst describes the current business context, the key business processes and services used to support them. After that the required changes are mapped to the current business context. It can be a good idea to present this mapping as a diagram for easy communication of the proposed changes to the business stakeholders.
Solution Vision
Once the Project Vision document is approved, the preparation of the Solution Vision document starts.
First, the business analyst recaps the problem statement from the Project Vision artifact. The solution statement describes the target audience of the solution, what will be satisfied by the solution and what the key benefits will be. The statement of differentiation of the solution from possible alternative options is added as a conclusive point in positioning of the solution.
The document describes stakeholders within the target audience along with their roles using a RACI matrix.
The main part of a Solution Vision is a detailed section devoted to the solution capabilities comprised of both functional and non-functional features, with priorities given by the business stakeholders.
The next section presents the business context in its future "to be" state. It's a good idea to include a a diagram illustrating the key changes and additions to the existing state, as well as a brief narrative to clarify the proposed changes.
Similarly to the Project Vision document, the features that are out of scope are clearly listedin the last section to make sure everyone is on the same page with regards to what will be implemented.
Business Requirements
This document focuses on providing details about the current processes and gives enough information to describe the business problem and how it fits into the scope of the project. This section reiterates the findings of the Current State Analysis document, however here they are aligned with the project objectives.
The business requirements that are going to be fulfilled by the solution are listed in the “In Scope” section. Business rules that apply to the described requirements are presented in a separate section. This approach simplifies the confirmation of the rules with business stakeholders.
Any assumptions and dependencies identified in relation to the business requirements are to be listed in the appropriate section. The proposed changes to stakeholder roles, new or modified business processes and business services that support them are presented in the last section.
Business Process Design
This document focuses on the scope of changes to business processes, providing details about the current business context, existing business processes, and stakeholders involved in these business processes.
It also describes the future state: the proposed business processes and the “to be” information environment. The new processes are accompanied with narratives to facilitate communication of the proposed changes to stakeholders and business end users. This “as is” section reiterates the findings of the Current State Analysis document, however here they are aligned with the changes to supporting business services.
Any assumptions and dependencies identified in relation to changes to the business processes are listed in the appropriate section.
Use Case Model
The Use Case Model lists all the scenarios for using the solution required by the business stakeholders. It is useful to describe the solution as a set of functional areas and group the scenarios per functional area. Such an approach allows to use this document more efficiently in communication with the business stakeholders as they can easily refer to the sections of their interest.
The model lists all possible scenarios in scope, their brief summary, actors involved in each scenario, frequency of use, triggering events and the two possible outcomes – success and failure.
One of the key attributes of the scenarios is a reference to the high-level requirements and required capabilities which allows to establish traceability.
Note: when making changes to Use Case Specifications, do not forget to update the Use Case Model document accordingly.
Use Case Specification
A Use Case Specification document presents more detailed information about the use cases in the Use Case Model document.
Each specification includes:
System-Wide Requirements
This document is prepared when the Business Requirements, Use Case Model and Use Case Specifications are complete. The main purpose of the document is to present a “qualitative” side of the solution.
The “Load patterns” section is the most interesting as it illustrates how the solution is expected to be used during a business day. This information gives good insight into business requirements from the “non-functional” perspective and helps clarify the business requirements where required.
As solutions are often based on information technology, some attention should be given to solution resilience. Disaster mitigation approaches and solution recovery requirements play a major role here.
It is a rare case nowadays that a solution is completely new. The common practice is to integrate the solution into the existing business environment. The system-wide requirements document describes the interfaces with internal and external systems and solutions, the data flowing between them, its formats and data elements. Where the solution should interface with external systems, samples of data must be presented in appendices.
Apart from business reporting capabilities, the solution must provide reporting capabilities for monitoring how the solution operates. These reports are listed in the last section of the document.
Solution Glossary
Business stakeholders often use terms and jargon in their communication. To get up to speed with this terminology (you can be quite new to it), the Solution Glossary document is used. It helps establish common terminology for the project team and key stakeholders, and for use within the solution. The structure of this document is simple:
It's a good practice to divide the solution into functional areas. These functional areas serve as small knowledge domains for the stakeholders involved in the project. This document serves as a reference point for all the previously discussed documents.
Author: Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of visual learning and reference materials for business analysts.
Our goal is to make business analysis easy to learn by presenting practical information in an engaging way. Have a look at what we do at http://blog.aoteastudios.com