9 Important Documents Created by Every Business Analyst

Documentation is one of the integral job functions of business analysts, and they, throughout the course of a project, prepare many documents. These documents are created to fulfill the varied project needs and cater to audiences belonging to different spheres of a project.

PSST… Don’t forget to download your FREE Business Analyst Documents Template Toolkit at the end of this article !!

The type and specifications a business analyst is expected to create in an organization depend upon many parameters, like the organization’s processes and policies, the needs and expectations of the business, and the stakeholder requirements.
Detailed below are the typical documents a business analyst is expected to create, and they are extensively used throughout the course of a project. Each of these documents has a specific template, and it’s part of the overall project documentation.
Here are the key documents prepared by Business Analyst (BA):

• Project Vision Document
• Requirement Management Plan
• User Stories
• Use Cases
• Business Requirement Document
• Requirement Traceability Matrix (RTM)
• Functional Requirement Specification (FRS)/ Functional Specification Document (FSD)
• System Requirement Specification (SRS)/ System Requirement Document (SRD)
• Test Case

Let’s discuss each of these documents in detail.

1. Project Vision Document

Although mainly the client/project manager creates a project vision document, business analysts are also expected to contribute to this document. A Project vision document entails the purpose and intent of the product/software to be developed and describes the ‘what’ business objective will be achieved on a high level.

The Project vision document contains the following sections:
– Introduction
– Description of users in the system
– Project stakeholders
– Product Overview
– Product Features
– Product requirements
– Constraints/Limitations
– Quality/documentation requirements

2. Requirement Management Plan

The Requirements Management plan is used to document the necessary information required to manage project requirements from project initiation to delivery effectively.

The Requirements Management Plan is created during the Planning Phase of the project. Its intended audience is the project manager, project team, project sponsor, and any senior leaders whose support is needed to carry out the plan.

The Requirement Management Plan contains the following sections:
– Purpose of the plan
– Responsibility assignment
– Tools and procedures to be used
– Approach to defining requirements
– Approach toward Requirements Traceability
– Workflows and Activities
– Change Management

3. Use cases

Each project is an endeavor to achieve ‘requirements,’ and the document that defines these requirements is a use case. A use case is a methodology used in system analysis to identify, define, and organize system requirements.

A use case is created from the perspective of a user and achieves the following objectives:
1. Organizes the functional requirements,
2. Iterative in nature and updated throughout the project life-cycle
3. Records scenarios in which a user will interact with the system
4. Defines other aspects like negative flows, UI elements, exceptions, etc.

The Use Case document contains the following:
– Actors
– Description
– Trigger
– Preconditions
– Normal Flow
– Alternative Flows
– Exceptions
– Special Requirements
– Assumptions
– Notes and Issues

4. User stories

In an agile development environment, a user story describes the functionality a business system should provide. It is written from the perspective of an end-user/customer/client.

The user stories are not very descriptive and only capture the ‘who’, ‘what’, and ‘why’ of a requirement in limited detail. If any requirement is too big for a single-user story, it’s broken down into several user stories making it easier for estimation and discussion. In such cases, the primary user story will be an Epic (parent) user story.

Some examples of user stories are:
– The system shall be able to sort the values in ascending and descending order
– The application must allow the user to enter his name, date of birth, and address.
– The system shall verify the user’s login credentials and redirect him to the dashboard in case of a successful login.

5. Business Requirement Document

A Business Requirement Document is created to describe the business requirements of a product/process and the intended end result expected from the product/process. It is one of the most widely accepted project requirement documents and is referred to throughout the development life cycle for any project.

A BRD mainly focuses on answering ‘what is the business solution’ as opposed to ‘how to achieve the business solution,’ and thus, it’s primarily centered around the business requirements.

A BRD is created with the help of the project team (BA, client, subject matter experts, and business partners). It is also a communication tool for other stakeholders/external service providers.

The Business Requirement Document contains the following sections:
– Project Background
– Business goals and objectives
– Stakeholders
– Requirement scope
– Functional requirements
– Data requirements
– Non-functional requirements
– Interface requirements
– Business glossary/Definitions
– Dependencies of existing systems
– Assumptions

6. Requirement traceability matrix (RTM)

A Requirement traceability matrix is used to record and track the relationship of the project requirements to the design, documentation, development, testing, and release of the project/product. This is done by maintaining an Excel sheet that lists the complete user and system requirements for the system (in the form of use cases), which are mapped to the respective documents like Functional Requirement #, Design Document, Software Module, Test Case Number, etc.

An RTM is maintained throughout the lifecycle of the various releases in a project, and it’s a vital document to track project scope, requirements, and changes in any project.

The Business Requirement Document contains the following:
– Requirement ID
– Requirement Description
– Functional Requirement
– Status
– Architectural/Design Document
– Technical Specification
– Software Module
– Test Case Number
– Tested In

Also View: 60+ Business Analyst Interview Question and Answers – Download FREE PDF

7. Functional requirement specification (FRS)/ Functional Specification Document (FSD)

A Functional requirement specification or Functional Specification Document describes the intended behavior of a system, including data, operations, input, output, and the properties of the system.

In a BRD, the requirements are high-level, but in an FRS/FSD, they are written in much more detail to capture each and every aspect of a requirement. Thus a functional specification document becomes a more technical, accurate, and descriptive requirement document.

Owing to their technical nature, FRS/FSD are equally used by developers, testers, and the business stakeholders of a project.

The Functional requirement specification (FRS)/Functional Specification Document (FSD) contains the following:
– Product Context
– Assumptions
– Constraints
– Dependencies
– Functional Requirements
– User Interface Requirements
– Usability
– Performance
– Manageability/Maintainability
– System Interface/Integration
– Security
– Requirements Confirmation/sign-off

8. System requirement specification (SRS)/ System Requirement Document (SRD)

A detailed document containing information about ‘how’ the complete system has to function and enumerates hardware, software, functional and behavioral requirements of the system.

SRS/BRD elaborates on the requirements from the perspective of observational behavior only and doesn’t consider technical or design bias.

The System requirement specification (SRS)/ System Requirement Document (SRD) contains the following:
– Product Perspective
– Product Functions
– User Characteristics
– General Constraints
– Assumptions and Dependencies
– External Interface Requirements
– Functional Requirements
– Classes / Objects
– Non-Functional Requirements
– Inverse Requirements
– Design Constraints
– Sequence Diagrams
– Data Flow Diagrams (DFD)
– State-Transition Diagrams (STD)
– Change Management Process

9. Test case

Although Business analysts are not explicitly asked to create test cases, they must understand what they constitute and how to create one, as they sometimes have to test functionalities by referring to the test cases.

A test case is a document that has a set of test data, preconditions, variables, and expected results created to verify and validate whether a particular piece of functionality is behaving as intended (or as documented in the requirement documentation). Thus, a test case becomes a standardized document that should be referred to every time a requirement has to undergo testing.

The components of a test case are:
– Test Case ID
– Test Scenario
– Prerequisite
– Test Data
– Test Steps
– Expected Results
– Actual Result
– Status
– Remarks
– Test Environment

A business analyst creates all the above documents, which are part of the project/product documentation. These documents are constantly referred to throughout the project’s life cycle for communication, reference, and revision.

Download BA Documents Template Toolkit (for Free)!!

Our free Template Toolkit contains the following pre-formatted and professional Business Analyst Document templates:

• Use Case Document Template
• Requirement Traceability Matrix (RTM) Template
• Requirement Management Plan Template
• Project Vision Document Template
• Test Case Template