The Business Requirement specification is not about
communicating the business needs, instead it is about communicating the EXACT
business needs. When I started writing this section, I was reminded of a very
funny yet informative forward mail about Customer Requirement versus Our Solution.
Below I have mentioned for you to have a glance:
Ref: ramanuj-sociologyofeverydaylife.blogspot.com
Thanks Ramanuj, for this cool creative work. Most of us,
spend very less time in business analysis and requirement gathering. This
results in failure of projects.
The Business Requirement Specification document is
formulated to communicate the exact business needs from the stake holders to
the development team. The development team here include the Project Manager,
the Architecture, the Designers, the Code Developers, the Testers, and so on.
Capturing exact business requirement plays critical role in
the business analysis activity. It is indeed a most important part of the
overall project development. It is mandatory to document the exact business
needs. If the Business Requirement specification is accurate, the probability
of other business analysis activity such as Functional specification and Feasibility
Study will also be of great accuracy.
What should be documented in a Business Requirement
Specification?
This session talks about the template of the Business
Requirement Specification. By the word “Template” we will not talk about the
font or the color used for the document. The word Template here explains the
road map to prepare the Business Requirement Specification document.
Business Requirement Specification Template
- Cover Page: This section should mention the Project Name, Document Name (Business Requirement Specification), Version Number, and Date.
- Executive Summary: This section provides the project overview, purpose of the document and scope of the specification.
- Project Description: Whether product or service, this section narrates the description of the project context. It also explains the user characteristics, assumptions, constraints, and dependencies.
- Requirements: This section explains the core requirements of the project based on the degree of prioritization. It is good to have the high level functional requirement in this section, followed by user interface and wire-frames requirements.
- Performance and Optimization: The performance section should explain about the stability, the scalability, the availability, the portability, and the latency requirements.
- Maintenance: In this section, the monitoring, the manageability, and the maintenance requirement are deeply discussed.
- Interface and Integration: This section explains the network, hardware, and system interface requirements.
- Safety and Security: This section discusses on the authorization and authentication factors.
- Data Management: Here, in this section, the rules followed while accessing the information is discussed. It also talks about the formats, integrity constraints, data entity relationships, default values and so on.
- Standards, Policies, and Regulations: This section explains the standards, policies, laws, that are predefined by the Company after many discussions and experiences.
- User Stories and Scenarios: The user stories are the measurable and quantified functions that the product or the service will perform.
- Deleted Requirements: Any discrepancies or changes in the requirement is communicated in this section for tracking purposes.
- Requirements Confirmation: This section should be in table form that explains each requirement followed by the confirmation approval signature from the Stakeholders. The Stakeholders name should be clearly documented along with the confirmed requirements. This would be the conclusion of the Business Requirement Specification Document.
