Business Analysis Documents Description - Vgood

7/29/2019 Business Analysis Documents Description - Vgood

1/7

Business analysis documents: Current State Analysis

This article is the first in a series describing business analysis artifacts, theirpurpose and internal structure.

I'll talk about these documents: 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

Once Ive described those, Ill go on to show the relationships between the artifacts.

The picture below illustrates the information common to every artifact. The areaindicated by the "Main content" arrow should be filled by the appropriate document-specific content discussed throughout this series of articles:

Current state analysisOnce a project has been mandated and the Project Initiation document (PID) isdrafted, 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. Ithelps understand the business need, primary pain points, business processesaffected, the stakeholders involved in these processes, and so on.
http://3.bp.blogspot.com/_szNiuiRMhCQ/TQmn-r8lDpI/AAAAAAAAACY/tUQwRtnbUks/s1600/artifact+structure.png


2/7

The area of the current state analysis is illustrated below:

The main purpose of the analysis is to present the AS IS state: the existingbusiness context, background, business functions and existing business processes,

and finally stakeholders involved in these business processes. Depending on theproject nature, some components of the underlying infrastructure can be included inthe document as well.

A Current State Analysis document lists the key pain points within the identifiedbusiness processes and tasks within them, and highlights the areas where a changeis expected.

The last section of the document is about presenting recommendations. It recapsthe key findings and lists the key changes expected. Any caveats should bepresented here as well.

The content structure of the Current State Analysis document is presented below:

This artifact serves as a foundation or a reference point for other artifacts producedby a business analyst. The other documents will be discussed in the following

articles.

Business analysis documents: Project Vision and Solution VisionProject vision

The Project Vision is a document which is shared by a project manager and businessanalyst. They work together to outline the problem statement, determine thedesired state, describe the criteria of business acceptance of the deliverables and
http://3.bp.blogspot.com/_szNiuiRMhCQ/TQmo219rd2I/AAAAAAAAACg/-6RLiTV1h7E/s1600/current+state+analysis+structure.pnghttp://4.bp.blogspot.com/_szNiuiRMhCQ/TQmoj5JMUZI/AAAAAAAAACc/SMyMVjJE4Xw/s1600/current+state+analysis+area.png


3/7

how project success will be measured. The document contains a section withstakeholder analysis which shows all the parties involved along with theirresponsibilities and needs:

The business analyst adds the high level requirements which are within the scope ofthe project, and marks each requirement as compulsory or optional. To clearlydefine the project scope and avoid ambiguity, all out-of-scope requirements are alsolisted at the end of the section.

Based on the results of the current state analysis (discussed in the previous post),the business analyst describes the current business context, the key businessprocesses and services used to support them. After that the required changes aremapped to the current business context. It can be a good idea to present thismapping as a diagram for easy communication of the proposed changes to thebusiness stakeholders.

Solution vision

Once the Project Vision document is approved, the preparation of the SolutionVision document starts.

First, the business analyst recaps the problem statement from the Project Visionartifact. The solution statement describes the target audience of the solution, whatwill 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 aconclusive point in positioning of the solution.

The document describes stakeholders within the target audience along with theirroles using a RACI matrix.

The main part of a Solution Vision is a detailed section devoted to the solutioncapabilities comprised of both functional and non-functional features, with prioritiesgiven by the business stakeholders.
http://blog.aoteastudios.com/2010/12/business-analysis-documents-current.htmlhttp://en.wikipedia.org/wiki/RACI_matrix#RACI_.28alternative_scheme.29http://en.wikipedia.org/wiki/RACI_matrix#RACI_.28alternative_scheme.29http://blog.aoteastudios.com/2010/12/business-analysis-documents-current.html


4/7

The next section presents the business context in its future "to be" state. It's a goodidea to include a a diagram illustrating the key changes and additions to theexisting 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 listed in the last section to make sure everyone is on the same page withregards to what will be implemented.

Business analysis documents: Business Requirementsand Use Cases

This is part 3 of a series of posts on business analysis documents (check outpart 1andpart 2if you haven't seenthem). If you find this post or the series useful, please let your colleagues know!

Business Requirements

The document focuses on providing details about the current processes and gives enough information to describe thebusiness 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. Businessrules that apply to the described requirements are presented in a separate section. This approach simplifies theconfirmation of the rules with business stakeholders.

Any assumptions and dependencies identified in relation to the business requirements are to be listed in theappropriate section.

The proposed changes to stakeholder roles, new or modified business processes and business services that supportthem are presented in the last section.

Use Case Model

Use Case Model lists all the scenarios for using the solution required by the business stakeholders. It is useful todescribe the solution as a set of functional areas and group the scenarios per functional area. Such an approachallows to use this document more efficiently in communication with the business stakeholders as they can easily referto the sections of their interest.

The model lists all possible scenarios in scope, their brief summary, actors involved in each scenario, frequency ofuse, triggering events and the two possible outcomes success and failure.
http://blog.aoteastudios.com/2010/12/business-analysis-documents-current.htmlhttp://blog.aoteastudios.com/2010/12/business-analysis-documents-current.htmlhttp://blog.aoteastudios.com/2010/12/business-analysis-documents-current.htmlhttp://blog.aoteastudios.com/2010/12/business-analysis-documents-project.htmlhttp://blog.aoteastudios.com/2010/12/business-analysis-documents-project.htmlhttp://blog.aoteastudios.com/2010/12/business-analysis-documents-project.htmlhttp://blog.aoteastudios.com/2010/12/business-analysis-documents-current.htmlhttp://blog.aoteastudios.com/2010/12/business-analysis-documents-project.html


5/7

One of the key attributes of the scenarios is a reference to the high-level requirements and required capabilities whichallows to establish traceability.

Note: when making changes to Use Case Specifications, do not forget to update the Use Case Model documentaccordingly.

Use Case SpecificationA Use Case Specification document presents more detailed information about the use cases in the Use Case Modeldocument.

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

Business analysis documents: Business Process Design,System-Wide Requirements, Solution GlossaryThis is the final article in the series on the structure of business analysis documents.

If you are interested in a diagram that brings together everything we talked about in this series, you can find it in ourguide to business analysis, BA Kickstart, or in theBA Illustrated poster pack. The diagram shows documentstructures, the relationships between the documents, and how the documents feed into project management, changemanagement and SDLC. Of course, there's lots of other useful knowledge in our products besides this.

Let's get on with the structure of the rest of the documents, however.

Business process design

This document focuses on the scope of changes to business processes, providing details about the currentbusiness context, existing business processes, and stakeholders involved in these business processes.
http://blog.aoteastudios.com/2011/01/business-analysis-documents-business.htmlhttp://blog.aoteastudios.com/2011/01/business-analysis-documents-business.htmlhttp://aoteastudios.com/products/kickstarthttp://aoteastudios.com/products/postershttp://aoteastudios.com/products/postershttp://blog.aoteastudios.com/2011/01/business-analysis-documents-business.htmlhttp://blog.aoteastudios.com/2011/01/business-analysis-documents-business.htmlhttp://aoteastudios.com/products/kickstarthttp://aoteastudios.com/products/posters


6/7

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 tostakeholders 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 inthe appropriate section.

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 thesolution.

The Load patterns section is the most interesting as it illustrates how the solution is expected to be usedduring 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 solutionresilience. 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 thesolution into the existing business environment. The system-wide requirements document describes theinterfaces with internal and external systems and solutions, the data flowing between them, its formats anddata elements. Where the solution should interface with external systems, samples of data must bepresented in appendices.

Apart from business reporting capabilities, the solution must provide reporting capabilities for monitoring howthe 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 thisterminology (you can be quite new to it), the Solution Glossary document is used. It helps establish commonterminology for the project team and key stakeholders, and for use within the solution. The structure of thisdocument is simple:


7/7

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 pointfor all the previously discussed documents.

Business Analysis Documents Description - Vgood

Documents

Transcript of Business Analysis Documents Description - Vgood