Вы находитесь на странице: 1из 6

The structure of business analysis documents | BRILLIANT IDEA's ... http://nichiera.blogspot.com/2012/04/structure-of-business-analysis.

html

The structure of business analysis


19th April 2012
documents
Author: Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of visual
learning and reference materials for business analysts. [http://www.modernanalyst.com
/DesktopModules/DnnForge%20-%20NewsArticles/Print.aspx?tabid=115&tabmoduleid=3372&articleId=1713&
moduleId=572&PortalID=0]

Company 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 [http://aoteastudios.com/]

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:

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:

1 of 6 10/12/2018, 4:32 PM
The structure of business analysis documents | BRILLIANT IDEA's ... http://nichiera.blogspot.com/2012/04/structure-of-business-analysis.html

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.

2 of 6 10/12/2018, 4:32 PM
The structure of business analysis documents | BRILLIANT IDEA's ... http://nichiera.blogspot.com/2012/04/structure-of-business-analysis.html

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.

3 of 6 10/12/2018, 4:32 PM
The structure of business analysis documents | BRILLIANT IDEA's ... http://nichiera.blogspot.com/2012/04/structure-of-business-analysis.html

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:

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.

4 of 6 10/12/2018, 4:32 PM
The structure of business analysis documents | BRILLIANT IDEA's ... http://nichiera.blogspot.com/2012/04/structure-of-business-analysis.html

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.

Posted 19th April 2012 by GIORGI LOBJANIDZE

View comments

5 of 6 10/12/2018, 4:32 PM
The structure of business analysis documents | BRILLIANT IDEA's ... http://nichiera.blogspot.com/2012/04/structure-of-business-analysis.html

6 of 6 10/12/2018, 4:32 PM

Вам также может понравиться