9 important Documents created by every Business Analyst

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

Business Analyst Documents

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 depends upon many parameters like organization’s processes and policies, need and expectations of the business, and the stakeholder requirements. Detailed below are the common 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 a part of the overall project documentation. The documents are:

  • 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 analyst 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 on a high level ‘what’ business objective will be achieved.

The Project vision document contains:
– 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 effectively manage project requirements from project initiation till delivery.
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:
– Purpose of plan
– Responsibility assignment
– Tools and procedures to be used
– Approach towards defining requirements
– Approach towards Requirements Traceability
– Workflows and Activities
– Change Management

 

3. Use cases
Each and every project is an endeavor to achieve ‘requirements’ and the document which 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:
– Actors
– Description
– Trigger
– Preconditions
– Normal Flow
– Alternative Flows
– Exceptions
– Special Requirements
– Assumptions
– Notes and Issues

 

4. User stories
In agile development environment, a user story is a document describing the functionality a business system should provide and are written from the perspective of an end user/customer/client. The user stories are not very descriptive and only captures ‘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 a number of user stories making it easier for estimation and discussion. In such cases, the main user story will act as 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 login credentials of the user and redirect him to the dashboard in case of 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 that is expected from the product/process. It is one of the most widely accepted project requirement document and is referred throughout the development life-cycle for any project.
A BRD mainly focusses on answering ‘what is the business solution’ as opposed to ‘how to achieve the business solution’ and thus it’s mainly centered around the business requirements. A BRD is created with the help of the project team (BA, client, subject matter exerts, business partners) and is also used as a communication tool for other stakeholders/external service providers.

The Business Requirement Document contains:
– 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 which lists the complete user and system requirements for the system (in form of use cases) which are in-turn mapped to the respective documents like Functional Requirement, Design Document, Software Module, Test Case Number, etc.
A 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:
– Requirement ID
– Requirement Description
– Functional Requirement
– Status
– Architectural/Design Document
– Technical Specification
– Software Module
– Test Case Number
– Tested In

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 a FRS/FSD they are written in much more details 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:
– 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. This document elaborates 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:
– 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 but 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, which 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 which should be referred 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

All the above documents are created by a business analyst and are part of the project/product documentation. These documents are constantly referred through the project’s life-cycle for communication, reference and revision.

 

Get BA Documents Template Toolkit for FREE !!

Get the Business Analyst Documents Template Toolkit containing elaborated templates for the commonly used requirements documents like Business Requirement Document (BRD), Use Case Document, Requirement Traceability Matrix (RTM) and many others absolutely Free.

Just enter your details in the form below and have them delivered to your Inbox !Business Analyst Documents Template

 

 

 

 

 

  • Vijay Krishna Tilak

    Error Sending Message New subscriber to BA Template Toolkit to magu_boy007@yahoo.com | Failed to connect to api.sendgrid.com port 443: Connection timed out

    I tried to send the toolkit to my email and it shows this error !

  • I’m also having issues receiving the Template Toolkit

  • Olga Baran

    Hi. I occured the same problem. Error Sending Message New subscriber to BA Template Toolkit to magu_boy007@yahoo.com | Failed to connect to api.sendgrid.com port 443: Connection timed out

  • Tony

    Has anyone been able to download the kit? I got the same error as the folks below. This site looks legitimate, so I really hope this isn’t an email farming scheme.

  • Paris Inman

    Never got an email on this end. Checked junked mail

  • Paris Inman

    I don’t think it works at all and likely was a scheme for just emails. SMH

  • Shereen Samuel

    Hello there,
    Thanks for the good link and the valuable set of documents – I happened to see your website today while searching something related to Business Analysis. As you rightly mentioned that the set of document a Business Analyst need to work on/be exposed to would differ based on the company structure you work with. I have worked with Service companies and directly with established European Banks and I must say the way my work differed a lot when I try to compare between them. Former hardly focused on documents and wanted the end product more, hence the template or documents just a little. On the other hand in the Bank we had documents for each and every step starting from project initiation phase till hand over to the implementation team. Quality in terms of each work product – whether its document or code mattered a lot here.
    My understanding from the past 7 years of experience is(could be very well wrong ) that the names and templates of the document are not of much importance because in one place it would be called as Project Vision document, on the other hand it might be known as Project Plan proposal/Project Charter etc where almost the same contents as you mentioned would be included like what is the project intended to do, the benefits, some number to prove that the project makes sense to be rolled out etc, stakeholders, requirements etc.
    Hmm. So what am I trying to say – so people who are trying to crack interview in becoming a BA would be that you need not by heart the document names and templates but an overall awareness of the situation is certainly required. Because I believe that one of the major talent that a Business Analyst should have is to be adaptable and navigate along with the tide. But that doesn’t mean that if the place you end up has zero process you have to be like, in fact there you can prove yourself in bringing in these documents one by one and channeling your project into a good shape. So in one place you might need to follow documents structure and other place it can be that they have the Atlassian tools and it would be totally up to you on how you document and consolidate your requirements. JIRA/Confluence is getting very popular right now and they provide certain standard template for User stores and other Product requirements but you will have to assess the need of the time and improvise. After all a BA should be AGILE 🙂

  • Sajal Gupta

    very good material ……..