Different Documents prepared by a BA in a Project.
Use case Description Document:
A BA has to document the ‘business requirements’ in terms of their functionalities.
This can be done through the use cases. A use case is used to identify, and define system functionalities.
A use case is created from the user perspective and achieves the following objectives:
1. Organizes the functional requirements,
2. Iterative in nature and updated throughout the project life-cycle
3. Records scenarios in which a user will interact with the system
4. But Use case Diagrams does not cover few other aspects like negative flows, UI elements, exceptions, etc. So, for that purpose a BA prepares a Use Case Description Document.
· Preconditions, Post conditions
· Normal Flow
· Alternative Flows
· Special Requirements
· Notes and Issues
Business Requirement Document
A Business Requirement Document’s main objective is to describe the ‘business requirements’ of a proposed project and the intended end result that is expected from that project. It is one of the most widely accepted project requirement document and is referred throughout the SDLC of the project.
A BRD mainly focusses on answering ‘what is the business solution’ as opposed to ‘how to achieve the business solution’ and thus it is mainly centered on the business requirements.
A BRD is created with the help of the project team (BA, client, subject matter exerts, business partners) and is used as a communication tool for other stakeholders/external service providers, etc.
The Business Requirement Document contains:
· Project Background
· Business goals and objectives
· Requirement scope
· AS-IS Process
· TO-BE Process
· Functional requirements
· Data requirements
· Non-functional requirements
· Interface requirements
· Business glossary/Definitions
· Dependencies of existing systems
Functional requirement specification (FRS)/ Functional Specification Document (FSD)
An FRS or FSD describes how the system, including data, operations, input, output and its properties is expected to behave.
In a BRD the requirements are high level but in a FRS/FSD they are written in much more detail to capture each and every aspect of a requirement.
Thus a functional specification document is more of a technical, accurate and descriptive document.
Owing to their technical nature, FRS/FSD are equally used by developers, testers and the business stakeholders of the project.
An FRS/FSD contains..
· Product Context
· Functional Requirements
· User Interface Requirements
· System Interface/Integration
· Requirements Confirmation/sign-off
System requirement specification (SRS)/ System Requirement Document (SRD)
A detailed document containing information about ‘how’ the complete system has to function and lists the 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.
An SRS/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 Processes