Software Requirements

Specification
for

College Management System

Prepared by: Prem Pardeshi
Ricky Parte
Hamza Patel
Akifuddin Shaikh

BVCOENM

13/08/2023
Table of Contents
1.INTRODUCTION

1.1 DOCUMENT PURPOSE

1.2 PRODUCT SCOPE
1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW
1.4 REFERENCES AND ACKNOWLEDGMENTS

2.OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

2.2 USERS AND CHARACTERISTICS
2.3 DESIGN AND IMPLEMENTATION CONSTRAINTS
2.4 ASSUMPTIONS AND DEPENDENCIES

3. SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.2 FUNCTIONAL REQUIREMENTS

4. OTHER NON-FUNCTIONAL REQUIREMENTS

4.1 PERFORMANCE REQUIREMENTS

4.2 SAFETY AND SECURITY REQUIREMENTS
4.3 SOFTWARE QUALITY ATTRIBUTES
 Page iii

Revision History
Name Date Reason For Changes Version
 Page 1

1. Introduction

1.1 Purpose

The purpose of this document is to present a detailed description of the College

Management System. It will explain the purpose and features of the system, the
interfaces of the system, what the system will do, the constraints under which it must
operate and how the system will react to external stimuli. This document is intended
for both the client and the developers of the system and will be proposed to the
Administrative head for its approval.

1.2 Intended Audience and Reading Suggestions

There are different types of intented audience for this document, such as developers,
testers, documentation writers and most importantly the users.We have divided the
rest of the document into different subsections. We suggest that you begin with
understanding the definitions, acronyms and abbreviations, then sequentially go
through contents, overview section and proceeding through the detailed description
sections that is most pertinent.

1.3 Product Scope

This software system will be a College management system for a the members of an
organization. This system will be designed to maximize the administrative, academic
and overall productivity by providing tools to assist in automating the technical
procedures and proccesses, which would otherwise have to be performed manually.
By maximizing the users work efficiency and production the system will meet the
users needs while remaining easy to understand and use. It is a user-friendly portal to
interact, manage, access the information.

1.4 References
<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough information so that the reader could
access a copy of each reference, including title, author, version number, date, and source or
location.>
 Page 2

2. Overall Description

2.1 Product Perspective

The product will be a standalone application and may be run on multiple systems
within an Internet network. The product will require a keyboard, mouse and monitor to
interface with the users. The minimum hardware requirements for the product are
specified in this document

2.2 User Classes and Characteristics

The target audience for CMS product is the college Administrator/students/faculty/staff
(Technical/Nontechnical) .The users for this system are
 Administrator The Super user of the system. Mainly focuses on administratiive and
academic related issues.
 Student A user with limited access rights.
 Staff A user of the system who has more access rights than a normal user.

2.3 Design and Implementation Constraints

The current constraints on the project are related to the provision of hardware resources and
software resources.

• At present, we have a i3 gen4 intel core processor running on top of the Linux/windows
operating system.

• The documents will be present only in pdf format.

• In the feedback forms, the replies will not be frequent and the petitioner will not be
anonymous.

• There will not be any moderater to filter out the fake complains with the
genuine ones. The superuser have to do it himself manually.

• The Internet connection is also a constraint for the application. Since

the application fetches data from the database over the Internet, it is
crucial that there is an Internet connection for the application to
function.
• The web portal will be constrained by the capacity of the database. Since
the database may be forced to queue incoming requests and therefor
increase the time it takes to fetch data.

• Mess Rebate Will at least of 3days.

 Page 3

• Registration will be open for short time.

• All Document should be in .Zip file.

• College will provide funds for SMS service if SMS service is not free.

• After submitting the course evaluation form, the user cannot revert his or her actions.

• The user cannot change his/her all personal or academic details.

He/she first have to get permission from the super user to do so.

2.4 Assumptions and Dependencies

A number of factors that may affect the requirements specified in the SRS include:

• It is assumed that only one person from the different department will have
the access to a module.i.e. Only heads of administration, academics, HEC
and Mess will have the access to their department except the faculty.

• The complaints and the feedback given by the students and other
members of the organization are assumed to be reliable.

• The schedule for the exam , the registration window will be open for only
few days only after that these pages will be inactive until next exams or
registration period.

• Apportioning of requirements
In the case that the project is delayed, there are some requirements that
could be transferred to the next version of the application. Those
requirements are to be developed in the third release.
 Page 4

3. External Interface Requirements

3.1 User Interfaces

Client:

• Hardware platform:

- PII or above with

- RAM of 512 or above MB - HardDisk 20GB or above GB

• Software Platform: Browser :

- Mozilla Fire-Fox v12.0 or higher
- Google Chrome v27.0.1453.116m or higher.

Server:
• User Interface:
A first-time user of the web portal should see the log-in page when he/she
opens the portal. If the user has not registered, he/she should be able to
do that on the log-in page. It will also have a remember me button.If the
user is not a first-time user, he/she should be able to see the dashboard
which contains different domains like academics, Hostel, Profile, Mess,
Transport.A news bulliten, some general information, list of holidays and
different timetables will also be visible on this page.Every user should have
a profile page where they can edit their e-mail address, phone number and
password and other personal details.

• Communications interfaces
The communication between the client and the server will be done through internet.

3.2 System Feature

3.2.1 Functional Requirements

This section includes the requirements that specify all the fundamental actions of
the software system

3.2.1.1 LOGIN
This section contains students login menu where students have to login by their
 Page 5

username as well as password

3.2.1.2 MARKSHEET
This section contains student’s stored data,student can find their marks
by entering detail in ‘student detail’ Option, and after feeling their data
he/she may automatically get their marks in ‘grades point option’.

3.2.1.3 MENU
This section includes menu’s for students details such as student
profile,library system, fee report and Marksheet.

3.2.1.4 SEARCH PAGE

Here student can search their stored data entering roll no.

3.2.1.5 STUDENT INFORMATION

Here student can store their data in database form by entering data into ‘student
information’ section.
 Page 6

4. Other Non-functional Requirements

4.1 Performance Requirements

Performance should not be an issue because all of our server queries involve small
pieces of data.Changing screens will require very little computation and thus will
occur very quickly.Server updates should only take a few seconds as long as the
phone can maintain a steady signal.

4.2 Safety Requirements

Must maintain data integrity. Computer crashes and misuse should not affect a user’s history

4.3 Security Requirements

Administrator and Users with valid credentials will be able to log in to

Portal.Administrator will have access to the database structures at back-
end.Administrator will have the rights for modifications as well as any Updation work
for the datasets and website. Access to the various subsystems will be protected by a
user log in screen that requires a user name and password.To be updated in future.