Below are top 10 (but not limited to) documents created and managed by almost all the Business Analyst.
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 in this document. Being a business analyst I’ve been asked many times to prepare Project charter.
This document is created at 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 project life cycle. It describes the purpose of the project, key tasks with task owner, workflow activity etc.
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 high-level document and it shows all end users and major processes and how they interact with each other.
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. A 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.
In the agile development environment, User Stories are the functionalities written in 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”
Business Requirement Document act as a formal contract between organization and 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 throughout the project. This is created by Business Analyst with the help of Client, SMEs, Manager and other Key Members.
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 development and testing team as it has more insight of the system, input, output, processes, operations, system’s property etc.
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 excel sheet by listing each requirement and corresponding test case numbers. Each organization has their own template for Requirement Traceability Matrix. This is used throughout the project life cycle to manage the agreed requirements.
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.
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.