9 Important Documents created by every Business Analyst (Part 2)
Documentation is one of the integral job functions of a business analyst and he, throughout the course of a project, prepares many documents. These documents are created to fulfill the varied project needs and cater to audiences belonging to different spheres of a project.
The type and specifications a business analyst is expected to create in an organization depends upon many parameters like organization’s processes and policies, need and expectations of the business, and the stakeholder requirements. Detailed below are the common documents a business analyst is expected to create and they are extensively used throughout the course of a project. Each of these documents has a specific template and it’s a part of the overall project documentation. The documents are:
Project vision Document
Requirement Management Plan
User stories
Use cases
Business Requirement Document
Requirement traceability matrix (RTM)
Functional requirement specification (FRS)/ Functional Specification Document (FSD)
System requirement specification (SRS)/ System Requirement Document (SRD)
Test case
Let’s discuss the second part of these documents in details, as we discussed 4 of these important documents last week.
5. Business Requirement Document
A Business Requirement Document is created to describe the business requirements of a product/process and the intended end result that is expected from the product/process. It is one of the most widely accepted project requirement document and is referred to throughout the development life-cycle for any project.
A BRD mainly focusses on answering ‘what is the business solution’ as opposed to ‘how to achieve the business solution’ and thus it’s mainly centered around the business requirements. A BRD is created with the help of the project team (BA, client, subject matter experts, business partners) and is also used as a communication tool for other stakeholders/external service providers.
The Business Requirement Document contains:
– Project Background
– Business goals and objectives
– Stakeholders
– Requirement scope
– Functional requirements
– Data requirements
– Non-functional requirements
– Interface requirements
– Business glossary/Definitions
– Dependencies of existing systems
– Assumptions
6. Requirement traceability matrix (RTM)
A Requirement traceability matrix is used to record and track the relationship of the project requirements to the design, documentation, development, testing and release of the project/product. This is done by maintaining an excel sheet which lists the complete user and system requirements for the system (in form of use cases) which are in turn mapped to the respective documents like Functional Requirement, Design Document, Software Module, Test Case Number, etc.
An RTM is maintained throughout the lifecycle of the various releases in a project and it’s a vital document to track project scope, requirements and changes in any project.
The Business Requirement Document contains:
– Requirement ID
– Requirement Description
– Functional Requirement
– Status
– Architectural/Design Document
– Technical Specification
– Software Module
– Test Case Number
– Tested In
7. Functional requirement specification (FRS)/ Functional Specification Document (FSD)
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.
In a BRD the requirements are high level but in an FRS/FSD, they are written in much more details to capture each and every aspect of a requirement. Thus a functional specification document becomes a more technical, accurate and descriptive requirement document. Owing to their technical nature, FRS/FSD are equally used by developers, testers and the business stakeholders of a project.
The Functional requirement specification (FRS)/Functional Specification Document (FSD) contains:
– Product Context
– Assumptions
– Constraints
– Dependencies
– Functional Requirements
– User Interface Requirements
– Usability
– Performance
– Manageability/Maintainability
– System Interface/Integration
– Security
– Requirements Confirmation/sign-off
8. System requirement specification (SRS)/ System Requirement Document (SRD)
A detailed document containing information about ‘how’ the complete system has to function and enumerates hardware, software, functional and behavioral requirements of the system. This document elaborates the requirements from the perspective of observational behavior only and doesn’t consider technical or design bias.
The System requirement specification (SRS)/ System Requirement Document (SRD) contains:
– Product Perspective
– Product Functions
– User Characteristics
– General Constraints
– Assumptions and Dependencies
– External Interface Requirements
– Functional Requirements
– Classes / Objects
– Non-Functional Requirements
– Inverse Requirements
– Design Constraints
– Sequence Diagrams
– Data Flow Diagrams (DFD)
– State-Transition Diagrams (STD)
– Change Management Process
9. Test case
Although Business analysts are not explicitly asked to create test cases but they must understand what they constitute and how to create one, as they sometimes have to test functionalities by referring to the test cases.
A test case is a document, which has a set of test data, preconditions, variables and expected results created to verify and validate whether a particular piece of functionality is behaving as intended (or as documented in the requirement documentation). Thus, a test case becomes a standardized document which should be referred every time a requirement has to undergo testing.
The components of a test case are:
– Test Case ID
– Test Scenario
– Prerequisite
– Test Data
– Test Steps
– Expected Results
– Actual Result
– Status
– Remarks
– Test Environment
All the above documents are created by a business analyst and are part of the project/product documentation. These documents are constantly referred through the project’s life-cycle for communication, reference and revision.