Experiment No.

Aim: Preparation of software requirement specification (SRS) document in IEEE format.

Laboratory Outcome: Develop architectural models for the selected case study.

Theory:
A software requirements specification (SRS) is a description of a software system to be
developed. It is modeled after business requirements specification (CONOPS). The software
requirements specification lays out functional and non-functional requirements, and it may
include a set of use cases that describe user interactions that the software must provide to
the user for perfect interaction.
Software requirements specification establishes the basis for an agreement between
customers and contractors or suppliers on how the software product should function (in a
market-driven project, these roles may be played by the marketing and development
divisions). Software requirements specification is a rigorous assessment of requirements
before the more specific system design stages, and its goal is to reduce later redesign. It
should also provide a realistic basis for estimating product costs, risks, and schedules.[1] Used
appropriately, software requirements specifications can help prevent software project
failure.
The software requirements specification document lists sufficient and necessary
requirements for the project development. To derive the requirements, the developer needs
to have clear and thorough understanding of the products under development. This is
achieved through detailed and continuous communications with the project team and
customer throughout the software development process.

The SRS may be one of a contract's deliverable data item descriptions or have other forms of
organizationally-mandated content.

IEEE SRS Document:

 Software Requirements
Specification
for

Student management System

Version 1.0 approved

Prepared by

Prasad

Het

Umar

SAKEC

8-08-22
Software Requirements Specification Page 2

Table of Contents
Table of Contents 2
Revision History 3
1. Introduction 1
1.1Purpose 1
1.2Document Conventions 1
1.3 Intended Audience and Reading Suggestions 1
1.4 Product Scope 1
1.5 References 1
2. Overall Description 2
2.1 Product Perspective 2
2.2 Product Functions 2
2.3 User Classes and Characteristics 3
2.4 Operating Environment 3
2.5 Design and Implementation Constraints 3
3. External Interface Requirements 4
3.1 User Interfaces 4
3.2 Hardware Interfaces 4
3.3 Software Interfaces 4
3.4 Communications Interfaces 4
4. System Features 5
4.1 System Feature 1 5
4.2 System Feature 2 (and so on) 5
5. Other Nonfunctional Requirements 6
5.1 Performance Requirements 6
5.2 Safety Requirements 6
5.3 Security Requirements 6
5.4 Software Quality Attributes 6
Software Requirements Specification Page 3

Revision History
Name Date Reason For Changes Version
Software Requirements Specification for <Project> Page 1

1. Introduction
1.1 Purpose
The purpose of this document is to build a SRS system to manage student records to ease the
student management.

1.2 Document Conventions

This document uses the following conventions.

DB Database

SR Student registration

1.3 Intended Audience and Reading Suggestions

This project is a prototype for the SR system and it is restricted within the college premises.
This has been implemented under the guidance of college professors. This project is useful
for the SR team.

1.4 Product Scope

The Student Management System’s major goal is to keep track of Profiles, Courses, Logins,
Exams, and Fees. It keeps track of all information pertaining to Profiles, Students, Fees, and
Profiles.

1.5 References
https://krazytech.com/projects/sample-software-requirements-specificationsrs-report-airline-
database
Software Requirements Specification for <Project> Page 2

2. Overall Description

○ 2.1 Product Perspective

Generate Student Information – In this feature the user can generate the report or the record
of the students inside the database.

Course details:
It stores the basic student information in the database.

Student description:
It includes Student code, name, address and phone number. This information may be used
for keeping the records of the student for any emergency or for any other kind of
information.

Reservation description:
It includes customer details, code number, flight number, date of booking, date of travel.

○ 2.2 PRODUCT FEATURES

The major features of Student management system as shown in below

Add Student Information – In this feature the user can add the information of the students.

Update Student Information – In this feature the user can update the information of the
students inside the database.

Delete Student Information – In this feature the user can delete any information of the students
inside the database.

Generate Student Information – In this feature the user can generate the report or the record
of the students inside the database.
Software Requirements Specification for <Project> Page 3

○ 2.3 OPERATING ENVIRONMENT

Operating environment for the airline management system is as listed below.

distributed database
client/server system
Operating system: Windows.
database: SQL database
platform: vb.net/Java/PHP

○ 2.4 DESIGN and IMPLEMENTATION CONSTRAINTS

The global schema, fragmentation schema, and allocation schema.

SQL commands for above queries/applications
How the response for application 1 and 2 will be generated. Assuming these are global
queries. Explain how various fragments will be combined to do so.
Implement the database at least using a centralized database management system.

○ 2.5 ASSUMPTION DEPENDENCIES

Let us assume that this is a distributed student management system and it is used in the
following application:
To store the basic student information in the database.
Calculating the number of students in a particular course.
To add or delete particular course by the administrator
To add/delete/update student information from the database.
Software Requirements Specification for <Project> Page 4

3. External Interface Requirements

3.1 User Interfaces

After opening the application, the user will have these following options: -

Add Student Information – In this feature the user can add the information of the students.
Update Student Information – In this feature the user can update the information of the
students inside the database.
Delete Student Information – In this feature the user can delete any information of the students
inside the database.
Generate Student Information – In this feature the user can generate the report or the record
of the students inside the database.

3.2 Hardware Interfaces

Add Student Information – This feature allows the user to add data of new students to the
database.
Update Student Information –This feature allows the user to make changes in the database.
Delete Student Information –This feature allows the user to delete the data of a student from
the database.
Generate Student Information – In this feature the user can generate the report or the record
of the students inside the database.

3.3 Software Interfaces

Software Used -A Java code for a Student Management System allows you to keep track of
student records and manage them as needed. This is a straightforward Java project with a
pleasing and engaging user interface. This project makes use of a MySQL database to store
and manage all of the data.

Operating System-We have chosen Windows operating system for its best support and user-
friendliness.

3.4 Communications Interfaces

The user will need to enter their email ID and password as a part of login.
Software Requirements Specification for <Project> Page 5

4. System Features
4.1 Description and Priority

The SR system maintains information on Profiles, Courses, Logins, Exams, and Fees. Of
course, this project has a high priority because it is very difficult for the administration to
manage all student records of different branches and year.

4.2 Stimulus/Response Sequences

● Search for student records.

● Displays a detailed list of available students according to different criteria.
● Cancel an existing registration.

4.3 Functional Requirements

● Distributed Database:
Distributed database implies that a single application should be able to operate transparently
on data that is spread across a variety of different databases and connected by a
communication network

● Client/Server System
The term client/server refers primarily to an architecture or logical division of responsibilities,
the client is the application (also known as the front-end), and the server is the DBMS (also
known as the back-end).
A client/server system is a distributed system in which,
● Some sites are client sites and others are server sites.
● All the data resides at the server sites.
● All applications execute at the client sites.
Software Requirements Specification for <Project> Page 6

5. Other Nonfunctional Requirements

5.1 Performance Requirements

The steps involved to perform the implementation of the Student database are as listed below.
Login page: Student or Employee (Student or employee mail id is needed)
Student section: Get basic student information that is available from the time of admission
Employee section: They will be able to edit or view student data for all the courses

5.2 Safety Requirements

If there is extensive damage to a wide portion of the database due to catastrophic failure, such
as a disk crash, the recovery method restores a past copy of the database that was backed up
to archival storage (typically tape) and reconstructs a more current state by reapplying or
redoing the operations of committed transactions from the backed-up log, up to the time of
failure.

5.3 Security Requirements

Security systems need database storage just like many other applications. However, the
special requirements of the security market mean that vendors must choose their database
partner carefully.

5.4 Software Quality Attributes

AVAILABILITY: The flight should be available on the specified date and specified time as
many customers are doing advance reservations.
CORRECTNESS: The flight should start from the correct start terminal and should reach the
correct destination.
MAINTAINABILITY: The administrators and flight in chargers should maintain correct
schedules of flights.
USABILITY: The flight schedules should satisfy a maximum number of customers' needs.

Conclusion: Here we were able to prepare a software requirement specification (SRS)

document in IEEE format.