In this blog, we are going to examine – Which are the Documents Prepared by a Business Analyst? Business analysts may prepare or be part of several documents in a project life cycle.
The documents, which a business analyst prepares, depend on the business analysis approach, complexity and size of the project and organizational standards. For example, the number of documents created for a project using the Agile Methodology will have considerably less number of documents as compared to the Waterfall Methodology.
So,Which are the Documents Prepared by a Business Analyst in Different Methodologies?
There are a number of documents, which can be created by a business analyst. Here is a comprehensive list of such documents(please note that a business analyst may not create all the documents in every project):
- Business Case
- Business Analysis Plan
- Business Requirements Document (BRD)
- Stakeholder Management Plan
- System Requirements Specification Document (SRS)
- Functional/Process Document
- Gap Analysis Document
- Solution Approach Document
- Requirements Traceability Table (RTT)
- Change Request Logs
- Impact Analysis Document
- System Test Plan
- System Test Cases
- UAT Progress Report
It is pertinent to list down the documents prepared by a business analyst (I am also including the Product Owner) in projects following Agile Methodologies separately:
- User Story Cards
- Product Backlog
- Sprint Backlog
- Burn down and Burn up Charts
A brief description for each of these is provided below:
A document describing solution options, their comparisons, and recommended solution based on parameters relevant to the organization.
Business Analysis Plan
A plan listing all the business analysis activities, to be carried out in the project. Generally, it is part of the project plan.
Business Requirements Document
Requirements for the project (Change initiative) are described from the customer’s perspective.
Stakeholder Management Plan
Business analysts create this document to document the strategy to handle stakeholders based on the stakeholder maps.
System Requirements Specification (SRS) Document
A details description of functional and non-functional requirements comprising screen designs, business rules, data models, etc.
A sub-set of SRS documents capturing the process models or functional maps of the proposed system.
Gap Analysis Document
A document prepared in commercial off-the-shelf (COTS) product implementation projects. This document describes the gaps between the process TO-BE implemented vs the AS-IS processes.
Solution Approach Document
Again, a document more relevant for a commercial off-the-shelf (COTS) product implementation projects. It describes the solution approach to address the gaps identified in the Gap analysis document.
Requirements Traceability Table (RTT)
A comprehensive matrix to capture the relationship and attributes of requirements for impact analysis (in case of change requests).
Change Request Logs
A log of all the change requests in the project with the date of request, requester, etc.
Impact Analysis Document
A document capturing all the details of a change including the value, its impact, cost, effort, approval status, etc.
System Test Plan
A plan for carrying out our system testing for a project with testing strategy, case coverage, test data preparation strategy, etc.
System Test Cases
The test cases with test data are based on the system test plan.
UAT Progress Report
Business analysts coordinate the user acceptance testing phase and during the UAT phase, they submit the status report to all the stakeholders.
Documents Created in Agile Projects
The number of documents created in Agile projects is limited as mentioned above. A brief description of these documents is below:
NOTE: Some of the documents mentioned above may also be created on an as-needed basis.
User Story Cards
A format that captures the user story, details based on conversation and the acceptance test cases. Think of it like a postcard with sides. The front side contains the user story and its details. The back side contains the acceptance test cases.
A listing of to-be-done requirements (captured as user stories or any other format) with priority and estimation. It is maintained on the product level and not all requirements are detailed out in the phase.
You can also check out Product Backlog Mistakes To Avoid
A subset of product backlog to-do items, which is to be taken up for development in a particular sprint. These are fully detailed out. A sprint backlog may contain:
- Changes etc.
Burn Down and Burn Up Charts
Charts to track the status of the requirements. These charts can be made for a sprint as well as for the entire product.
I have tried to cover most of the documents created by Business Analysts, however, if I have missed something, do let me know.
Techcanvass offers IT certification courses for professionals. We are an IIBA Endorsed Education Provider (EEP) & iSQI ATP (for Certified Agile Business Analyst Training).
Our ECBA Certification training not only prepares you to become a business analyst but also prepares you for the IIBA ECBA Certification.