This article was published as a part of the Data Science Blogathon
Preparing documents is one of the most critical tasks that every responsible business analyst does. A Business Analyst not only documents the clients’ requirements but also happens to document the progress and every change that has occurred during the project lifecycle. It is vital to jot down the process flow and note these things for maintenance and future reference.
If you are new to this field or aspiring to become a successful business analyst, perhaps our guide about the critical and detailed documents prepared by business analysts will come in handy.
Without further ado, let’s dive right in and check what all documents prepared by business analysts are essential for becoming a successful BA.
Key Documents Needed to be Prepared by a Business Analyst:
In this list, we will be discussing the essential documents prepared by a BA right from the project initiation to project delivery to achieve the optimal business solution for the client:
- Project vision Document
- Business Analysis Plan
- Business Requirements Document
- Functional requirement specification (FRS)/ Functional Specification Document (FSD)
- System requirement specification (SRS)/ System Requirement Document (SRD)
- Requirement traceability matrix (RTM)
- Use Case Diagrams
- Wireframes, Mockups
- Change Request Document
Let’s discuss each of these vital documents in detail.
Project Vision Document
Even though the client or the project manager primarily creates the Project Vision Document, the role of the business analyst in developing this document is equally important. A project vision documents include the goal and the vision of the product to be developed and discusses what objective will be achieved through that particular product. It also consists of the following factors: benefits, risks involved, and options available before the project is initiated. These documents act as a formal agreement between the company and the business stakeholders.
A project vision document includes:
– Vision & Goal
– Description of users to be included in that particular project
– Stakeholders of the project
– Overview of Product to be developed
– Features of the product to be included while developing it
– Product requirements
– Constraints or Risks Involved
– Quality/documentation requirements
Business Analysis Plan
A Business Analysis Plan is primarily a formal document that describes the major activities that need to be carried out by a Business Analyst during the project lifecycle. A business analyst prepares this document during the planning phase of the project scope. The people involved in this phase are the project managers, product owners and the business managers whose support is needed to execute this plan.
The Business Analysis Plan involves the following steps:
- Purpose of the plan
- Roles & Responsibility Distribution
- Tools Required to Execute the Project Plan
- Process & Techniques implemented to define the project
- Workflow & Process Mapping
- Adaptability & Measures to Implement Changes if Required
Business Requirement Documents Plan
Image 1
A business requirement document or BRD is created to define the requirements of the particular product or software that the client needs the company to work upon and finally achieve the results as discussed in the meetings with the client. A BRD is one such document that everyone refers to throughout the project life cycle. This document helps them make the right choices for every phase without making a rookie mistake during the process.
A BRD focuses on what would be the intended business solution based on the problem statement as presented by the client. Hence, it is safe to say that the BRD mentions and gathers all the essential requirements as explained by the business stakeholder.
Along with the Business Analyst, the project manager, the scrum master, the client, the domain experts, the senior managers create the BRD to ensure that the business requirements are correctly understood and jotted down for reference purposes.
The Business Requirement Document normally contains:
– A little background of the Project
– Goals and objectives of the Business
– Stakeholders involved in the project
– Requirement scope
– Gathering the relevant Data for the project
– Interface requirements for the projects to function well
– Business glossary/ Jargons (if required)
Functional Requirement Specifications (FRS)
Image 2
So BRDs are prepared in such a way that anyone can refer to the document for easy reference. No technical jargon is used, and the business requirements are put down in layman’s terms to avoid confusion. However, a BRD is not the ideal document for the technical development team to understand the system thoroughly. Hence, a Functional Specification document is there to meet the requirements of the development team.
While a BRD discusses what needs to be done or achieved in a particular project, FRS focuses on how the team should complete the project & how should the system behave to find the best path to complete the project within the stipulated time. Functional Specification Document also defines the intended behavior of a system, including data, operations, input, output, and the properties of the system. FRD is more insightful and intended for the development and testing team to fulfill their job in a particular project.
System Requirement Document (SRD) /SRS
Image 3
An SRS or SRD describes the complete behavior of the system and how the entire system has to function after getting developed. This document contains all the functions as well as the non-functional requirements. The System requirement specification (SRS)/ System Requirement Document (SRD) contains:
– Use Cases
– Type of Software Requirements to build the project
– Database & Storage Requirements for the product to function seamlessly
– Product Functions to understand the UI/UX
– User Characteristics to understand the target users for the intended software
WireFrame, Prototype, And MOCK-UP
Image 4
It is essential to have a visual presentation of the company’s product that is about to be developed. This mockup, aka wireframe, eventually helps the client understand the future system, and as BA, it helps them know if the client agrees with their idea.
To visually present this blueprint, a business analyst prepares a wireframe design with the help of wireframe tools like JIRA. These diagrams can save plenty of time during the analysis phase as it aligns with the client’s requirements. The development team also takes reference from the wireframe design to build a practical design.
Use Case Diagram
Business Analysts must also prepare use case diagrams that help the team identify, organize and define the system requirements. Use cases illustrate a typical user’s interaction with the system developed by the team. It additionally helps in recording the scenarios where the user will be interacting with the system. It deals with user stories and many possibilities of how the interaction should be happening.
The development team refers to the use cases diagrams throughout the project lifecycle. The BA updates the use case diagrams when the team or the key stakeholders request any changes.
A normal Use Case diagram and a descriptive requirement document contain:
– Actors
– Description
– Trigger
– Preconditions
– Notes and Issues
These are some of the details that you will find in the use case diagram.
Requirement Traceability Matrix- RTM
An RTM, aka Requirement Traceability Matrix, is an important document prepared and managed by a business analyst. A Business Analyst uses RTM for mapping and tracking project requirements to the particular test cases and possible defects. RTM assures that all the functionality of the developed application is covered and tested as well.
An RTM is prepared in a tabular format in tools like excel, wherein the relationship between test scenarios and requirements gets established. RTM is also used to track any changes if implemented in the project.
The Business Requirement Document contains:
– Requirement Description
– Functional Requirement
– Technical Specification
– Software Module
– Tested In
Change Request Management
As a business analyst, you might come across many changes requested by the client or the development team during the project execution. The business owners might request some features to be added or deleted later on if they deem fit after certain speculations as per the market speculations. Any additional request that might delay or change the project’s course plan is considered a change request. Before implementing the change, the business analyst analyzes the timeline, the impact and then goes through the necessary approvals before adding them to the project.
Change Request Document is a great way to deal with scope creep, which occurs if the new proposed plan of action now differs from the initial purpose due to the addition or deletion of features. With regular meetings with the technical team and the client, it is then decided how the change request will be implemented and how the overall project plan will be affected.
Frequently Asked Questions
A. BRD stands for Business Requirements Document, while FRD stands for Functional Requirements Document.
A BRD captures the high-level business objectives, goals, and requirements of a project or system, focusing on the business perspective.
An FRD, on the other hand, details the specific functional requirements of a project or system, outlining how the system should behave, its features, and functionality from a technical perspective.
A. BRD stands for Business Requirements Document. A BRD is a formal document that outlines the objectives, goals, and requirements of a project from a business perspective. It serves as a communication tool between stakeholders, including business analysts, project managers, and clients, to ensure a common understanding of the desired outcomes and scope of the project. A BRD typically includes sections such as project overview, business objectives, functional requirements, non-functional requirements, constraints, assumptions, and acceptance criteria. It helps guide the development process, assists in decision-making, and serves as a reference for evaluating project success.
Conclusion
As a business analyst, it is essential to document all the critical information and share it with the relevant team to complete the project with the decided timeframe. Additionally, a business analyst conducts constant meetings with the development team and the business stakeholder to track the project’s progress, accept change requests, and coordinate with the technical team to complete the project as per the proposed project plan. Hence, these documents prepared by business analysts come in handy. Whether the BAs are using the waterfall model or preferring to work in an agile development environment, these detailed documents are essential to track project scope and meet the business objective. In the next article, I will be describing all the important business analysis documents in a detailed version.
Image Source-
- Image 1: example.com
- Image 2:
- Image 3: Freshcode
- Image 4 : pintrest
The media shown in this article on Interactive Dashboard using Bokeh are not owned by Analytics Vidhya and are used at the Author’s discretion.
