1.

SRS - System Requirement Specifications

• An SRS is a formal document that communicates software requirements between
the customer and the developer.

• Key Points:

o Purpose:
▪ To outline what the software should do.
o Focus:
▪ Concentrates on "WHAT" needs to be done, not "HOW" to do it.
o Language:
▪ Written in terms that end users understand.
o Development:
▪ If needed, a more detailed requirements document can be created
later.
• This ensures everyone involved has a clear understanding of the software's goals
before moving forward.
• A software Requirement specification should be Complete, Consistent, Traceable,
Unambiguous, and Verifiable.

Format of the SRS -

This is the basic structure and different company has different statute and it has to be
according to that requirement.

• Introduction of the SRS

1. Purpose
a. Outline the goals of the SRS document and its importance in communicating
software requirements between the customer and the developer.
2. Definitions, Acronyms, and Abbreviations
a. Provide a list of terms, acronyms, and abbreviations used throughout the
document to ensure clarity.
3. Overview of the Document Structure
a. Briefly describe the sections included in the SRS and how to navigate through
the document.
4. Client Requirement / Scope
a. Description: Define the boundaries of the project and what will be included
and excluded.
Detailed Description

1. Project Objective
a. Clearly state the main goals and intended outcomes of the project.
2. User Classes and Characteristics (Target Users)
a. Identify different types of users who will interact with the software and their
specific needs.
3. Operating Environment
a. Specify the hardware, software, and network requirements necessary for the
software to function effectively.
4. Assumptions and Dependencies
a. List any assumptions made during the requirements gathering and any
dependencies on external factors or systems.
Specific Requirements

1. Non-Functional Requirements
a. Outline criteria such as performance, security, usability, and reliability that the
software must meet.
2. Interface Requirements
a. Detail requirements for APIs, user interfaces, and hardware interfaces needed
for the software to interact with other systems.
3. Data Requirements
a. Specify the types of data that will be used, including formats and database
design.
Project Modules and UI

• How Many Modules Are Involved?

o List the different modules that will be part of the project.
• Which UI is Required?
o Indicate whether the software will be mobile-based, web-based, or both.

Functionality Details for Each Module

• Description
o Provide a detailed description of each module's functionality.
• Business Rules
o Specify the rules that govern the business processes related to the module.
• Pre & Post Conditions
o Define conditions that must be true before and after a function is executed.
• Data Dictionary / Wireframe
o S.No: Serial number for reference.
o Field Name: Names of fields in the interface.
o Type: Data type (e.g., text, number).
 o Behavior: Description of how the field behaves.
o Limitation: Any constraints on the field.
• User Story
o Describe scenarios that explain how users will interact with the software.
• Use Case
o Outline specific interactions between users and the system, detailing the steps
involved.
• Validation
o Specify validation rules for data entry and user actions.

Other Considerations

• Data Flow Diagram

o Visual representation of how data moves through the system.
• Client-Side Dependency
o List any dependencies that the client needs to manage for successful
implementation.

This structure provides a clear and organized way to present all relevant information regarding
the software project, ensuring that all stakeholders are aligned on requirements and
expectations.
2. FRS / FRD - System Requirement Specifications
Definition:

The FRS details what the system is required to perform, including services, tasks, or functions.
It focuses on system behavior and user interaction rather than the technology used. It provides
clarity for all project stakeholders on how the system will fulfill business requirements.

Key Points:

1. Formal Statement of Requirements: Defines the application’s functionalities and

ensures mutual agreement between stakeholders and developers.
2. Behavior Definition: Focuses on system behavior, including calculations, data
processing, and user interaction.
3. Solution Independence: Describes what the system should do, not how it will be built
or implemented.
4. Complete Requirement Set: Leaves no room for assumptions by providing a
comprehensive list of functions.
5. Non-technical Document: Designed for general audiences without requiring in-depth
technical knowledge.
6. Input for Development: Provides the foundation for system development and testing
to ensure all business objectives are met.

A Functional Requirement document should include the following:

1. Descriptions of Data to be Entered into the System
a. This section describes the types of data users need to input, such as names,
addresses, dates, or product details.
b. It specifies data formats, validation rules, and constraints (e.g., the username
must be alphanumeric, the password should be at least 8 characters long, etc.).
2. Descriptions of Operations Performed by Each Screen
a. This outlines what actions users can perform on each screen, such as submitting
forms, clicking buttons, or navigating to different sections.
b. It details how each screen interacts with the data and what happens when
certain operations are triggered (e.g., logging in, editing a profile, or generating
a report).
3. Descriptions of Workflows Performed by the System
a. This explains the system’s overall flow, outlining how various functions and
tasks are performed in sequence.
b. It describes how data moves through the system, the steps in processes, and
how different screens and operations are connected (e.g., user registration
workflow, approval processes).
4. Descriptions of System Reports or Other Outputs
 a. This section specifies what types of reports, summaries, or data exports the
system generates.
b. It explains how data is aggregated and presented (e.g., sales reports, inventory
summaries, user activity logs).
5. Who Can Enter the Data into the System?
a. This outlines user roles and permissions, identifying who can enter, modify, or
view specific data.
b. It defines access levels for different types of users (e.g., only admins can add
new users, customers can edit their profiles, managers can generate reports).
6. How the System Meets Applicable Regulatory Requirements
a. This details how the system complies with legal and regulatory standards, such
as data protection laws, security measures, and industry regulations (e.g., GDPR
compliance, security encryption, or audit trails).
b. It ensures that the system adheres to all relevant laws and standards in its
operations.

These elements ensure that the functional requirements document thoroughly describes how
the system should function from both a user and business perspective.

Example According to Login Page:

Functional Requirements for a Login Page:

1. User Input:
a. Users must enter a valid username and password.
2. Validation:
a. The system should validate the user’s credentials against the database.
b. Password must be at least 8 characters long, including one uppercase letter and
a number.
3. Error Handling:
a. If incorrect credentials are provided, an error message will display: "Invalid
username or password."
b. If the user attempts to log in more than 3 times unsuccessfully, the account will
be locked for 30 minutes.
4. Password Reset:
a. The user should be able to click a "Forgot Password" link, which sends a reset
link to the registered email.
5. Security:
 a. Passwords must be encrypted before being sent to the server.
b. The system should log the user's IP address for failed login attempts.
6. Session Management:
a. Upon successful login, the user session will remain active for 30 minutes of
inactivity, after which they will be logged out automatically.
7. Role-based Access:
a. Only users with valid roles (admin, user) can access specific parts of the
application based on their role after login

Here is a comparison table between FRS (Functional Requirements Specification) and SRS
(Software Requirements Specification):

FRS (Functional Requirements SRS (Software Requirements

Aspect
Specification) Specification)
Describes the specific functions Describes both functional and non-
Definition
the system must perform. functional requirements of the system.
Focuses only on functional Covers both functional and non-functional
Scope
requirements. requirements (performance, security, etc.).
Defines what the system should Provides a comprehensive blueprint for
Purpose do (specific functions and development, including how the system
behaviors). should perform.
Business Analysts, Clients, Developers, Testers, Project Managers,
Audience
Developers. Clients.
Includes technical details such as
Technical Generally does not include
performance, security, and system
Details technical details.
constraints.
 Non-
Includes non-functional aspects like
Functional
Not covered. performance, scalability, reliability,
Requirement
security.
s
Functional behavior and user Both functional behavior and system
Focus
interaction. performance in different conditions.
Describes tasks, calculations, Describes both tasks and technical
Level of
and data manipulation for each requirements such as how fast the system
Detail
function. should perform.
Validating login credentials, encrypting
Validating user login
Example passwords, and ensuring performance
credentials.
standards like page load time.
Document Defines system functionality to Defines the entire system specification to
Objective meet business needs. guide design, development, and testing.

This table summarizes the main differences between FRS and SRS, highlighting
their individual purposes and scopes.
3. BRS / BRD – Business Requirement Specifications
Description :-
A Business Requirements Document (BRD) is a formal document that outlines the
business needs and objectives for a particular project or system. It serves as a blueprint
for developing solutions, defining what the business wants to achieve, and specifying the
functional requirements of the system or project.

The BRD ensures that both the business and the technical team are aligned on the goals,
scope, and deliverables of the project. It is used to guide the development process and
serves as a reference throughout the project lifecycle.

Key Points of BRD:

• Purpose: Describes the business problem and the need for a solution.
• Scope: Defines the boundaries of the project, including what will and won't be
covered.
• Business Objectives: Clearly outlines the goals that the project aims to achieve.
• Functional Requirements: Specifies what the system should do to meet business
needs.
• Non-Functional Requirements: Includes performance, security, usability, and
scalability requirements.
• Stakeholders: Identifies key business stakeholders, users, and project teams
involved.
• Assumptions and Constraints: Lists any assumptions made and limitations of
the project.
• Milestones and Timeline: Outlines the key project phases, deliverables, and
deadlines.
• Technology Used: Specifies the technology stack and infrastructure required.
• Risk Analysis: Identifies potential risks and mitigation strategies.
• Client Side Dependency ; Required from the clint in the process of development
which is not included in the development or its extra payable
o Third party API
o Domain
o Account for Google Play

Points Covered in a BRD:

1. Introduction and Business Overview:

 a. A high-level summary of the project’s purpose and the problem being
solved.
2. Project Scope:
a. What will be delivered (in scope) and what will not be covered (out of
scope).
3. Business Objectives:
a. Specific, measurable objectives the business aims to achieve with the
project.
4. Functional Requirements:
a. Detailed description of the functions and features the system must include.
5. Non-Functional Requirements:
a. Performance metrics, security standards, and other operational criteria.
6. Stakeholder Analysis:
a. Identifies key stakeholders and their roles in the project.
7. Milestones and Timeline:
a. Key phases of the project, with corresponding deadlines and deliverables.
8. Technology Used:
a. The technology stack, including software, hardware, and third-party
systems.
9. Risk Analysis:
a. Identifies possible risks and outlines plans to mitigate them.
10. Assumptions and Constraints:
• Any assumptions made for the project, and the limitations of the solution.

Business Requirements Document (BRD) for ERP System

1. Introduction:

The company is looking to implement a new ERP system to streamline internal processes
and improve operational efficiency. The ERP will integrate key business functions,
including finance, HR, inventory management, and customer service, into a single
system.

2. Project Scope:

• In Scope: Implementation of ERP modules for Finance, Human Resources,

Inventory, and Customer Relationship Management (CRM).
• Out of Scope: Advanced reporting tools and AI-driven analytics (to be considered
in phase 2).

3. Business Objectives:

• Automate core business functions to reduce manual errors and save time.
• Provide real-time data for better decision-making.
• Enhance customer experience by improving service and support functions.

4. Functional Requirements:

• Finance Module: Track accounts, process invoices, manage payroll, and generate
financial reports.
• HR Module: Manage employee data, recruitment, payroll processing, and
performance reviews.
• Inventory Module: Track stock levels, manage supply chains, and process orders.
• CRM Module: Manage customer interactions, sales tracking, and service
requests.

5. Non-Functional Requirements:

• Performance: The system should process requests within 2 seconds.

• Security: Data should be encrypted, and access control should be role-based.
• Usability: The system should be user-friendly with minimal training required.

6. Stakeholders:

• Business Sponsor: CFO of the company

• Users: Finance, HR, Inventory, and Customer Support teams
• IT Team: Responsible for implementation and system support

7. Milestones and Timeline:

Milestone Target Date

 Requirement Gathering 15th Oct 2024
System Design 30th Nov 2024
Development Start 1st Dec 2024
ERP Implementation Phase 1 1st Mar 2025
User Testing 15th Mar 2025
Go-Live 1st Apr 2025

8. Technology Used:

• ERP Platform: SAP S/4HANA

• Database: Microsoft SQL Server
• Frontend: AngularJS for User Interface
• Backend: Java Spring Boot for business logic
• Cloud Infrastructure: AWS for hosting and storage

9. Risk Analysis:

• Risk 1: System integration with legacy software may cause delays.

o Mitigation: Allocate extra time for integration testing.
• Risk 2: Resistance from employees in adapting to the new system.
o Mitigation: Provide comprehensive training and workshops.
• Risk 3: Data migration errors from old systems to the ERP.
o Mitigation: Conduct multiple rounds of data validation and backup.

10. Client Requirements:

• The ERP system must provide a detailed dashboard for real-time tracking of
financial and inventory data.
• The system must integrate with third-party payroll software.
• Employee data must be migrated from the existing system to the new ERP without
loss of information.

11. Assumptions and Constraints:

• Assumptions: The current hardware infrastructure can support the ERP system.
• Constraints: The budget for the project is limited to $500,000, and
implementation must be completed within six months.

Note – this is only a sample

Here’s a table summarizing the differences between a Business Requirements Document (BRD)
and a Proposal:
Business Requirements Document
Aspect Proposal
(BRD)
To outline the business needs,
To present a solution or plan to
Purpose objectives, and requirements for a
address a specific problem or need.
project.
Primarily for stakeholders within the Usually intended for clients,
organization, such as project potential customers, or decision-
Audience
sponsors, business analysts, and makers who need to understand
developers. the proposed solution.
Detailed functional and non- Overview of the proposed solution,
Content Focus functional requirements, project benefits, cost estimates, timelines,
scope, and business objectives. and project deliverables.
Highly detailed, providing More high-level, focusing on what
Detail Level comprehensive information about the the solution offers rather than in-
requirements and expectations. depth requirements.
Structured with sections on Can vary in structure but typically
Structure objectives, requirements, includes an introduction, proposed
stakeholders, risks, and timelines. solution, pricing, and conclusion.
Often developed during the pre-
Created after the initial analysis and
Stage in Project project phase to persuade
during the planning phase to define
Lifecycle stakeholders to approve the
what needs to be built.
proposed project.
Changes are typically made based
May be used as a baseline document
Change on feedback from clients or
for managing changes in project scope
Management stakeholders before project
and requirements.
approval.
Serves as a guide throughout the Used to secure approval and
Use project lifecycle, ensuring all funding for a project before it
requirements are met. begins.
 Summary:

• BRD focuses on detailing what the project needs to achieve and the requirements
necessary to meet those needs.
• Proposal is aimed at convincing stakeholders to support a particular solution or project,
highlighting the benefits and feasibility of the suggested approach.

4. Proposal
A proposal is a formal document that outlines a suggested plan or solution to address a
specific problem or need. It is typically used in business settings to persuade
stakeholders, clients, or decision-makers to approve a project, investment, or course of
action.
When to Prepare a Proposal

• When Identifying a Need: When a business or client identifies a gap or problem

that requires a solution.
• Before Project Initiation: Prior to starting a project, to secure funding or approval
from stakeholders.
• For Bidding Purposes: When competing for a contract or project, especially in
public sector bids.
• In Response to RFPs: When responding to a Request for Proposal (RFP) issued by a
client or organization.

Key Points of a Proposal

1. Purpose and Objectives: Clearly define the problem or need and the objectives of
the proposal.
2. Proposed Solution: Describe the proposed solution, including the methodology,
approaches, and any unique features.
3. Benefits: Highlight the benefits and advantages of the proposed solution over
alternatives.
4. Timeline: Provide a realistic timeline for the project, including key milestones and
deadlines.
5. Budget: Include a detailed budget that outlines costs associated with the project,
including resources, labor, and materials.
6. Risks and Mitigation: Identify potential risks and outline strategies for mitigating
those risks.
7. Qualifications: Provide information about the team or organization’s qualifications,
experience, and expertise related to the project.
8. Conclusion: Summarize the key points and restate the value of the proposed
solution.

Format of a Proposal

Here is a common format for a proposal:

1. Title Page
a. Proposal Title
b. Date
c. Prepared by (Name/Organization)
 d. Prepared for (Client/Organization)
2. Table of Contents
a. List of sections and page numbers for easy navigation.
3. Executive Summary
a. A brief overview of the proposal, including key objectives, the proposed
solution, and benefits.
4. Introduction
a. Background information on the problem or need and the context for the
proposal.
5. Problem Statement
a. A detailed description of the problem or need that the proposal aims to
address.
6. Proposed Solution
a. Detailed explanation of the proposed solution, methodologies, and
approaches.
7. High Level understanding
a. What we understand
b. Want we developed
8. Benefits
a. Explanation of the advantages and benefits of the proposed solution.
9. Timeline
a. Project timeline, including phases and milestones.
10. Budget
a. Detailed cost estimates, including breakdowns of expenses.
11. Team Included
a. Detail of the team which will be included in the process.
12. Risk Analysis
a. Identification of potential risks and proposed mitigation strategies.
13. Qualifications
a. Information about the organization or team’s qualifications and experience.
14. Conclusion
a. Recap of the proposal’s key points and a call to action.
15. Appendices (if necessary)
a. Additional supporting documents, data, or references.