Top 10 Documents Created By Business Analyst

Are you assigned to a new project as a Business Analyst and you don’t know what documents you will be asked to prepare? Are you trying to switch your career as a business analyst and wondering the documents that you will be asked to prepare?

Don’t worry! This article is for you only. In this article, I will explain and give you an overview of common documents prepared by Business Analysts so that you can go ahead and explore more about it.

Below are the top 10 (but not limited to) documents created and managed by almost all the Business Analyst.

#1. Project Vision/Project Charter Document:

Project Vision or Project Charter is a very high-level document which describes the purpose of the project and what value it will add to the business i.e. business objective to be achieved by the project. Generally, it is prepared by the project manager but Business analyst needs to contribute to this document. Being a business analyst I’ve been asked many times to prepare Project charter.

Read about Project Charter Project Charter - All You Need To Know

#2. Requirement Management Plan/Project Plan:

This document is created at the planning phase of the project and it contains all the information about the project to manage the project from start to end. It’s a plan that outlines the elicitation, requirements analysis, and validation/verification efforts as well as clearly indicates who is responsible for what. This document is referred to Project Manager, Project Lead, Project Sponsor or any member who needs to be involved in the project life cycle. It describes the purpose of the project, key tasks with task owner, workflow activity, etc.

#3. Use Cases:

Use Case document is the key methodology used in system analysis to identify, define and organize system requirements. This also helps to identify the key stakeholders of the process. This is again a high-level document and it shows all end users and major processes and how they interact with each other. Learn more about Use Case in the article [Use Case] What? Why? and How? - All You Need To Know?

#4. Wireframes, Prototype, Mockup, and Other Visual Documentation:

Business Analyst often asked to create a prototype or mock-up screen to gather functional or business process requirements. It’s easy for stakeholders to view what they will be getting before approving it. Well-drawn mockup screens can save a lot of your time in the analysis phase. It's good to have some designer skills to be able to create this document smartly.

#5. User Stories In Agile Project:

In the agile development environment, User Stories are the functionalities written in the user’s point of view which business should provide.

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 (Main user story will act as a parent user story).

E.g. “System should not allow users to download anything without registration”

#6. Business Requirement Document - BRD:

Business Requirement Document act as a formal contract between the organization and the client. It describes the business problem and proposed a solution along with efforts required, risks involved, key stakeholders and other key details. It elaborates current state i.e. “As Is” and future state i.e. “To Be” to obtain everyone’s agreement before starting any project. This document is referred to throughout the project. This is created by Business Analyst with the help of Client, SMEs, Manager, and other Key Members.

Read the full article on How To Write Business Requirements Document

#7. Functional requirement specification (FRS):

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. Fictional requirement document or specification is written more technical than Business requirement document.

If BRD describes "what" needs to be some then FRD/FRS describes "how" it should be done. This document is referred to as the development and testing team as it has more insight into the system, input, output, processes, operations, system’s property, etc.

#8. Requirement Traceability Matrix - RTM:

The Requirement Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols.

It is maintained in the excel sheet by listing each requirement and corresponding test case numbers. Each organization has its own template for Requirement Traceability Matrix. This is used throughout the project life cycle to manage the agreed requirements.

#9. Test Cases:

Business analysts contribute in preparing test cases with Testers and sometimes they test the functional testing by referring the test cases. It’s important for a Business Analyst to have some basic idea of test cases i.e. how it’s prepared? What are the key elements? Etc.

#10. System Requirement Specification/Document (SRS/SRD):

If we go by the definition “A Software Requirements Specification (SRS) is a description of a software system to be developed. It lays out functional and non-functional requirements, and may include a set of use cases that describe user interactions that the software must provide.” This document elaborates the requirements from the perspective of observational behavior.


Above are the most common documents prepared and managed by Business Analysts, however, there could be some more documents you could be asked to prepare like Change Management document.


I hope you liked this article and found it useful. Don't forget to share your experience in the comment section of this article if you have ever been asked to work on any other document.