What is BRD ( Business requirements documents)
How it is Different from SRS (Software Requirements Specification)
BRD stands for business requirement documents, which play a very significant role in the traditional Software development life cycle.
BRD gives detailed information about all segments, aspects, and all components of SDLC.
it contains details of the projects name, project ID, project objects, project Goals Resources require for this project and risks and dependencies involved in that,
scope, and opportunity of the project on which we are going to work it also helps to know problems situation project is going to solve. it also makes us aware of
the success criteria and methods we will solve.
STRUCTURE OF BRD:-
1) Introduction
2) requirements scope
3)Functional requirements
4 Data requirements
5) Nonfunctional requirements
6)interface requirements
7)schedule time with the timeline Deadlines
8)Cost benefits
9) Expectations and assumption
10) business glossary
The BRD is prepared at the initial stage of the project for the introduction of projects and for requirements Gathering.
How it is different from SRS:
SRS:- Refers to Software requirement specification
BRD comes under the requirement of gathering.
SRS comes under the requirement analysis of SDLC it contains functional requirements and technical requirements of the project.
USE:-
SRS is used by various individuals in the organization. system client needs SRS to specify and verify whether requirements meet the desired needs in addition SRS to
enable the managers to plan for the system development process system engineers need requirements documents to understand what system is to be developed.
CHARACTERISTIC: –
Correct: – is correct when all requirements’ documents are stated in the business requirements Documents
Unambiguous:-
SRS is Unambiguous when every stated requirement has only one interpretation.
Complete:- SRS complete when the requirements clearly define what software
STRUCTURE OF SOFTWARE REQUIREMENTS SPECIFICATION
1) Introduction
2) Overall description
3) Product perspective
4) Product Function
5) User characteristics
6) Constraints
7) Assumption and dependency
8) external interfasce
9)Function
10) software system attribute.
11) Change the requirement process
12) Documents Approval
13) Supporting information .
all requirements are verified according to format only we update the RTM.