College Management System

(SRS Report)

Member Name:
Muhammad kashif (15)
Asad kamal shah (42)

Deparment:
CS & IT
Submited To:
Mr,Fahad Rauf

University of Mianwali
 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 DESCRIPTION

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

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 LLLLLL
4 2.
FUNCTIONAL
PERFORMANCE
AND
5REQUIREMENTS
ATTRIBUTES
QUALITY
MODELS
(DFD)
DIAGRAMS
SCHEMA)
DATABASE
(REPRESENTING
DIAGRAM
4.1
4.2
4.3
1.
OTHER
ANALYSIS
DATA
E-R
SAFETY
SOFTWARE
SECURITY
NON-
FLOW
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

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

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 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:

• 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

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.3 Behaviour Requirement
Behaviour requirements are used to document user interfaces. Specifications of business automation such as
business rules, calculations and process flows. Specifications of user interactions often represented as use cases .

4. Non Functional Requirements

Non functional Requirements (NFRs) define system attributes such as security, reliability, performance,
maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system
across the different backlogs.

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 Reliability

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

4.3 Availability

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

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

Software Quality Attributes:

Software Quality Attributes are features that facilitate the measurement of performance of a software product
by Software Testing professionals, and include attributes such as availability, interoperability, correctness,
reliability, learnability, robustness, maintainability, readability, extensibility, testability.

5 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 Arrow showing
Direction of flow

Process Circles

Files Horizental pair

of lines

Data source, Rectangular Box

sink

The points at which data is transformed are called as nodes. The principle processes that take place at nodes are:

1.Combining data streams

2.Splitting data streams

3.Modifiying data streams

E-R Diagram:

Age Gender

Name DOB

Student

Enrolls in

Affiliation

College

Name Address

Specializ
ed in

Computer
science Mechanical Electronic