The Structure of Business Analysis Documents


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:

  • Current state analysis document

  • Project vision document

  • Solution vision document

  • Business requirements document

  • Business process design document

  • Use case model document

  • Use case specification document

  • System-wide requirements document

  • Solution glossary

The diagram below shows the attributes common to all documents:


 Artifact Structure of Business Analysis 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:


Current State Analysis Area


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:


Current State Analysis Document Structure 


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:


Project Vision Document Structure 


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.


Solution Vision Document Structure 


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.


Business Requirements Document Structure 


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.


Business Process Design Document Structure 


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.


Use Case Model Document Structure 


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.

Use Case Specification Document Structure 


Each specification includes:

  • Brief use case overview

  • Reference to the functional area

  • Preconditions

  • Actors involved

  • Main flow

  • Alternative flows

  • Exception handling flows

  • Functional requirements for the solution

  • Traceability to the business requirements

  • Market or business rules applicable to the scenario

  • User interface, controls and data 


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.

System-wide Requirements Document Structure 


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:

Solution Glossary Document Structure 


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

Like this article:
  133 members liked this article


datamodel posted on Tuesday, March 15, 2011 12:38 PM
So data requirements need to be documented only for data that appears in interfaces for users or other systems? Or have I missed something?
Alex - Aotea Studios posted on Wednesday, March 16, 2011 4:48 AM
No, you have not missed anything. I think you might have been misled by the term data used in different context.

The term "data" is used widely in business analysis. When a BA works on a business requirements document, he is dealing with data available to the users and is concerned with transformations of the data that take place after each interaction of the user and the solution.

When preparing system wide requirements, the BA is mostly interested in data exchange between the solution and its environment. Here the BA focuses on data formats, data validation, data samples to support UAT and so on.

I hope this helps.
cisco.leon posted on Tuesday, June 7, 2011 12:45 PM
Do you have Word templates for the above deliverables you've mentioned?
Alex - Aotea Studios posted on Tuesday, June 7, 2011 6:58 PM
cisco.leon: We do have a set of templates although it's not free. You can find out more about it at
Leslie posted on Monday, June 20, 2011 2:36 PM
difficult to make comment without understanding the process being used and whether the document types capture all of the necessary information for their purpose (but i suppose that IS a comment).

but, it appears that the process is concerned with a business solution that is to be implemented by a new system and not enterprise wide, nor impacting existing applications. If this was the case i might organise the use case model diffrently.
(for example: 'It is useful to describe the solution as a set of functional areas and group the scenarios per functional area.' - I would replace functional area with 'system responsibility' and say that this is necessary, not just useful.
Also, there is no discussion on interface specifications .. etc.)

My major comment though concerns the BA Artifact in unnumbered figure that appears to be the first diagram in the article. This unnumbered diagram (sorry, did I get my point across, yet?), appears to contain a supertype template for BA artifacts that is common to all documents. IMO the attributes to the right of the artifact are listed upside down. By 'upside down', I mean that the most useful information is placed at the bottom and the stuff that nobody reads at the top. (In fact why would any technical document contain a section labeled 'Document History'? Who cares? I want to know what the state of the requirements are today, not what they were 6 months ago. If I want a history of the project to date, I suggest either creating a separate document that gives a complete overview of the project history, from day 1, tell the requestor to go look at our configuration management system where this information is maintained. But don't be looking in the requirements specifications for a history of the project.

Sorry, where was I - oh yes - generally the most useful information is found in the appendices. Next is the main content and other requirements. The rest is just standard template waffle thyat no-one is really interested in reading. That is except for the 1 paragraph on the 1st page of the document which states 'Who should be reading this document and why'. If my name ain't listed under this paragraph, guess what happens to the paper used to print this document on.

Hope this helps,

Anthony posted on Wednesday, September 26, 2012 11:24 PM
I like this, its very clear :)
marktylor posted on Sunday, March 22, 2015 12:09 AM
Thanks for sharing and letting us know about your value able experience regarding business analyst. It is such a great effort. Looks quite impressive to me as it has large amount of information for all the dedicated individuals who are looking to improve their business analyst techniques.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC