College Management System SRS

SOFTWARE REQUIREMENTS
SPECIFICATION
for
College Management System

Release 1.1
Prepared by Team 3
Contents
1 Introduction
1.1 Purpose . . . . . . . . . . . . . . . . . . . .
1.2 Project Scope and Product Features . . . .
1.3 Intended Audience and Document Overview
1.4 Definations, Acronyms, and Abbreviations .
1.4.1 Definations . . . . . . . . . . . . . .
1.4.2 Acronyms, and Abbreviations . . . .
1.5 References . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
4
5
5
5
6
2 Overall Description
2.1 Product Perspective . . . . . . .
2.2 User Classes and Characteristics
2.3 Constraints . . . . . . . . . . . .
2.4 Assumptions and Dependencies .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
7
8
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
10
14
19
21
24
27
27
27
27
27
4 Supporting information
4.1 upadate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
28
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Specific Requirements
3.1 External Interfaces . . . . . . . . . . . . . . . . . .
3.2 Functional Requirements . . . . . . . . . . . . . . .
3.2.1 User Class one - Student . . . . . . . . . . .
3.2.2 User Class two - Administrative head(Super
3.2.3 User Class three - Faculty . . . . . . . . . .
3.2.4 User Class four - HEC head . . . . . . . . .
3.2.5 User Class Mess committee head- Student .
3.3 Non Functional Requirements . . . . . . . . . . . .
3.3.1 Performance Requirements . . . . . . . . .
3.3.2 Reliability . . . . . . . . . . . . . . . . . . .
3.3.3 Availability . . . . . . . . . . . . . . . . . .
3.3.4 Security Requirements . . . . . . . . . . . .
. . . .
. . . .
. . . .
user)
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Revision History
Revision
v1.0
v1.1
Revision Date
Sept 12,2015
Sept 25,2015
Description of Change
Initial Document
Second Document
Author/Modifier
Shubham Subhankar Sharma/Vikash Saini
Shubham Subhankar Sharma/Vikash Saini
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 where as 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 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.3 Intended Audience and Document Overview

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.4 Definations, Acronyms, and Abbreviations

1.4.1 Definations
Browser : Software used to view hypertext documents. Internet Explorer and Netscape
Navigator are examples of browsers.
HTML : Hypertext Markup Language is a specification for graphical layout of a document.
The specification calls for the document to be stored as text containing a series of tags
that contain formatting information
PHP : Server side scripting language.
JavaScript : is a high level, dynamic, untyped, and interpreted programming language.
MySQL : MySQL is an open-source relational database management system.
standalone application : A Software that is not a part of some bundled software. A
program that is run as a separate computer process, not an add-on of an existing process.
Standalone program, a program that does not require operating systems services to run.
A portable application, which can be run without the need for installation procedure.
Web Portal : A web portal is most often one specially designed web page that brings
information together from diverse sources in a uniform way.
Data Integrity : Data integrity refers to maintaining and assuring the accuracy and
consistency of data over its entire life-cycle, and is a critical aspect to the design, implementation and usage of any system which stores, processes, or retrieves data.
1.4.2 Acronyms, and Abbreviations

Table: 1 lists the acronyms and abbreviations used in this document with respect to CMS.
Acronyms
AJAX
API
XML
DBMS
IEEE
kbps
HTML
CSS
GUI
mbps
OS
RAM
SDLC
URL
Meaning
Asynchronous Java-Script and XML
Application Programming Interface
Extensible Markup Language
Database Management System
Institute of Electrical and Electronics Engineers
Kilo-Byte Per Second
Hypertext Markup Language
Cascading Style Sheets
Graphical User Interface
Mega-Byte Per Second
Operating System
Random Acess System
Software Development Life Cycle
Universal Resource Locator
1.5 References
http://www.cse.msu.edu/~chengb/RE-491/Papers/SRSExample-webapp.doc
https://web.cs.dal.ca/~arc/teaching/CS3130/Templates/SRS%20and%20Project%20Plan%
20Templates/SRS-template1.doc
http://regisindia.com/wp-content/uploads/2013/10/SRS-Development-of-Web-GIS-Tool_
IEEE-SA-830-SRS-Format_Final_27082013.pdf
https://en.wikipedia.org/wiki/Software_requirements_specification
https://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=
8&ved=0CBwQFjAAahUKEwjXre2yxILIAhVNjo4KHXS3Bug&url=http%3A%2F%2Fhome.agh.edu.
pl%2F~jsw%2Fio%2FIEEE830.doc&usg=AFQjCNEfca8yYVNSEGzj6a5NT6TvIaKbXQ&sig2=osOXYy-hIwIb
bvm=bv.103073922,d.c2E
http://www.cse.chalmers.se/~feldt/courses/reqeng/examples/srs_example_2010_
group2.pdf
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.
Users for specific task.
- Warden/HEC head: For Hostel management
- Mess Committee Head: For mess
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 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.
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:
Hardware Platform:
- PIII or above with
- RAM of 512 or above MB
- HardDisk 20GB or above GB.
SoftwarePlatform:
-HTML,PHP,JavaScript,MySql,Apache,CSS,MVC,Bootstrap
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 Functional Requirements

This section includes the requirements that specify all the fundamental actions of the software
system
3.2.1 User Class one - Student

3.2.1.1 Functional Requirement
ID:FR1
TITLE:Login into the Portal.
DESC: The user can login into the system by providing its loginid and password to the portal
which are unique and provided by the college.
RAT:To login into the portal and take advantage of the services provided by it.
DEP:None

ID:FR2
TITLE:Change password
DESC:Change the password after logging into the system.The user will be asked a security
question if he/she forgets his/her password. In case, he/she is unable to do so, the user has to
formally apply to the admin for the change of his/her password providing the necessary proof.
RAT:For security purposes, the user can choose his/her password
DEP:FR1

ID:FR3
TITLE:View/change profile details.
DESC:The user can view or change some of his/her personal details like email id, contact details
and address details. The profile will contain name, age,permanent address, parents name, their
address, their contact details, branch, year, semester, room alloted, hostel name and no. etc.
RAT:To update his/her profile and know his or her status.
DEP:FR1

ID:FR4
TITLE:Help
DESC: Can get help through the help option which gives information about the different features provided by the system. A copy of user manual will also be provided in this section.
RAT:In case of any confusion, the user can solve the problem easily and better understand the
functionality of the system.
DEP:FR1
10

ID:FR5
TITLE:Timetables
DESC:The user can view timetable for classes, mess and buses on the front page of the portal
after logging into the system.
RAT:By geting this information, user can schedule his routine and better utilize his/her precious
time.
DEP:FR1
3.2.1 6 Functional Requirement

ID:FR6
TITLE:List of upcoming holidays
DESC:The user can view the list on upcoming holidays on the front page of the portal after
logging into the system.
RAT:He/she could plan for vacations and other co-curricular activites.
DEP:FR1

ID:FR7
TITLE:News bulletin and Announcements.
DESC:On the front page , the user can view different news and announcements from various
departments.
RAT:The user gets updated about the college and knows whats going on in the college.
DEP:FR1

ID:FR8
TITLE:Academics
DESC:This module on dashboard contains all the information about the academics and administration.
RAT:You can get all the information about academics after getting inside this module.
DEP:FR1

ID:FR9
TITLE:Request for certificates
DESC:The user can request for different types of certificates like No Objection Certificate, Character Certificate, Address Proof for Hostel etc. After filling the given format , the request will
be send to the administrative department for verification of request. After the verification, the
user can get his/her certificate.
11
RAT:This feature makes the process move convinient,fast and less cumbersome.
DEP:FR1,FR8

ID:FR10
TITLE:Mess
DESC:This module on dashboard contains all the information about the mess.
RAT:You can get all the information about mess after getting inside this module.
DEP:FR1

ID:FR11
TITLE:Faculty
DESC:This module provides the information about the faculties. This includes name, education
details, areas of interest and expertise, email id and contact details(optional).
RAT:You can get all the information about faculties in one place after getting inside this module.
DEP:FR1,FR8

ID:FR12
TITLE:Assignments and reading references
DESC:The user can download the reading and writing assignments uploaded by the faculty for
their course.
RAT:The user will have a remote access to the assignments.
DEP:FR1,FR8

ID:FR13
TITLE:Course Evaluation
DESC:: At the end of the semester, a new page will be available for evaluation of a particular
course for the students. The user can give evalution for a particular course by just filling the
multiple choice questions and submitting.
RAT:This helps faculties to get a feedback for their course and improve their performance by
introspecting and also it helps the administration in better allocation of the faculty.
DEP:FR1,FR8
12

ID:FR14
TITLE:Exam Schedule
DESC:The user can view the exam schedule.
RAT:By using this feature,the user can prepare and plan his efforts in a better way.
DEP:FR1,FR8

ID:FR15
TITLE:Feedback/Complains
DESC: In this form, one can lodge a complaint or give a feedback by selecting the domain: Academics, Administration, Hostel, Mess, Transportation.The head of each department will give
response accordingly.
RAT:The user can get relieve from his/her problems without much effort or conflicts.
DEP:FR1

ID:FR16
TITLE:Fee Receipt Generation
DESC: Student can generate fee receipt by giving the bank details in the system authenticated
by the administrative head for the current and the previous semesters.
DEP:FR1,FR8

ID:FR17
TITLE:Monthly menu and timings
DESC:The user can view the monthly menu and timings of mess(breakfast,lunch,snacks and
dinner).
RAT:It helps the user to better adjust with the mess routine.
DEP:FR1,FR10

ID:FR18
TITLE:Result
DESC: Student can access their results of past semester and generate a pdf file and print by
logging into the portal. The user can not view results of other students.
RAT:The user can easily keep track of his/her academic performance.
DEP:FR1,FR8
13

ID:FR19
TITLE:Mess Rebate
DESC:The user can request for his/her mess rebate by formally applying providing a valid reason and the period of his abscence. After the verification of his request, the mess committee
will either accept or deny the request and the user will be informed accordingly. The system
will keep track of the days the rebate request was succesfully accepted.
RAT:The user can easily get rebate from mess and can also keeps track of his rebate request.
DEP:FR1,FR10

ID:FR20
TITLE:Course Registration
DESC:Here, the user can register for the courses at the start of the semester. This page will be
open for a very short time interval. The user has to provide all the necessary details and select
the electives for the semester.
RAT:The user can easily register for the semester without cumbersome paperwork.
DEP:FR1,FR8
3.2.2 User Class two - Administrative head(Super user)

ID:FR21
DEP:None

ID:FR22
DESC:Change the password after logging into the system.The user can also change the password
for other users if requested. If he/she forgets his/her password.
RAT:For security purposes, the user can choose his/her password.
DEP:FR21

ID:FR23
14
DEP:FR21

ID:FR24
TITLE:Help
DEP:FR21

ID:FR25
TITLE:Timetables
after logging into the system.The user will also have the right and access to either manually
change the timetable or automatically generate a timetable by providing the constraints like no.
of rooms in the buildings, no. of students for all the branches and semesters, no. of students
,time and capacity constraints.
time.
DEP:FR21

ID:FR26
logging into the system.The user will also have the right and access to change/modify the list.
RAT:He/she plans for vacations and other co-curricular activites.
DEP:FR21

ID:FR27
departments.The user will be able to access/broadcast important events.
RAT:The user keeps the others updated about the events that are going to happen in the college
.
15
DEP:FR21

ID:FR28
TITLE:Academics
DEP:FR21

ID:FR29
DESC:Here, the user can register for the courses at the start of the semester. This page will be
open for a very short time interval. The user has to provide all the necessary details and select
the electives for the semester.
RAT:The user can easily register for the semester without cumbersome paperwork.
DEP:FR21,FR28

ID:FR30
TITLE:Request for certificates
DESC:The user attends the request for certificates like No Objection Certificate, Character
Certificate, Address Proof for Hostel etc.The administrative department verifies request and
accordingly accepts or denies the request and procedes subsequently.
DEP:FR21,FR28

ID:FR31
TITLE:Faculty
DEP:FR21,FR28
16

ID:FR32
DESC:The user can download the reading and writing assignments uploaded by the faculty for
their course.
DEP:FR21,FR28

ID:FR33
TITLE:Course Evaluation
DESC:: At the end of the semester, a new page will be available for evaluation of a particular
course for the students. The user prepares the format for the course evaluation and decides the
window when the users can give their feedback. He also evaluates all the evaluations.
RAT:This helps faculties to get a feedback for their course and improve their performance by
introspecting and also it helps the administration in better allocation of the faculty.
DEP:FR21,FR28

ID:FR35
TITLE:Exam Schedule
DESC:The user can view the exam schedule. The user have the right to update/ modify the
exam schedule by either automatically generating the timetable by providing the required details
or manually filling the blanks.
RAT:By using this feature,the user can prepares a perfect timetable without any conflicts.It is
very time efficient .
DEP:FR21,FR28

ID:FR36
DESC: In this form, one can lodge a complaint or give a feedback by selecting the domain:
Academics, Administration, Hostel, Mess, Transportation.The user deals with the complains
and feedback in the field of academics and administration.
DEP:FR21

ID:FR37
TITLE:Fee Receipt Generation
17
DESC:The user can view details of the fee transaction details of all the students batchwise.
DEP:FR21,FR28

ID:FR38
dinner).
DEP:FR21,FR28

ID:FR39
TITLE:Result
DESC:The user keeps track of the results of all the students. The user have to right to modify/update all the details related to results.He also decides the date when the results will be
visible to the students.
RAT:The user can easily keep track of academic performance of all the students.
DEP:FR21,FR28

ID:FR40
TITLE:Alert
DESC: An alert sms will be given to the faculty members,staff and drivers beforehand consisting
of name of the faculty/ driver, phone no, vehicle no, location and timing.
RAT:The user can get prepared beforehand in this case.
DEP:FR21,FR28

ID:FR41
DESC:Here, the user will provide all the information, rules and regulations related to registration of the semester. The user can edit the form for the registration process. He/she keeps
track of all the registrations which are been done. He also verifies, validates and authenticate
the registration request using student and result records. He/she also decides what will be the
electives for a particular semester and who are applicable to apply for a course.
RAT:The user manages all the registration related processes from this single portal.
DEP:FR21,FR28
18
3.2.3 User Class three - Faculty

ID:FR42
DEP:None

ID:FR43
DEP:FR42

ID:FR44
DEP:FR42

ID:FR45
TITLE:Help
DEP:FR42

ID:FR46
TITLE:Timetables
19

time.
DEP:FR42

ID:FR47
DEP:FR42

ID:FR48
departments.
DEP:FR42

ID:FR49
TITLE:Academics
DEP:FR42

ID:FR50
TITLE:Faculty
DEP:FR42,FR49
20

ID:FR51
DESC:The user can upload the assignments on to the portal according to the year, batch and
course.
DEP:FR42,FR49

ID:FR52
TITLE:Exam Schedule
DEP:FR42,FR49

ID:FR53
DESC: In this form, one can lodge a complaint or give a feedback by selecting the domain: Academics, Administration, Hostel, Mess, Transportation.The head of each department will give
response accordingly.
DEP:FR42

ID:FR54
TITLE:Alert
DESC: An alert sms will be given to the faculty members,staff and drivers beforehand consisting
of name of the faculty/ driver, phone no, vehicle no, location and timing.
RAT:The user can get prepared beforehand in this case.
DEP:FR42,FR49
3.2.4 User Class four - HEC head

ID:FR55
21
DEP:None

ID:FR56
DEP:FR55

ID:FR57
DEP:FR55

ID:FR58
TITLE:Help
DEP:FR55
3.2.4 5 Functional Requirement

ID:FR59
TITLE:Timetables
time.
DEP:FR55
22

ID:FR60
DEP:FR55

ID:FR61
DESC:On the front page, the user can view different news and announcements from various departments.The user also have the right to announce necessary announcement related to hostel.
DEP:FR55

ID:FR62
TITLE:Faculty
DEP:FR55,FR8

ID:FR63
DESC: In this form, one can lodge a complaint or give a feedback by selecting the domain:
Academics, Administration, Hostel, Mess, Transportation.The user will deal with the complains
and feedback information related to hostel.
DEP:FR55

ID:FR64
TITLE:Mess
23
DEP:FR55

ID:FR65
dinner).
DEP:FR55,FR64

ID:FR66
TITLE:Room wise resources distribution
DESC:: Information about the room wise resource will be recorded and updated by the HEC for
the maintenance of the hostel and the college. These include quantity, price, date of purchase,
warranty period, condition, brand.The items contains fans, chairs, table , tubelight, switch board
, CFL , bulb.
RAT:The user can keep track of all the resources and also know their conditions, so that they
can estimate how much resources would be needed in the future.
DEP:FR55
ID:FR67
TITLE:Room wise student distribution
DESC:: It includes the detailed information about the students that are residing in the hostel.
It contains their name, batch, year, contact details, email no. And all these information is kept
room and hostel wise.
RAT:The user can easily manage student records, mails arrived at the gate, compensation if
any .
DEP:FR55
3.2.5 User Class Mess committee head- Student

ID:FR68
DEP:None
24

ID:FR69
DEP:FR68

ID:FR70
DEP:FR68

ID:FR71
TITLE:Help
DEP:FR68

ID:FR72
TITLE:Timetables
after logging into the system. The user have the rights to change the timings for the mess.
time.
DEP:FR68

ID:FR73
25

DEP:FR68

ID:FR74
departments.The user have the right to announce any mess related news on the news bulletin.
DEP:FR68

ID:FR75
TITLE:Academics
DEP:FR68

ID:FR76
TITLE:Mess
DEP:FR68

ID:FR77
TITLE:Exam Schedule
DEP:FR68,FR8

ID:FR78
DESC: In this form, one can lodge a complaint or give a feedback by selecting the domain: Academics, Administration, Hostel, Mess, Transportation.The user have to deal with the complains
26
and the feedback of mess related issues.

DEP:FR68

ID:FR79
DESC:The user can modify/update the monthly menu and timings of mess(breakfast,lunch,snacks
and dinner).
DEP:FR68,FR76
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 users 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 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.
27
4 Supporting information
4.1 upadate
Transpotation Funcationally is removed from our project.
Payment Details is remvoed from mess .
28

College Management System SRS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

College Management System SRS

Uploaded by

Copyright:

Available Formats

SOFTWARE REQUIREMENTS

College Management System

1.2 Project Scope and Product Features

1.3 Intended Audience and Document Overview

1.4 Definations, Acronyms, and Abbreviations

1.4.2 Acronyms, and Abbreviations

2.2 User Classes and Characteristics

2.4 Assumptions and Dependencies

3.1 External Interfaces

3.2 Functional Requirements

3.2.1 User Class one - Student

3.2.1.2 Functional Requirement

3.2.1.3 Functional Requirement

3.2.1.4 Functional Requirement

3.2.1.5 Functional Requirement

3.2.1 6 Functional Requirement

3.2.1.7 Functional Requirement

3.2.1.8 Functional Requirement

3.2.1.9 Functional Requirement

3.2.1.10 Functional Requirement

3.2.1.11 Functional Requirement

3.2.1.12 Functional Requirement

3.2.1.13 Functional Requirement

3.2.1.14 Functional Requirement

3.2.1.15 Functional Requirement

3.2.1.16 Functional Requirement

3.2.1.17 Functional Requirement

3.2.1.18 Functional Requirement

3.2.1.19 Functional Requirement

3.2.1.20 Functional Requirement

3.2.2 User Class two - Administrative head(Super user)

3.2.2.2 Functional Requirement

3.2.2.3 Functional Requirement

3.2.2.4 Functional Requirement

3.2.2.5 Functional Requirement

3.2.2.6 Functional Requirement

3.2.2.7 Functional Requirement

3.2.2.8 Functional Requirement

3.2.2.9 Functional Requirement

3.2.2.10 Functional Requirement

3.2.2.11 Functional Requirement

3.2.2.12 Functional Requirement

3.2.2.13 Functional Requirement

3.2.2.14 Functional Requirement

3.2.2.15 Functional Requirement

3.2.2.16 Functional Requirement

3.2.2.17 Functional Requirement

3.2.2.18 Functional Requirement

3.2.2.19 Functional Requirement

3.2.2.20 Functional Requirement

3.2.3 User Class three - Faculty

3.2.3.2 Functional Requirement

3.2.3.3 Functional Requirement

3.2.3.4 Functional Requirement

3.2.3.5 Functional Requirement

after logging into the system.

3.2.3.6 Functional Requirement

3.2.3.7 Functional Requirement

3.2.3.8 Functional Requirement

3.2.3.9 Functional Requirement

3.2.3.10 Functional Requirement

3.2.3.11 Functional Requirement

3.2.3.12 Functional Requirement

3.2.3.13 Functional Requirement