University Management System: Software Requirements Specification

Software Requirements Specification for University Management System Group 8
SOFTWARE REQUIREMENTS
SPECIFICATION
FOR
UNIVERSITY MANAGEMENT
SYSTEM
VERSION 1.0 APPROVED
PREPARED BY GROUP 8
CODE-4 TEAM
06/10/10
Team members
SC/ITC/08/0003
SC/ITC/08/0031
SC/ITC/08/0032
SC/ITC/08/0034
i
TABLE OF CONTENTS
1. Introduction................................................................................................................................................. 1
Purpose.................................................................................................................................................................................. 1
Intended Audience and Reading Suggestions........................................................................................................ 1
Project Scope....................................................................................................................................................................... 1
References............................................................................................................................................................................ 1
document overview.......................................................................................................................................................... 1
2. Overall Description.................................................................................................................................... 3
Product Perspective......................................................................................................................................................... 3
Product Features............................................................................................................................................................... 4
User Classes and Characteristics................................................................................................................................. 5
Operating Environment.................................................................................................................................................. 5
Design and Implementation Constraints................................................................................................................. 5
User Documentation........................................................................................................................................................ 6
Assumptions and Dependencies................................................................................................................................. 6
3. System Features.......................................................................................................................................... 6
Registration......................................................................................................................................................................... 7
Profile..................................................................................................................................................................................... 8
Track Student Progression............................................................................................................................................ 9
User Management........................................................................................................................................................... 10
System Management..................................................................................................................................................... 13
Department Management............................................................................................................................................ 13
Class Management.......................................................................................................................................................... 15
Online Application.......................................................................................................................................................... 16
4. External Interface Requirements........................................................................................................ 17
User Interfaces................................................................................................................................................................. 17
Software Interfaces........................................................................................................................................................ 18
Communications Interfaces........................................................................................................................................ 18
5. Other Nonfunctional Requirements................................................................................................... 18
Performance Requirements....................................................................................................................................... 18
ii
Safety Requirements..................................................................................................................................................... 19
Security Requirements................................................................................................................................................. 19
Software Quality Attributes........................................................................................................................................ 19
iii
1. INTRODUCTION
PURPOSE
The purpose of this software requirement specification is to capture requirements for developing a
University Management System for the University of Cape Coast. This document describes the
design decisions, architectural design and detailed design needed to implement the system. This
document helps to capture requirements in the early stages of the development cycle thus reduces
the risk of schedule slippage or budget overspending and enables developers to develop the
system in a more efficient manner.
INTENDED AUDIENCE AND READING SUGGESTIONS

This document is intended for use by all stakeholders involved in the development of the system.
Stakeholders comprise of customer representatives and software representatives (designer,
developer, documenter and tester).This document has been prepared to capture the requirements
of all stakeholders so that those requirements are traceable to the end product.
PROJECT SCOPE
The university management system is a web based application that will allow the university to
create a more structured organization, increases the transaction handling capacity and improves
the system of internal control.
The UMS also provides the university a system that is responsive, efficient, reliable, easy to use,
and easy to maintain. Besides, it will present a good user experience for all users.
The scope of UMS is global i.e. registered users must be able to login to their accounts by directly
accessing the university’s website and then signing in with their username and password anytime
anywhere.
The goal of this project is to transform the university workflow into internet-based operations and
services, integrated database and seamless information systems to be available at any time and
place.
REFERENCES
[1] Ian Sommerville, Software Engineering Ninth Edition, 2011.
[2] Jessica keyes, Software Engineering Handbook, 2005.
[3] Karl E. Wiegers, Software Requirements, Second Edition, 2003.
[4] IEEE Document Standards published in “IEEE Standards Collection”. 2001 Edition.
DOCUMENT OVERVIEW
1
The remainder of this document is divided into section which gives information about the
requirement specification of the system under development.
Section 2 of this document describes the system under development from a holistic point of view.
Product perspective and features, characteristics, constraints, assumptions, dependencies, and
overall requirements are defined from the system-level perspective.
Section 3 of this document describes the system features in details, by stating the description and
priority, stimulus/response sequences and functional requirements of each feature.
Section 4 of this document describes the external interface requirements of the system i.e. the
User Interfaces, Software Interface and the Communication Interface.
Section 5 of this document describes the other nonfunctional requirement – performance, safety,
security and software quality attributes – of the system under development.
2
2. OVERALL DESCRIPTION
PRODUCT PERSPECTIVE
The University Management System is a new system that replaces old paper work system; it is an
online application that will run on any electronic device that has a web-browser. The system
provides a view, submit, online registration, checking of results and other miscellaneous resources.
The view will be based on different categories, like attendance view, report generation, grade view
and many more.
Further the faculty members can add/update/remove the resource available to the students; they
can also mark the attendance of student online.
The System will also have an Administrator who will have full-fledged rights over every user. The
Administrator will be able to add and delete users; add new departments, branches, programs and
so on. The system is expected to evolve over several releases.
ADMINISTRATOR
LOGIN
BACK UP DATABASE ADD USERS
VIEW USERS ACCOUNT CHANGE PASSWORD
GENERATE REPORT RESTORE DATABASE
LOGIN
GRADE STUDENT DISPLAY GPA
VIEW PROFILE DOWNLOAD CLASS MATERIAL
VIEW STUDENT’S RECORDS RETRIEVE PASSWORD
LOAD ASSIGNMENT DISPLAY PROFILE
FACULTY UMS STUDENTS

LOGIN
CHECK GPA
DISPLAY PROFILE REGISTER
DISPLAY STUDENT’S RECORD REQUEST PASSWORD
FILL FORM
DISPLAY ADMITTED STUDENT
SUBMIT FORM
SEND EMAILS
APPLICANTS
FIGURE 1.0: CONTEXT DIAGRAM FOR UMS
PRODUCT FEATURES
3
The university management system is an online application that will operate in four modes:
 Administrative mode – for administrators
 Faculty mode – for lecturers
 Student mode – for admitted students
 Applicants mode – for applying students
In each mode, a user has access to a different set of services helping to control access to the
system and maintain the integrity of the data stored in the databases.
The features that are available to the Administrator are:
 Backup and Restore of database
 Creation, Deletion or Modification of an account/user
 Can change user’s password
 Insert/delete/edit the information available on the UMS
 Can access all the accounts of the faculty members/students
The features available to faculty members are
 Viewing of self details
 Viewing student marks and Grade
 Uploading marks, assignments, reading materials for student
The features available to the student are:
 Registration
 Viewing of Grades
 Download reading material for a course
The features available to the applicants are:
 Apply for form online.
 Filling and Submitting of form online
Refer to figure 1.0 for more features.
USER CLASSES AND CHARACTERISTICS
4
There are various kinds of users for the product. Usually web products are visited by various users
for different reasons.
The various users include:
 Administrators (Data Processing Unit): has the privileges’ of an administrator. Some level
of technical expertise is needed for some of the administrators like super administrator. This
knowledge is required in some technical function like the database management.
 Faculty Members: they would make use of the above mentioned features by accessing the
UMS online. They should have a basic knowledge of using a computer hence technical
expertise is not required.
 Students: they would make use of the above mentioned features by accessing the UMS
online. They should also have a basic knowledge of using a computer.
 Applicants: they would make use of the above mentioned features by accessing the UMS
online. A basic knowledge of using a computer is sufficient.
OPERATING ENVIRONMENT
The UMS shall operate with the following Web browsers: Microsoft Internet Explorer version 5.0
and higher, Netscape Communicator version 4.7 and other higher version, Opera 7.0 or other
higher versions available and Mozilla Firefox.
The UMS shall operate in a windows environment, running an Apache Version 2.2.11 server. The
DBMS that will be used to manage the university’s data is MySQL. The only requirement to use
this online product will only be the internet connection.
DESIGN AND IMPLEMENTATION CONSTRAINTS

The UMS shall use the client/server architecture and therefore be capable of handling multiple
requests concurrently
All script shall be written in PHP (server side scripting) and JavaScript (client side scripting).
All HTML code shall conform to the HTML 4.0 standard.
The development team has to deal with changing requirements by the clients since the model
being used in developing the software allows for that.
Another major constraint is developing the software within the time limit:
 The university might implement a new policy which states that students cannot edit their
user profile.
 There must be constant power supply to keep the server running.
USER DOCUMENTATION
5
User manual will be delivered alongside the software product. It will include product overview,
complete configuration of the used software, technical details, basic operation of the product and
contact information which will include email address.
ASSUMPTIONS AND DEPENDENCIES

UMS shall work even at when the network traffic is high. Sever shall have a power backup as well
as a database backup. The UMS shall be compatible with most of the operating systems i.e.
previous and latest ones.
Over time, the technology employed by the UMS may change. New version of the DBMS will
become available. New features will help the administrator maintain the databases, improve the
response time for simultaneous transactions, and prompt the development of new features for
student, and faculty members.
3. SYSTEM FEATURES
The users of the system will be exposed to different features depending on the user mode, all
users except applicants have to login with their unique username and password.
Homepage
LOGIN
Applicants
Page
Is login valid? No
Yes
User Mode?
Student Administrator Faculty

Page Page Page
FIGURE3:1 DATA FLOW DIAGRAM FOR LOGIN
REGISTRATION
6
DESCRIPTION AND PRIORITY
This feature shall be available only to students of the university, it shall allow them to register
their courses for the semester, and add or drop some of the courses they will be offering for
the semester. The priority of this feature is low.
STIMULUS/RESPONSE SEQUENCE
This functionality is access from the student page.
Stimulus Response
Click on the “Registration” menu Three sub-menus will drop down,
button “Register”, “add course” and
“drop course”.
Click on “Register” button A table is displayed showing the
course for the semester, their
respective credit hours, and the
total credit hours.
Click on “OK” button The student is being registered with
the courses and the database
is updated
Click on “Add course” button A table is displayed showing the

possible courses you can add,
and a list of already registered
courses
Click on any course from the list of The course is being added to
possible courses registered list of course
Click on “OK” The student database is being
updated
Click on “Drop course” A list of registered courses is displayed

Click on any course from the list of The course is being remove from the
course list
Click on “OK” The select course is removed and the
database is updated.
The new registered course is
displayed.
FUNCTIONAL REQUIREMENTS
Function Register
Input Uses the username that was used to login which is the
student index number
Process Gets the student department and level by analyzing the index
number.
Fetches the courses mounted for the semester from the
7
department and level the student belongs to.

Output Courses to be offered that semester and their corresponding
credit hours.
Requirement Student has not failed three (3) or more courses.
Function Add Course

Input Selected courses from the available courses.
Total credit hours of course already registered for.
Process Sums the credit hours of the selected course and registered
course and make sure it is not greater than 21 hours, which is
the maximum credit hours an individual can take per
semester. If greater than 21 hours the update will be cancel
Output The final courses to be offered that semester and their
corresponding credit hours.
Requirement Total credit hours is not greater than 21.
Student must have registered before he/she can add course.
Function Drop Course

Input Selected courses from the registered courses.
List of Compulsory courses from the database
Process Check if the selected course is part of the compulsory courses
Sums the credit hours of the selected course and registered
course and make sure it is not greater than 21 hours, which is
the maximum credit hours an individual can take per
semester. If greater than 21 hours the update will be cancel
Output The final courses to be offered that semester and their
corresponding credit hours.
Requirement Student must be registered before he can drop course
Compulsory course can’t be dropped
PROFILE
This feature shall be available to the students and faculty members of the university; it shall
display basic information about the individual. It shall also allow changing of password. The
priority of this feature is medium.
Stimulus Response
Click on the “Profile” menu button Opens the individual profile page,
showing the name, profile
picture, contacts, and E-mail.
8
On the profile page, click on “change Displays a form, with four (4) textbox
password” and one (1) dropdown combo
box, requesting for old
password, new password,
retype new password, security
question (combo box), and
security answer.
Clicking on “OK” button after filling the Updates the database, by changing
form the password, security
question, and security value of
the individual.
Function Change password

Input Old password, new password, security question and security
answer.
Current password from the database.
Process Checks if the password from the database matches the old
password entered by the student.
If true the change is made and the database is updated.
If false, the change is not made and the user is notified about
the error.
Output If change is successful, a prompt shall notify the user that the
change has been made.
If change is unsuccessful, a prompt shall notify that the
change was not made
Requirement New password must be not be less than six (6) characters.
TRACK STUDENT PROGRESSION
This feature shall be available to the students of the university; it shall allow them to check their
result, and calculate their CGPA. The priority of this feature is low.
Stimulus Response
Click on “Track student progression” Two sub-menu will drop down, “check
menu button on the student result” and “calculate CGPA”
page
Click on “check result” A table is displayed, showing a list of
all the courses the student
registered for the previous
9
semester and their

corresponding grades.
Click on “calculate CGPA” A list of all the courses the student has
registered for from the first
semester in level 100 to the
current semester in the current
level, with their corresponding
grades and below is the CGPA.
Function Check result

Input Student index number which is the username.
Database that holds the table.
Process Matches the student index number through the table holding
the courses which the student registered for the previous
semester and fetches the grade of each course.
Output A list of courses and their corresponding grade.
Requirement Only student who have already completed one semester can
use check their result
Function Calculate CGPA

Input Student index number - username
Database holds the table
Process Runs the student index number through the table holding the
courses which the student has registered for from the first
semester of first year to the current semester for the current
year to fetch the grade and the credit hours of the course.
The CGPA is computed by summing the product of the grade
weighting and the credit hours of each course and dividing the
summation by the total credit the student has registered for.
Output List of courses, their corresponding grades and calculated
CGPA.
Requirement Only student who have completed one semester can calculate
their CGPA.
USER MANAGEMENT
This feature is available to administrators only. It allows management of different users of

the UMS. This feature is divided into Student management, Faculty management, and
Administrator Management. It allows the administrators to search for users, to view or
modify user information, add new users, and delete users. This function is available to all
management mode selected. The priority of this feature is high.
10
Stimulus Response
Click on “User Management” menu Three sub-menu will drop down,
button “Student management”,
“Faculty management”, and
“Administrator management”.
Clicking on any of the sub-menu Loads a page that allows you to
perform function on the type of
user management chosen.
Searching, viewing and
modification of user
information, adding or deleting
users.
Enter an information about a user and Displays a list of users that
clicking on “Search” button corresponds to information that
is searched on.
If search does not match any user, a
message is displayed to the
user informing to modify search
key.
Click on “Edit User” when a user is Loads a form that hold all the record
highlighted about the user that are editable.
Click on “Ok” button after making Updates the information on the user in
modification the database.
A prompt informing the user that the
modification was successful
Click “Add User” Loads a form that is meant to be filled

with the information of the user
to be added.
Click on “Submit” button after filling the If all required field are filled correctly, a
form prompt displays the user is
successfully added.
If all required field are not correctly
filled, an error message is
displayed beside the field that
is not correctly field.
Click on ”Delete User” when a user is Displays a prompt asking for

highlighted confirmation if the admin if
he/she wants to perform the
delete action.
Click “Ok” button Prompt the admin that the deletion was
successful.
Click “Cancel” button Returns the user back to the search
11
result.
Function Search
Input Unique identifier e.g. student index number for students. or
name of the user
Database for kind of user management chosen.
Process Query the database to fetch user with value matching the
search word.
Output A list of user(s) with matching the search word or an error
message if no user matches the search word.
Requirement TBD
Function Edit User

Input The selected user, then value filled into the form for the user.
Process Checks if the form has all required field filled correctly, if
correctly filled the database is updated with the new values for
the user.
If not correctly filled, loads the form again with error message
Output Displays a message that the update was successful
Displays the form with error message, and error marks in front
of the field which was wrongly filled.
Requirement The user must be searched for and highlighted first before you
can edit it.
Function Add User

Input Name, unique identifier, contact information, email, level
(student), date of birth, program (student), department,
gender.
Process Check if the unique identifier is already in the database of the
management mode selected.
Adds the new user by creating record in the database.
Output Displays a message that user was successfully added

Displays an error message if the required field are not
correctly filled or if unique identifier already exist.
Requirement All required field must be correctly filled.
Function Delete User

Input The selected user from the search result.
Process Deletes the whole record of the selected user from the
database
Output A confirmation message if admin wants to perform the delete
action
Requirement The user to be deleted must be searched for first before you
12
can delete it.
SYSTEM MANAGEMENT
This feature is available to the administrators only. It allows the admin to restore and backup
the database as well as other system related functionalities. The priority is high.
Stimulus Response
Click on “System Management” Drops down two options, “Backup” and
“Restore”
Click on “Backup” Loads the backup page, allowing the
user to backup the system.
Click on “Restore” Loads the restore page, allowing the
user to choose the restore
point.
Function Backup
Input All the record stored in the database
Process Copying of the records on the database and storing them on a
tape drive
Output Message showing the progress of the backup.
Message showing the backup is completed
Requirement A tape drive with tape which is large enough to store the data
on the database.
Function Restore
Input Backup data from a tape drive
Process Populate the database with the data from the tape drive
Output Message showing the progress of the restore process.
Requirement Tape drive must have the backup data
DEPARTMENT MANAGEMENT
13
This feature is available to the administrator. It allows the administrator to add new
departments, mount new programs and assign lecturers to particular courses.
Stimulus Response
Clicking on “Department Drops down three sub-menu, “Add
Management” new department”, “Mount
program” and “assign lectures”
Clicking on “Add department” button This loads a form that requires the
name of the department, the
head of the department, and
the department number.
Clicking on “add” button Creates a department in the database

And message is displayed to show that
the operation is successful
Clicking on “Mount program” This will load a form that requires the
name of the program, the
department which the program
belongs to, and program
number.
Click on “mount” button This create a new program in the
database
And prompt displaying the successful
creation of the database is
displayed to the user.
Click on “Assign lectures” This displays a form requiring the
name of the course and the
name of the lecturer. Combo
boxes are used here.
Clicking on “assign” button This will display message if the
operation is successful.
Function Add department

Input Name of the department, department number, head of the
department, school the department belongs to, and the
department number.
Process Checks if the department already exists in the database and if
all required fields are filled.
If positive result the department is created, else an error
message is displayed to the user.
Output Success message if the operation is successful
Error message, if the operation is not successful
Requirement TBD
14
Function Mount Program

Input Name of program, department name, and program number.
Process Checks if the program has already been mounted and if all
required field are correctly filled
Requirement TBD
Function Assign Lectures

Input Course name and the lecturer name
Process Fetches for the lecturers id and the course id, and checks if
the lecturer has been assigned to more than three course,
If okay the lecturer is assigned to the course else an error
message is displayed specifying the cause of the error.
Requirement Lecturer must not be assigned to more than three courses.
CLASS MANAGEMENT
This feature will be available to faculty members of the university; it will allow them to
manage their student attendance and grades. The priority of this feature is medium
Stimulus Response
Click on “Class management” Display two sub-menu “Attendance”
and “Grading”
Clicking on “Attendance” Displays all the course the lecturer is
taking
Clicking on a course Displays the list of student taking the
course selected.
Each student has checkbox in front of
its student number.
Checking on the check box in front of a This marks the student to be present
student name for that meeting.
Un-checking on the checkbox This marks the student to be absent for
that meeting.
Clicking on “Grading” Displays all the courses the lecturer is
taking
Clicking on a course Displays the list of student offering the
course.
15
Each student has a combo box in front

of its student number. The
combo box list all the possible
grade a student can get.
Selecting a grade for a student Updates the database of the student
record
Function Attendance
Input Lecturer Id, Course Id from the user, checks from the check
box
Process Search through the database for the courses the lecturer is
lecturing.
Search through the database for student who have registered
for that course, and set if they are present by increasing the
number of present each student has to a particular course
Output Displays the total number of student present and absent for
that particular meeting
Requirement Lecturer must be assigned to a course.
Function Grading
Input Course Id, lecture Id, and grades for each student
Process Search through the database for the courses the lecturer is
lecturing and displays it
Search for the students who are offering the course selected
by the lecturer.
Assign the grade chosen to the student database.
Output Confirmation that the update should be made.
Notification that the operation is successful.
Requirement Student with Incomplete result shall be change to E after one
week.
ONLINE APPLICATION
This feature is available to only applicants to the university. It shall allow to them to apply
and fill form online. The priority of this feature is medium.
Stimulus Response
On the homepage click on This takes you to the applicant page,
16
“Applicants” where the user has to fill a

form.
Clicking on “apply” This submits all the information the
applicants has entered into the
form.
A message is displayed to the
applicants that message has
Function Applicants
Input Name of the applicants, result of the applicants, e-mail, and
previous school.
Process Checks that all the required fields are filled correctly
Saves it into the applicant database
Output If all required field are correctly filled, a message is displayed
to the user that the application has been submitted.
Requirement TBD
4. EXTERNAL INTERFACE REQUIREMENTS
USER INTERFACES
All pages of the system shall follow a consistent theme and clear structure. The occurrence of
errors shall be minimized through the use of checkboxes, radio buttons and dropdown menu in
order to reduce the amount of text input from user.
JavaScript implement in HTML in order to provide a Data Check before submission. HTML Tables
to display information to give a clear structure that easy to understand by user. Error message
shall be located beside the error input which clearly highlight and tell user how to solve it.
17
FIGURE4:1 USER INTERFACE
SOFTWARE INTERFACES
The application interfaces with a MySQL database which holds the data required for the
application. It would also interface with the web browsers on which the application will be accessed
by the user.
COMMUNICATIONS INTERFACES
The UMS shall send an e-mail to applicants who have gain admission to the University. The HTTP
protocol will be used to facilitate communications between the client and server.
5. OTHER NONFUNCTIONAL REQUIREMENTS
PERFORMANCE REQUIREMENTS
18
Response time to queries shall take no longer than 7 seconds to load onto the screen after the
user submits the query.
The system shall display confirmation messages to users within 4 seconds after the user submits
the information to the system.
SAFETY REQUIREMENTS
The database may get crashed at any certain time due to power or operating system failure.
Therefore it is required to backup the database. The system has been configured in a way to allow
scheduled backup of the whole system’s database. This is will be done at the early hours of the
morning when the system is not expected to be used.
SECURITY REQUIREMENTS
All Users except applicants shall be required to log in to the UMS for all operations.
 The student’s index number shall be used as username.
 All users password must exceed six characters.
The database for the UMS shall be a secured one, where changes to the database shall be based
on the kind of user accessing the database.
 Administrators shall have full control over the database.
 Students shall be able to change only password.
 Faculty members shall be able to upload into the database, mark attendance and enter
student grades.
 Applicants shall only be able to enter data into the database i.e. filling of form.
SOFTWARE QUALITY ATTRIBUTES
MAINTAINABILITY
The system will be designed so that it will be easily extensible; that is new services for each user
mode (Administrator, Faculty, Student, and Applicant) can be added using the same paradigm.
While developers are required to extend the system, the code to develop new services is not
expected to be complex.
The system will allow changes to the software in order to correct defects and deficiencies found
during the field usage.
AVAILABILITY
19
High availability is a primary and critical requirement. It means that the system shall be up and
running 24/7 with no downtime. The system shall be able to recover immediately from any failure
situation from software bugs to hardware crashes.
SCALABILITY
Scalability ensures that the UMS can adapt to growing demands such as being able to handle
more users or larger number of enquires and transactions, and to have the capability to meet peak
demand periods without introducing unacceptable delays for processing queries.
*** End of the SRS ***
20

University Management System: Software Requirements Specification

Uploaded by

Copyright:

Available Formats

University Management System: Software Requirements Specification

Uploaded by

Document Information

Original Title

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

University Management System: Software Requirements Specification

Uploaded by

Copyright:

Available Formats

Software Requirements Specification for University Management System Group 8

INTENDED AUDIENCE AND READING SUGGESTIONS

FACULTY UMS STUDENTS

FIGURE 1.0: CONTEXT DIAGRAM FOR UMS

 Administrative mode – for administrators

 Faculty mode – for lecturers

 Student mode – for admitted students

 Applicants mode – for applying students

The features that are available to the Administrator are:

 Backup and Restore of database

 Creation, Deletion or Modification of an account/user

 Can change user’s password

 Insert/delete/edit the information available on the UMS

 Can access all the accounts of the faculty members/students

The features available to faculty members are

 Viewing of self details

 Viewing student marks and Grade

 Uploading marks, assignments, reading materials for student

The features available to the student are:

 Download reading material for a course

The features available to the applicants are:

 Apply for form online.

 Filling and Submitting of form online

Refer to figure 1.0 for more features.

USER CLASSES AND CHARACTERISTICS

The various users include:

DESIGN AND IMPLEMENTATION CONSTRAINTS

 There must be constant power supply to keep the server running.

ASSUMPTIONS AND DEPENDENCIES

Student Administrator Faculty

FIGURE3:1 DATA FLOW DIAGRAM FOR LOGIN

DESCRIPTION AND PRIORITY

Click on “Add course” button A table is displayed showing the

Click on “Drop course” A list of registered courses is displayed

department and level the student belongs to.

Function Add Course

Function Drop Course

DESCRIPTION AND PRIORITY

Function Change password

TRACK STUDENT PROGRESSION

DESCRIPTION AND PRIORITY

semester and their

Function Check result

Function Calculate CGPA

DESCRIPTION AND PRIORITY

This feature is available to administrators only. It allows management of different users of

Click “Add User” Loads a form that is meant to be filled

Click on ”Delete User” when a user is Displays a prompt asking for

Function Edit User

Function Add User

Output Displays a message that user was successfully added

Function Delete User

can delete it.

DESCRIPTION AND PRIORITY

DESCRIPTION AND PRIORITY

Clicking on “add” button Creates a department in the database

Function Add department

Function Mount Program

Function Assign Lectures

* End of the SRS *