Key Documentation Prepared by Business Analysts
Documentation is the core part of the business analysis process that provides clarity, standards, and process details that help organizations in decision-making. The documentation provides information about the guidelines, requirements specifications, roadmaps, communications, blueprints, and solutions that are crucial for the execution of the project.
Business analysts create various documents to translate complex requirements into accessible language that can be understood both by the technical and non-technical staff of the team. Business analysts bridge the gap between the business stakeholders and the technical team by creating various documentation that provides clear, concise information on the problem statement, business objectives, key requirements, restrictions, exclusions, and solutions that help in the alignment of the team.
A well-crafted document by the business analyst helps the organization secure the budget required for the execution of the project and forecast any risks during the implementation of the project. Documentation also helps to align the project with the overall organization goal and describes the value added to the organization goal by the execution of the project.
Key Documentation Prepared by The Business Analyst
- Business Requirements Document (BRD):
The business requirements document is one of the most common documents that is prepared by a business analyst. BRD captures the big picture of the project and stakeholders’ business needs. It provides detailed information on the project goals, objectives, and approved solutions, along with the key deliverables that define the scope and associated benefits of the project’s execution.
Although the fields in the BRD change from organization to organization, here are the key fields in the BRD document:
- Project details
The project details section includes information such as project name, project number (if applicable), organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.
- Project Overview
The project overview provides high-level project objectives and their benefits. This is the section one would read to get the complete summary of the project.
- Project scope and out-of-scope items
The project scope lists the deliverables of the project; this helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.
Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.
- Assumptions
The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.
- Current and future state business processes
The current state of the of the business process depicts a snapshot of the current state of the organization, and the future state highlights the deliverables of the project.
This section helps to have a side-by-side comparison of the enhanced functionality that will be achieved by the project.
- Business requirement
The business requirement is the main section of the BRD. This section lists all the action items that are required to achieve the project scope.
Along with the action items, it is important to assign priority to each item, as it helps the technical team identify which task they need to pick first.
For projects where the implementation of the business requirements is divided into multiple releases, it is important to include release details in the business requirements section.
- Business rules
The business rules section consists of all the project-relevant business rules that were agreed upon and approved by the stakeholders. Business rules usually trace back to business requirements.
- Project risks
The project risks section includes all the risks identified and mitigation measures for the risks. Identifying the risks ahead helps the team focus on their tasks and reduces uncertainty during the execution of the project. Identifying risks earlier also helps to make better business decisions.
- Cost-benefit analysis
Cost-benefit analysis is the last section of the BRD. In this section, you describe how the project objectives will make a profit for the organization and estimate the ROI that can be achieved with the execution of the project.
Advertisement
- Functional Requirements Document (FRD):
The Functional Requirements document provides information about the business problem and approved solutions for the problem. FRD is the contract between the business and the technical team to deliver the accepted solution. It provides information about key functionality that a solution system needs to have and the performance of the system. FRD captures all the nitty-gritty information about the solution product.
The FRD document is different from the BRD , as FRD focuses more on the nitty-gritty details of the solution and BRD focuses on the broader view of the overall project.
The style and fields of the FRD document change from project to project. Here are the key fields of the FRD document:
- Project details
The Project Details section includes detailed information about the project, such as project name, project unique number, organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.
- Project Description
An overview of the project, its benefits, and the approved solution. This is the section one would read to get a complete overview of the project.
- Project Background
The project background describes the problem statement of the project and the purpose of the project.
- Project scope and out-of-scope items
The project scope lists all the deliverables of the project, including the technical details of the solution system. This section helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.
Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.
- Assumptions
The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.
- Functional requirements
The functional requirements section describes what the system must do. Functional requirements must be drafted in a way that provides complete information about the business needs and specifications needed in the solution system.
- Operational requirements
The operation requirements section describes how the system must operate, i.e., how fast the system should respond, how many responses the system needs to provide in the given time, etc.
- Requirement Traceability Matrix
The requirement traceability matrix is described in detail in the section below.
The requirement traceability matrix is used to track the implementation of the functional requirements. The RTM is updated throughout the project to show the progress made in the implementation of the functional requirements.
- Glossary
List all the business terms and their definitions.
- Non-Functional Requirements Document
The non-functional requirements document defines how the system must behave. This section is crucial for the execution of the project; it describes the capabilities of the system operation and its constraints. Non-functional requirements provide information about system users, scalability, operation, hardware and software, performance, retention and capacity, accessibility, and security.
The solution system can still operate by just executing the functional requirements, but it might not meet all the business expectations in terms of security, performance, scalability, etc.
Below are the fields that are going to be part of the Non-Functional Requirements document:
- Security
Security is the most important section of the non-functional requirements document. This section captures all the security guidance that needs to be incorporated by the project execution team during the implementation of the project. It captures security architecture guidance, authentication, data security, risk management, and technology development guidance.
- Users
This section provides information about the business expectations for the number of users that will use the system. And a number of concurrent users that the system can support without letting the system performance degrade.
- Scalability
This section captures business expectations for the data volume that the system must support. It also captures the volume that the system can support during peak and non-peak times.
- Operational
The operational section is different from organization to organization; this is the section that captures the Tier 1, Tier 2, Tier 3… (Severity 1, Severity 2, Severity 3…) incidents that arise and the action plan to resolve the incidents. Based on the severity of the incident, a recovery strategy is defined to get the system back up and running.
- Hardware and software
This section includes information about any new hardware components required for the execution of the project and the specifications of the hardware components.
It also captures any new software installation or software configuration required for the completion of the project.
- Performance
The performance section answers questions such as how fast the system needs to perform. What should be the response time of the system?
- Retention and capacity
The retention and capacity section captures data types that need to be stored in the database and the data retention time frame required for the data. It also talks about the capacity of the database and the various logs that will be available.
- Accessibility
This section captures information about who can access the system and the minimum requirements for accessing it.
- Requirement Traceability Matrix
The Requirement Traceability Matrix is the document used during the implementation of the project to trace the requirements to its test cases and further to any defects. The main purpose of this document is to prove that all the requirements have been successfully executed and tested by the project execution team.
The requirement The traceability matrix generally consists of the following fields:
- Requirement Number
The requirement number is the business requirement or the functional requirement number that is captured in either the BRD or FRD document based on organization standards. All the requirements for the project are listed in this column.
- Requirement description
A brief description of the requirement.
- Test case number
The test case number is the unique number used to identify the test case for a particular requirement.
- Testcase description
A brief description of the test case and its scenarios.
- Test execution result
This section captures if the test case was a ‘Pass’ or Fail’ during the execution of the test case.
- Defect number
If the test case execution fails, then a corresponding defect is created, and this section captures the defect’s unique number.
- Defect Status
This section is used to capture defect status such as ‘Open’ or ‘Complete’. This helps to know if the defect was successfully fixed and tested.
Conclusion
Throughout this paper, we have discussed various documents prepared by a business analyst that play a crucial role in the project’s success, driving communication and streamlining the process. From the initiation of the project to the implementation and final deployment of the product, these key documents guide the team through the project lifecycle and ensure the team is aligned with business objectives at every step of the project.