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 prepare, depends 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 Agile methodology will have considerably less number of documents as compared to 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 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 for 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) described from the customer 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 of screen designs, business rules, data model etc.
A sub-set of SRS document capturing the process models or functional maps of the proposed system.
Gap Analysis Document
A document prepared in a 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 Gap analysis document.
Requirements Traceability Table (RTT)
A comprehensive matrix to capture 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 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 our system testing for a project with testing strategy, cases coverage, test data preparation strategy etc.
System test cases
The test cases with test data based on the system test plan.
UAT progress report
Business analysts co-ordinate the user acceptance testing phase and during the UAT phase, they submit the status report to all the stakeholders.
Documents created in Agile Projects
Number of documents created in Agile projects is limited as mentioned above. The brief description of these documents is below:
NOTE: Some of the documents mentioned above may also be created on as-needed basis.
User Story Cards
A format which 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 I
A sub-set 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.
Read Also: When burn down charts fail?
Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.