Software Requirements

Specification

for

University Management System

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this
document.
Software Requirements Specification for <Project> Page 2

Table of Contents
Table of Contents ii
Revision History ii
1. Introduction 1
1.1 Purpose 1
1.2 Document 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 2
2.4 Operating Environment 2
2.5 Design and Implementation Constraints 2
2.6 User Documentation 2
2.7 Assumptions and Dependencies 3
3. External Interface Requirements 3
3.1 User Interfaces 3
3.2 Hardware Interfaces 3
3.3 Software Interfaces 3
3.4 Communications Interfaces 3
4. System Features 4
4.1 System Feature 1 4
4.2 System Feature 2 (and so on) 4
5. Other Nonfunctional Requirements 4
5.1 Performance Requirements 4
5.2 Safety Requirements 5
5.3 Security Requirements 5
5.4 Software Quality Attributes 5
5.5 Business Rules 5
6. Other Requirements 5
Appendix A: Glossary 5
Appendix B: Analysis Models 5
Appendix C: To Be Determined List 6
 Software Requirements Specification for <Project> Page 3

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

1.2 Document Conventions

This software system is designed to maximize administrative, academic and overall productivity by
providing tools to automate technical procedures and processes. It is a user-friendly portal to interact,
manage and access the information.

1.3 Intended Audience and Reading Suggestions

This document is intended for a variety of audiences, including users, testers, developers, and writers of
documentation. The remaining sections of the document have been separated into various subsections.
We advise you to start by comprehending the definitions, acronyms, and abbreviations before
proceeding to the contents, overview part, and relevant detailed description sections in that order.

1.4 Product Scope

• 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 system’s 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.5 References
https://www.studocu.com/row/document/nahda-university/computer-science/srs-for-university-
management-system/27752841

2. Overall Description
 Software Requirements Specification for <Project> Page 4

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 Product Functions

2.3 User Classes and Characteristics

The current constraints on the project are related to the provision of hardware and software resources.
There is a i3 gen4 intel core processor running on top of the Linux/windows operating system, and the
documents will be present only in pdf format. Feedback forms will not be frequent and the petitioner will
not be anonymous. The Internet connection is also a constraint, and the web portal will be constrained
by the capacity of the database. Mess Rebate will be at least of 3 days, registration will be open for
short time, all documents should be in.Zip file, and the College will provide funds for SMS service if it is
not free. After submitting the course evaluation form, the user cannot revert their actions and must get
permission from the super user to do so.

3. External Interface 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 User Interfaces

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.
 Software Requirements Specification for <Project> Page 5

3.2 Hardware Interfaces

Client:
• Hardware platform:
- PIII or above with
- RAM of 512 or above MB
- Hard Disk 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
Hard Disk 20GB or above GB.

3.3 Software Interfaces

HTML, PHP, JavaScript, MySQL, Apache, CSS, MVC, Bootstrap

3.4 Communications Interfaces

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

4. Functional Requirements
This section includes the requirements that specify all the fundamental actions of
the software system.
 Software Requirements Specification for <Project> Page 6

4.1 View/Update profile

4.1.1 Purpose: View or Update the details of the student
4.1.2 Precondition: Login into Student portal
4.1.3 Actors: Student
4.1.4 Inputs:
Input Type Required/Optional Specifications
4.1.4.1 Name Text Required Only alphabet
4.1.4.2 Mother’s Name Text Required Only alphabet
4.1.4.3 Father’s name Text Required Only alphabet
4.1.4.4 DOB Numeric Required Only Numeric Birth year
must be between 1985 to
2004
4.1.4.5 Age Numeric Required Auto fill according to DOB
4.1.4.6 Gander Text Required Select from
Male/Female/Others
4.1.4.7 Mobile Number Numeric Required 10 digits numeric
4.1.4.8 Email Alphanumeric Optional Alphanumeric with symbol
and symbol and end with “@gmail.com”
4.1.4.9 Address Alphanumeric Required Must be alphanumeric

4.1.5 Basic Path: After login into student portal using valid student ID and password student
view his/her details and update his/her details if any required and click on update profile button.
4.1.6 Output: Display the message: “Your profile is update successfully.”
4.1.7 Post condition: Go to student home page.

4.2 Scholarship Eligibility Criterion

4.2.1 Purpose : Check if the student is eligible for scholarship or not
4.2.2 Precondition :
a) Must be a registered student of the University
b) Attendance must be greater or equals to 75%
c) All pending fees must be cleared
4.2.3 Actors : Scholarship in charge, teacher, accounts officer
4.2.4 Inputs :

Inputs Type Required/Optional Specification

4.2.4.1 Student’s Name Text Required Only alphabets

4.2.4.2 Registration number Numeric Required Number must be of
12 digits
4.2.4.3 Roll number Numeric Required Number must be of
10 digits
4.2.4.4 Attendance Numeric(in Required Attendance must be
percentage) greater or equals to
75%
4.2.4.5 Fees cleared? Yes/No Required Fees must be
cleared
 Software Requirements Specification for <Project> Page 7

4.2.5 Basic path : In the scholarship portal, the scholarship in charge enters the
student details, the teacher then confirms if the student’s attendance is
above 75% or not, then the accounts officer confirms if the fees is cleared or
not, if any of the above 2 conditions are not met, the scholarship is rejected. A
acknowledgement message is shown if the scholarship is granted or not
4.2.6 Output : An acknowledgement message is shown if the scholarship is granted
or not.
4.2.7 Postcondition : Redirected to home page.

4.3 Project Specific details

4.3.1 Purpose: To show how many professor and graduate students can work on one or multiple
projects.
4.3.2 Precondition: Must have a sponsor, starting and ending date and a budget to work.
4.3.3 Actors: Professor and graduate students.
4.3.4 Input details: Project details
Input Type Optional/Required Specification
Project_no Number Required Specific no allotted
for each project.
Identified by its
unique no.
Project_sp_no Number Required Sponsor name can
be same or different
for various multiple
projects.
Start_date Number Required Starting date is
required.
End_date Number Required Ending date is
required
Project_budget Number Required Cost of the project.

4.3.5 Basic Path: First we have to take the desire input for the project such as project no, project
sponsor name ,start date, end date and a budget. Then project is being managed by one
professor .From here we can check the no of professor working in a single project . The same
above can be implemented by various professor for multiple projects. Professors can manage
multiple projects under them. Graduate students also work under the supervision of the
professors on several projects. Their count are also considered for the project.

4.3.6: Output: To check how many professors or graduate students are working on a single or
multiple project. They can also supervise them.

4.3.7: Post Condition: the database can actually have the total no of professors or graduate
students and can act according to that for the future endeavors.
 Software Requirements Specification for <Project> Page 8

4.4 Number Of Students In A Department

4.4.1 Purpose: Using this Professor or Staff can check total number of students or their details of
a Department.
4.4.2 Pre-Condition: Professor or Office staff must be registered .
4.4.3 Actor: College Professor and Office Staff.
4.4.4 Input:

INPUT INPUT TYPE OPTIONAL/REQUIRED Specification

Department_name Char(30) Required Only alphabets
Course_name Char(30) Required Only alphabets
Semester_no Number Required Number must be of 2
digits
Year Number Required Number must be of 4
digits

4.4.5 Basic Path:

4.4.5.1: After login we will be in Dashboard.
4.4.5.2: In Dashboard Select Department.
4.4.5.3: In Department have to select Department_name.
4.4.5.4: Then have to select Course_name and Semester_no
4.4.5.5: At last have to select year.
4.4.6 Output: In output we will get a table where we will get all students details according to their
department,course and semester no.
4.4.7 Post-Condition:The database can actually have the total no of professors or graduate
students and can act according to that for the future endeavours.

5 Non Functional Requirements

5.1Performance 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.

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

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

5.4 Security Requirements

Administrator and Users with valid credentials will be able to log in to Portal.
 Software Requirements Specification for <Project> Page 9

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.