SOFTWARE REQUIREMENTS SPECIFICATION

For
College Management System
SOFTWARE REQUIREMENTS SPECIFICATION

For

College Management System

Contents

1 INTRODUCTION

1.1 DOCUMENT PURPOSE

1.2 PRODUCT SCOPE

1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW

1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

1.5 REFERENCES AND ACKNOWLEDGMENTS

2 OVERALL DESCRIPTIONS

2.1 PRODUCT PERSPECTIVE

2.2 PRODUCT FUNCTIONALITY

2.3 USERS AND CHARACTERISTICS 4

2.4 OPERATING ENVIRONMENT

2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS

2.6 USER DOCUMENTATION 5

2.7 ASSUMPTIONS AND DEPENDENCIES

3 SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.2 FUNCTIONAL REQUIREMENTS

3.3 BEHAVIOUR REQUIREMENTS

OTHER NON-FUNCTIONAL REQUIREMENTS

4.1 PERFORMANCE REQUIREMENTS

4.2 SAFETY AND SECURITY REQUIREMENTS
4.3 SOFTWARE QUALITY ATTRIBUTES

5 ANALYSIS MODELS

1. DATA FLOW DIAGRAMS (DFD)

2. E-R DIAGRAM (REPRESENTING DATABASE SCHEMA)
4. OTHER NON-FUNCTIONAL REQUIREMENTS

4.1 PERFORMANCE REQUIREMENTS

4.2 SAFETY AND SECURITY REQUIREMENTS

4.3 SOFTWARE QUALITY ATTRIBUTES

5. ANALYSIS MODELS

1. DATA FLOW DIAGRAMS (DFD)

2. E-R DIAGRAM (REPRESENTING DATABASE SCHEMA)

1 Introduction

The title of the project is COLLEGE MANAGEMENT SYSTEM (CMS). CMS is an Internet based application
that aims at providing information to all the levels of management within an organization. This system can be
used as a information management system for the college.

For a given user, the administrator will create a loginid & password, using this user can access the system to
either upload or download some information from the database.

The front-end will be HTML pages with Java Script for client side validation whereas all business logics will be
in PHP reside at middle layer. And these layers will interact with third layer of database, which will be MySQL
database. The web server will be Apache. To start working on this project environment required is a server
having Apache as web server, MySQL as database and XAMPP as development environment.

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 Project Scope and Product Features

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 processes, which would otherwise have to be performed manually.
By maximizing the users work efficiency and production the system will meet the user’s needs while remaining
easy to understand and use. It is a user-friendly portal to interact, manage, access the information.

1.3 Intended Audience and Document Overview

There are different types of intended 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.4 Definitions, Acronyms, and Abbreviations

CMS- College Management System, SRS- Software Requirement Specification, IDLE Python, student’s data
entry Ex- Name, Father Name, Contact No. etc.

2 Overall Descriptions

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.
• Administrator the Super user of the system. Mainly focuses on administrative 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 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 moderator to filter out the fake complains with the genuine ones. The super user has 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.

• 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.

3 Specific Requirements

This section contains all the software requirements at a level of detail sufficient to enable designers to design a
system to satisfy those requirements, and testers to test that the system satisfies those requirements. Throughout
this section, every stated requirement should be externally perceivable by users, administrator, or, other external
systems.

3.1 External Interfaces

Client:

• Hardware platform:

- PIII 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 bulletin, 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 Functional Requirements

This section includes the
requirements that specify all the
fundamental actions of the software
system
LOGIN
 This section contains students
login menu where students have to
login by their username as well as
password
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’.

MENU
This section includes menu’s
for students details such as student
profile,library system, fee report and
Marksheet.
 SEARCH PAGE
Here student can search their
stored data entering roll no.

STUDENT INFORMATION
Here student can store their
data in database form by entering
data into ‘student information’
section.
3.2 Functional Requirements

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

LOGIN

This section contains student’s login menu where students have to login by their username as well as
password.

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’.

MENU

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

Mark sheet.

SEARCH PAGE

Here student can search their stored data entering roll no.
STUDENT INFORMATION

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

3.3 Non Functional Requirements

3.3.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.

3.3.2 Reliability

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

3.3.3 Availability

The CMS Portal shall be available, up and running for 24*7 throughout the year except due to the routine
maintenance activities.

3.3.4 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 Updating
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.

4 Analysis Modules

Data Flow Diagram (DFD): It is a way of representing system requirements in graphical form; this led to
modular design. A DFD describes a data flow (logical) rather than how they are processed. So they do not
depend upon software, hardware, data structure or file organization. It is also known as ‘bubble sort’. A DFD is
a structured analysis and a design tool that can be used for flowcharting in place of, or in association with,
information-oriented and process oriented system flowcharts. A DFD is considered as an abstract of the logic of
information-oriented or process-oriented system flowchart. The four basic symbols used to construct data flow
diagrams are-

Data Flow

Process
File

Data Source or Sink

Age DOB

Name Sex

Students

Enrolls

Address
 Name College

Affiliation

Specialized in

B .tech CSE BCA

S. No Name of Experiment Date Remark Signature

1

9
10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26