| Date post: | 09-Mar-2016 |
| Category: |
Documents |
| Upload: | shadrack-benard-kweingoti |
| View: | 15 times |
| Download: | 0 times |
of 29
1
UNITED STATES INTERNATIONAL UNIVERSITY-AFRICA
COURSE TITLE : INFORMATION SYSTEMS
ENGINEERING
COURSE CODE : APP4030
SEMESTER/YEAR : FALL/2013
TASK :
PROJECT TITLE :
ASSIGNMENT #2
(INDIVIDUAL MINI-PROJECT)
REGISTRARS MANAGEMENT SYSTEM SPECIFICATION
DOCUMENT
PRESENTED TO : DR. G. CHEGE (Ph. D)
BY : SHADRACK BENARD
KWEINGOTI
ID NO : 631448
SUBMITED ON : 30TH OCTOBER, 2013
2
Contents
Preface ...................................................................................................................................................... 5
1. Introduction ........................................................................................................................................... 5
1.1 Purpose .......................................................................................................................................... 5
1.2 Scope ................................................................................................................................................... 5
1.2 Definitions, Acronyms, and Abbreviations ................................................................................... 6
1.3 References ..................................................................................................................................... 7
1.4 Overview ....................................................................................................................................... 7
2. General Description .............................................................................................................................. 7
2.1 Product Perspective ....................................................................................................................... 7
2.1.1 System Interface .................................................................................................................... 7
2.1.2 User Interfaces ...................................................................................................................... 8
2.1.3 Hardware Interfaces .............................................................................................................. 8
2.1.4 Software Interfaces ............................................................................................................... 8
2.1.5 Communications Interfaces ................................................................................................... 9
2.1.6 Memory Constraints .............................................................................................................. 9
2.1.7 Operations ............................................................................................................................. 9
2.1.8 Site Adaptation Requirements ............................................................................................ 10
2.2 Product Functions ....................................................................................................................... 10
2.2.1 User Functions ........................................................................................................................ 10
2.2.2 Students Functions .................................................................................................................. 10
2.2.3 Course Functions..................................................................................................................... 11
2.3 User Characteristics .................................................................................................................... 11
2.4 General Constraints ..................................................................................................................... 12
2.5 Assumptions and Dependencies .................................................................................................. 12
2.6 Apportioning of Requirements .................................................................................................... 12
3. Specific Requirements ........................................................................................................................ 12
3.1 External Interface Requirements ................................................................................................. 12
3.2 Functional Requirements ............................................................................................................ 13
3.2.1 Users Functions .............................................................................................................................. 13
3.2.1.1 Authorization Function ........................................................................................................... 13
3.2.1.2 Change Password .................................................................................................................... 13
3
3.2.1.3 Mail Notify .............................................................................................................................. 13
3.2.2 Administrator Functions ................................................................................................................ 13
3.2.2.1 Add User .................................................................................................................................. 13
3.2.2.2 Delete User ............................................................................................................................. 14
3.2.2.3 Display Users ........................................................................................................................... 14
3.2.2.4 Change Password .................................................................................................................... 14
3.2.3 Registrar Functions ........................................................................................................................ 15
3.2.3.1 View Students ......................................................................................................................... 15
3.2.3.2 Add Student ............................................................................................................................ 15
3.2.3.3 Delete Student ........................................................................................................................ 15
3.2.3.4 View Information .................................................................................................................... 15
3.2.3.5 Update Student ....................................................................................................................... 16
3.2.3.6 View Courses ........................................................................................................................... 16
3.2.3.7 Add New Course...................................................................................................................... 16
3.2.3.8 Delete Course .......................................................................................................................... 16
3.2.3.9 Update Grade .......................................................................................................................... 17
3.2.3.10 Make Report ......................................................................................................................... 17
3.2.3.11 Display Information ............................................................................................................... 17
3.2.4 Course Advisor Functions .............................................................................................................. 17
3.2.4.1 View Student ........................................................................................................................... 17
3.2.4.2 View Information .................................................................................................................... 18
3.2.4.3 View Users............................................................................................................................... 18
3.2.4.4 Mail Notify .............................................................................................................................. 18
3.2.4.5 Register Course ....................................................................................................................... 18
3.2.4.6 Add or Drop or Replace Course .............................................................................................. 19
3.2.5 Student Function ............................................................................................................................ 19
3.2.5.1 Check Registration Date .......................................................................................................... 19
3.2.5.2 Register Course ....................................................................................................................... 19
3.2.5.3 Add or Drop or Replace Course .............................................................................................. 19
3.2.5.4 View Information .................................................................................................................... 20
3.2.5.5 View Transcript ....................................................................................................................... 20
3.2.5.6 Update Information ................................................................................................................ 20
4
3.2.6 Lecturer Function ........................................................................................................................... 20
3.2.6.1 View Course ............................................................................................................................ 20
3.2.6.2 View Class List ......................................................................................................................... 21
3.2.6.3 Enter Grade ............................................................................................................................. 21
3.3 Use Cases .......................................................................................................................................... 22
3.3.1 Registrar Management System-Use Case Diagram ................................................................... 22
3.3.1.1 Manage User Accounts ........................................................................................................... 23
3.3.1.2 Manage Student Details .......................................................................................................... 23
3.3.1.3 Login ........................................................................................................................................ 24
3.3.1.4 Mail Notify .............................................................................................................................. 24
3.3.1.5 View Personal Information ..................................................................................................... 25
3.3.1.6 View Student Information ....................................................................................................... 25
3.3.1.7 Manage Course Details ........................................................................................................... 26
3.3.1.8 Control Student Activities ....................................................................................................... 27
3.3.1.9 Manage Lecturer Details ......................................................................................................... 27
3.4 Non-Functional Requirements .......................................................................................................... 28
3.4.1 Performance ............................................................................................................................... 28
3.4.2 Reliability ................................................................................................................................... 28
3.4.3 Availability ................................................................................................................................ 28
3.4.4 Security ...................................................................................................................................... 28
3.4.5 Maintainability ........................................................................................................................... 28
3.4.6 Portability ................................................................................................................................... 28
3.4.6 Usability...................................................................................................................................... 28
3.4.7 Friendliness ................................................................................................................................ 29
3.4.8 Privacy ........................................................................................................................................ 29
3.4.9 Extensibility ................................................................................................................................ 29
3.5 Design Constraints ............................................................................................................................ 29
5
Preface
This document contains the Software Requirements Specification (SRS) Document for the United States
International University Registrars Managements System (USIURMS). The main aim is to automate all
the functions of the Registrars Office which manage student data, course registration, grades, course
additions and drops amongst others.
1. Introduction
The following subsections are an overview of the entire Software Requirements Specification (SRS)
document.
1.1 Purpose
This SRS Document contains the complete software requirements for the United States International
University Registrars Management System (USIURMS) and describes the design decisions, architectural
design and the detailed design needed to implement the system. It defines the product functions, user
characteristics, constraints under which it must operate, how the system will react to external stimuli, and
specific requirements of the system. This document is intended for both the stakeholders and developers
of the system.
1.2 Scope
USIURMS has the main aim of automating all the functions of the Registrars Office, which manage
student data, course registration, grades, course additions and drops amongst others, in a Web-based
environment. The overall system will consist of USIURMS Student Database System and USIURMS
Web Interface. The USIURMS Student Database System will supply the fundamental database structure
of the entire system whereas USIURMS Web Interface will provide a secure Web interface between the
users and the database. USIURMS aims to create a paperless office rather than using a traditional
record keeping system.
The objectives of the project are:
To automate students record keeping processes while eliminating paperwork,
To allow manipulation of the student records,
To reduce duplicate data,
To establish an efficient communication channel between the students, registrar, course advisers,
and administrators,
To provide a way of better decision making for advisers about their students,
To enable the registrar, course advisors, and administrators to finish their work in a timely
manner.
6
1.2 Definitions, Acronyms, and Abbreviations
CGPA Cumulative Grade Point Average
USIU United States International University
GPA Grade Point Average
DBMS Database Management Systems
GB Gigabyte
HD Hard Disk
HTTP Hyper Text transmission Protocol
HTML Hyper Text Markup Language
IEEE Institute of Electrics & Electronics Engineering
IIS Internet Information Server
MB Megabyte
USIURMS United States International University Registrar Management System
Mbps Megabits per seconds
ODBC Open Database Connectivity
OS Operating System
PC Personal Computer
PHP Professional Home Page
RAM Read Access Memory
SA Systems Administrator
RO Registrars Office
SPS Software Requirements Specification
SSL Secure Socket Layer
TCP/IP Transmission Control Protocol / Internet Protocol
Paperless Office Refers to an integrated working environment where all the data and
documentation is represented in electronic format.
Course Information: Refers to information including course code and course name, and course
7
instructor.
Record Keeping
Process:
Refers to courses taken at each semester, course dropping, course adding, course
replacing and personnel record entry processes.
Student Personal
Information :
Refers to personal records of student.
Transcript
Information:
Refers to information containing student name, course codes, course title,
academic status, grade, semester, year, and CGPA.
User: Refers to the USIUs Registrar, Administrators, Students and Course advisors
who interact with the software once it is released.
1.3 References
IEEE Standards 1016-1998, Recommended Practice for Software Design Descriptions
IEEE Standards 830-1998, IEEE Recommended Practice for Software Requirements
Specifications.
1.4 Overview
This document is prepared in accordance with the IEEE Standards 830-1998, IEEE Recommended
Practice for Software Requirements Specifications.
Section 2.0 of this document gives a general description of USIURMS. It also provides product
perspectives, product functions, user characteristics, general constraints, and assumptions and
dependencies of the system.
Section 3.0 contains all the details for creating a design. It will contain functional and performance
requirements, design constraints, attributes and external interface requirements for the USIURMS.
2. General Description
This section describes the general factors that affect the USIURMS and its requirements. In order to be
easily understandable, this part of SRS provides a background for the requirements. The detailed
definitions can be found in Section 3 of the SRS.
2.1 Product Perspective
2.1.1 System Interface
The system interfaces with the finance management system.
8
2.1.2 User Interfaces
The interfaces will involve check boxes, combo boxes, text boxes, and radio buttons. The combo boxes
and the radio buttons will be used to prevent users from entering wrong type of information. They will
also enable fast data entry. Text boxes will be controlled for avoiding invalid and inconsistent data.
Users can use Tab key to move cursor on screen items easily.
There will be two types of messages for constructive advice to the users: error and confirmation
messages. There will be four types of error messages for application control: input, output, process and
database/Web server error messages.
There will be five types of users, and each user will access the screens according to their types after
entering their id and passwords. Standard screen format, fixed colors, fonts, background, the page layout,
will be used throughout the interfaces.
The language of the user interfaces will be English.
2.1.3 Hardware Interfaces
Server Side
USIURMS will be installed into the USIU Server. This is a Digital UNIX (64bit), 128 RAM, 24 GB
Hard Disk computer with a 100 Mbps access to the backbone.
Client Side
Any Personal computer, which can support any X-window or Windows environment with a mouse
support, is acceptable.
2.1.4 Software Interfaces
Server Side
Apache 1.3.2 Web server is installed at the USIU server and this web server will enable USIURMS to
interact with its users. PHP is a HTML embedded server-side scripting language, which will be used to
code the USIURMS.
Client Side
On the client side the required software product is Internet Explorer/Google Chrome/Mozilla Firefox
supporting at least HTML version 3.2, java enabled, and any operating system that can run the browsers.
9
2.1.5 Communications Interfaces
The default communication protocol for data transmission between server and the client is Transmission
Control Protocol/ Internet Protocol (TCP/IP). At the upper level Hyper Text Transfer Protocol (HTTP)
will be used for communication between the web server and client.
2.1.6 Memory Constraints
The client computer, which runs the web browser, should have enough physical memory to run this
program.
2.1.7 Operations
The USIURMS operations needed by the users are described below.
Administrator of the system registers and defines the status of users (Course advisors, Registrar,
Student, Lecturer, and Administrator) by (Add User). The user will be given a unique user id and
password, and will be notified by e-mail as soon as he/she is registered. Whenever necessary the
administrator can delete the user by (Delete User). The authorized users may change their passwords
by (Change Password). In addition, if they forget their passwords, the administrator can assign them a
new password by (Change User Password).
The registrars register new courses to the system by (Add Course) and delete the existing course
information by (Delete Course).
When a student is accepted to the USIURMS faculty, the registrar input new students personal
information by (Add Student). All the information about the students can be updated by (Update
Student). The student is assigned any course advisor when he/she registered to the system. The
registered students may also be deleted from the system by (Delete Student).
Students personal information can be accessed depending on the users status. Registrar can access
all the students personal information by (View Student). The course advisor can access students
personal information by using (View Student) and send them mail using (Mail Notify).
At the beginning of each semester, the registrar updates the students grade form according to the
transcript information taken from RO, by (Update Grade).
The advisors can register students courses information, which will be taken during the semester by
(Register Course).
The advisor can replace students core or elective course, which have been taken, with another course
by (Replace Course).
Registrar and the course advisors can access all users personal information by (Display Users). They
can also send mail to each other using (Mail Notify).
10
A student can register, drop, add, replace, list the various courses, and view their unofficial transcripts
using, (Register Course), (Add Course), (Drop Course), and (Replace Course), (View Information),
(Check Registration Date), (View Unofficial Transcript) and (Update Information).
A lecturer can view all the courses registered in the system and assigned to them for teaching by
(View Courses), view the class list containing students who have chosen their classes by (View Class
List), view his/her students details by (View Student), and enter the students grade at the end of the
semester, which will be submitted to the registrar (Enter Grade).
2.1.8 Site Adaptation Requirements
USIU server has requirements to operate PHP scripts (Apache Web server 1.3.2 with PHP 4.0 modules).
2.2 Product Functions
2.2.1 User Functions
The administrator of USIURMS shall register new users to the system. The new user can be a course
advisor, student, lecturer or the registrar. After entering the information about the user, the system gives a
unique user id and password to the users and notifies them by e-mail.
2.2.2 Students Functions
The following functions input the required information for managing the students:
The registrar shall register new students to the system, when the students are enrolled and
accepted in a specific faculty. She/he shall input and update the personal information of the
students.
The course advisor shall register students courses information, which will be taken during the
semester period.
The course advisor shall enter the students courses, which they took before they start the
program, and also replace their core or elective courses taken before, with another course.
Taking the transcript information of the students, the registrar uploads and updates the
students transcript information at the beginning of every semester.
The student shall register for courses.
The student shall add, drop, or replace courses.
The student shall download a list of all courses.
The student shall view/check his/her date of registration.
The course advisor shall register the student for courses. He/she can add, drop, and replace
courses.
11
The lecturer shall view their respective courses to be taught, view their respective class lists,
view students in their classes, and enter final students grade.
Functions to monitor the students, query the database according to information required, and generate
appropriate reports:
The registrar shall display all the students personal information.
The course advisors can display students name, courses taken, courses not yet taken, pre-
requisite courses, major, concentration, GPA and CGPA.
Report of all replaced courses can be requested.
Course advisors can send e-mail to the students they select.
2.2.3 Course Functions
The USIURMS system must be aware of all the courses. The registrar shall either register courses to the
system or delete courses from the system. The related sub-functions are the following:
2.3 User Characteristics
The Administrator
This user has to have at least Window 7/Linux OS and Internet browsing skills for administrating
USIURMS user profiles.
The Course Advisor
Since advisors are the instructors of the school, its expected that they know academic rules and
regulations of USIU. Also they have experience with at least Window 7, and Internet browsing skills.
The Registrar
Registrars have at least Window 7/Linux OS, and Internet browsing skills. They also have experience
about rules and regulations of USIU.
The Student
This user has to have at least Window 7/Linux OS and Internet browsing skills to use the system.
The Lecturer
This user must have at least Windows7, Internet browsing skills to use the system and must be aware of
all the USIU academic rules.
12
2.4 General Constraints
The software development team obeys the IEEE standards. Academic rules also have to be observed
throughout the entire requirements process.
The format of the RO file will be Excel spreadsheet, PDF or text. The file will include the required data
(student id, student name, course code, course title, academic status, year, semester, CGPA and the grade
of the course).
Related hardware and software limitations are stated in sections 2.1.1, 2.1.2, 2.1.3, 2.1.4.
2.5 Assumptions and Dependencies
Every user will have the appropriate hardware and software configuration stated in sections 2.1.1, 2.1.2,
2.1.3, 2.1.4. At the beginning of every semester, RO file will be supplied by RO.
2.6 Apportioning of Requirements
In the future if RO will give access to USIURMS for retrieving the RO file via a direct connection to their
database, requirements for language usage such as XML, type of DBMS server, communication type and
secure connection will have to be determined.
3. Specific Requirements
3.1 External Interface Requirements
Name of item: The RO file, which includes students transcript information.
Description of Purpose: This file is taken to update USIURMS Students grade information.
Source of Input: Registrars Office (RO)
Accuracy: The accuracy and integrity of the file is provided by RO. Any incorrect data is not tolerable. In
such a case, RO should correct this data.
Unit of Measure: None.
Timing: Beginning of every semester.
Relationships to Other Inputs: None.
Screen Format/Organization: None.
Window Format/Organization: None.
Data Format: The file data will include student id, student name, course title, course code, year, semester,
grade, and CGPA respectively. The file format will be either in Excel spreadsheets or text file.
Command Formats: None.
13
End Messages: None.
3.2 Functional Requirements
3.2.1 Users Functions
3.2.1.1 Authorization Function
Introduction: USIURMS shall check whether the user is authorized to use the system or not. If it is a valid
login, the system shall determine the status of the user.
Input: user id and password
Process: The user id and password are checked from the database, and if they are valid a new session will
be created depending on the status of the user. Otherwise, an error message will warn the user.
Output: Error message or successful login
3.2.1.2 Change Password
Introduction: USIURMS shall enable all its users to change their passwords.
Input: new password, old password, confirm password
Process: Logged user activates the function to change his/her password. The new password and confirm
password fields are entered. If they match, the old password will be updated with the new one.
Output: Error or confirmation message will be displayed.
3.2.1.3 Mail Notify
Introduction: USIURMS shall enable all users to send e-mails to the other users of the system.
Input: user id, message text
Process: The user selects the user(s) to whom he/she wants to send e-mail. Then the system finds the
email addresses of the recipients by querying the database according to their user ids. Then, the message
text will be sent to the recipients.
Output: error message or e-mail notification to the user(s) and confirmation message will be displayed.
3.2.2 Administrator Functions
3.2.2.1 Add User
Introduction: USIURMS shall enable administrator to add new users and define their status to the
system.
Input: user id, name, department, e-mail address, address, status, password.
14
Process: The administrator activates the function and enters the user id, name, surname, department, e-
mail address, status and password of the new user. The function will also check the database whether the
user already exists or not.
According to the results, the system adds the user to the all user list with a confirmation message, and
notifies the user by e-mail (user id, password), or the function displays an error message.
Output: error message or updated all user list, confirmation message, and e-mail notification to the user
will be displayed.
3.2.2.2 Delete User
Introduction: USIURMS shall enable administrator to delete users from the system.
Input: user id.
Process: The administrator activates the function and enters the user id. The function also checks from
the database whether the user already exists or not.
According to the results, the system deletes the user from the all user list with a confirmation message,
and notifies the user by e-mail, or the function displays an error message.
Output: error message or updated all user list, and confirmation message will be displayed.
3.2.2.3 Display Users
Introduction: USIURMS shall display all the users registered to the system.
Input: none
Process: When the administrator login the system, automatically, the current user list is displayed. The
function queries the database for users who were registered to the system.
Output: All users with their respective details (user id, name, telephone number, e-mail address, status)
will be displayed.
3.2.2.4 Change Password
Introduction: USIURMS shall enable administrator to change the system users passwords.
Input: user id, new password, confirm password
Process: Administrator activates the function to change the selected users password. The new password
and confirm password fields are entered. If they match, the old password will be updated with the new
one. Also the function notifies the user by e-mail, or the function displays an error message.
15
Output: Error or e-mail notification to the user(s) and confirmation message will be displayed.
3.2.3 Registrar Functions
3.2.3.1 View Students
Introduction: USIURMS shall display all the students enrolled to the system.
Input: none
Process: When the registrar logon the system, automatically, all student list is displayed. The function
queries the database for all the students who were enrolled.
Output: List of all students enrolled with their respective details (student id, name, major, address, e-
mail, phone, and faculty) will be displayed.
3.2.3.2 Add Student
Introduction: USIURMS shall enable registrar to add new students to the system.
Input: All students details.
Process: The registrar activates the function and enters the related input values of the new student. The
function also checks from the database whether the student already exists or not. According to the results,
the system adds the student to the all student list with a confirmation message, or the function displays an
error message.
Output: error message or updated all student list and confirmation message will be displayed.
3.2.3.3 Delete Student
Introduction: USIURMS shall enable registrar to delete student from the system.
Input: student id
Process: The registrar activates the function and enters the student id of the student. The function also
checks whether the user already exists or not. According to the results, the system deletes the student
from the all students list with a confirmation message, or the function displays an error message.
Output: error message or updated all student list, and confirmation message will be displayed.
3.2.3.4 View Information
Introduction: USIURMS shall enable registrar to display selected students personal information.
Input: student id
Process: By this function, the database is queried for all the personal information of the student.
16
Output: All students personal information form is displayed.
3.2.3.5 Update Student
Introduction: USIURMS shall enable registrar to update selected students personal information.
Input: student id
Process: With this function, the database is queried for all the personal information of the student.
Output: All students personal information form is displayed.
3.2.3.6 View Courses
Introduction: USIURMS shall display to the registrar all the courses registered to the system.
Input: none
Process: By this function, the database is queried for all the course information. According to the result,
the courses that were registered are displayed.
Output: error message or a report which contains course code, course name, course credit, course status,
and department will be displayed.
3.2.3.7 Add New Course
Introduction: USIURMS shall enable registrar to register new courses to the system. The courses of
USIU must be introduced to the system before they are assigned to the students.
Input: course code, course name, course credit, course status, department.
Process: The registrar activates the function and enters the related input values of the new course. The
function also checks from the database whether the course already exists or not. According to the results,
the system adds the course to the all course list with a confirmation message, or the function displays an
error message.
Output: error message or updated course list, and confirmation message will be displayed.
3.2.3.8 Delete Course
Introduction: USIURMS shall enable registrar to delete course from the system.
Input: course code
Process: The registrar activates the function and selects the course code of the course to be deleted. From
the all courses list, the course and its related information is deleted. With a confirmation message or the
function displays an error message.
Output: error message or updated course list, and confirmation message will be displayed.
17
3.2.3.9 Update Grade
Introduction: USIURMS shall enable registrar to upload and update the information about the students
semester transcript information.
Input: RO file.
Process: By this function, the RO file will be uploaded to the system. The file will consist of student id,
course code, course title, academic status, year, semester, CGPA and the grade of the course, which have
been taken by the student in the previous semester.
Output: error message or confirmation message will be displayed.
3.2.3.10 Make Report
Introduction: USIURMS shall enable registrar to query the database to get information of the students
enrolled to the system by selecting different options.
Input: exchange, foreign, under-graduate, graduate and post-graduate.
Process: The registrar will select the options to make the desired query. The registrar is allowed to select
multiple options. According to the query, the list of students will be displayed and the number of students
will be calculated.
Output: list of all students enrolled (student id, name, name, department, under-graduate, graduate, post-
graduate, status, number of students) will be displayed.
3.2.3.11 Display Information
Introduction: USIURMS shall enable the registrar to display the personal information of all users
registered to the system.
Input: none
Process: By this function, the database is queried for all the registered users. According to the result,
users personal information will be displayed.
Output: All user lists (user id, name, name, telephone number, permanent address, e-mail address, status)
will be displayed.
3.2.4 Course Advisor Functions
3.2.4.1 View Student
Introduction: USIURMS shall display all the students enrolled to the system.
Input: none
18
Process: When the advisor logon the system, automatically this function is called and all student lists is
displayed.
Output: List of the students enrolled.
3.2.4.2 View Information
Introduction: USIURMS shall enable advisor to display selected students personal information.
Input: student id
Process: When this function is called, the database is queried for all the personal information of the
student.
Output: respective students information.
3.2.4.3 View Users
Introduction: USIURMS shall enable the advisor to display the personal information of all users
registered to the system.
Input: none
Process: When this function is called, the database is queried for all the registered users. According to the
result, users personal information will be displayed.
Output: All user lists (user id, name, telephone number, e-mail address, status) will be displayed.
3.2.4.4 Mail Notify
Introduction: USIURMS shall enable advisor to send e-mails to the students.
Input: student id, message text
Process: The advisor selects the student(s) to whom he/she wants to send e-mail. Then the system finds
the email addresses of the recipients by querying the database according to their student ids. Then, the
message text will be sent to the recipients.
Output: error message or e-mail notification to the student(s) and confirmation message will be
displayed.
3.2.4.5 Register Course
Introduction: USIURMS shall enable the advisor to register students courses information, which will be
taken during the semester.
Input: student id
19
Process: When this function is called, the database will be queried for the students courses information
about courses yet to be taken. According to the result, students courses information will be displayed.
The advisor can use Insert Course, and Delete Course functions.
Output: Course screen with list of course information, Insert Course, and Delete Course buttons will be
displayed.
3.2.4.6 Add or Drop or Replace Course
Introduction: USIURMS shall enable the advisor to add/drop/replace a course for the student.
Input: row to be dropped/added/replaced.
Process: The advisor will select the row to be added/dropped/replaced. After this operation, the refreshed
list of courses will be displayed.
Output: error message or updated course screen and confirmation message will be displayed.
3.2.5 Student Function
3.2.5.1 Check Registration Date
Introduction: USIURMS shall enable the student to check the registration date.
Input: student id
Process: When this function is called, the database will be queried for the students information about the
date of registration. According to the results, the registration date information will be displayed.
Output: error message if not registered in the system
3.2.5.2 Register Course
Introduction: USIURMS shall enable the student to register for courses which will be taken during the
semester.
Input: student id
Process: When this function is called, the database will be queried for the students courses information
about courses yet to be taken. A select course button will be displayed where the student can select the
courses.
Output: Selected course list is displayed.
3.2.5.3 Add or Drop or Replace Course
Introduction: USIURMS shall enable the student to add/drop/replace course.
Input: row to be dropped/added/replaced.
20
Process: The student will select the row to be added/dropped/replaced. After this operation, the refreshed
list of courses will be displayed.
Output: error message or updated course screen and confirmation message will be displayed.
3.2.5.4 View Information
Introduction: USIURMS shall enable the student to display their personal information.
Input: none
Process: When this function is called, the database is queried for the students information. According to
the result, users personal information will be displayed.
Output: Personal information list (user id, name, address, telephone number, e-mail address, status) will
be displayed.
3.2.5.5 View Transcript
Introduction: USIURMS shall enable the student to view his/her transcript information from the system.
Input: none
Process: When this function is called, the database is queried for all the transcripts in the system.
According to the result, users transcript will be displayed.
Output: Transcript will be displayed.
3.2.5.6 Update Information
Introduction: USIURMS shall enable the student to update his/her personal information.
Input: none
Process: When this function is called, the database is queried for all the registered users. According to the
result, users personal information will be displayed and he/she can update it.
Output: Users personal information (user id, name, telephone number, e-mail address, status) will be
displayed.
3.2.6 Lecturer Function
3.2.6.1 View Course
Introduction: USIURMS shall enable the lecturer to view the courses assigned to them.
Input: none
21
Process: When this function is called, the database is queried for the course information. According to the
result, users course information will be displayed.
Output: course information list (course code, course title, course credit, time and class) will be displayed
by the system.
3.2.6.2 View Class List
Introduction: USIURMS shall enable the lecturer to view the list of students in their respective classes.
Input: none
Process: When this function is called, the database is queried for the class list information. According to
the result, users class list information will be displayed.
Output: class list (student no, student name, attendance) will be displayed by the system.
3.2.6.3 Enter Grade
Introduction: USIURMS shall enable the lecturer to enter the students grade to be used by RO.
Input: students grade
Alternate flow: If user enters grade out of range, the system shall not accept it. Error message is
displayed to inform him/her to enter grade within range.
Process: When this function is called, the students grade is stored into the database.
Output: students grade information (student no, student name, course code, course name, grade) will be
displayed by the system and send to the RO.
22
3.3 Use Cases
3.3.1 Registrar Management System-Use Case Diagram
Registrar Management System
Manage UserAccounts
Maintain StudentsDetails
Mail Notify
View StudentInformation
View PersonalInformation
Login
Manage CourseDetails
Control StudentActivities
Manage LecturerDetails
Administrator
Course Advisor
Lecturer
Registrar
Student
23
3.3.1.1 Manage User Accounts
Use Case Name Manage User Accounts
Introduction This use case allows the administrator to maintain user account. This includes
adding, changing and deleting, displaying all users, changing passwords of user
account information from the system.
Actors Administrator
Pre-Conditions The administrator must be logged on to the system before the use case begins.
Post-Condition If the use case was successful, the user account information is added, updated, or
deleted from the system. Otherwise, the system state is unchanged.
Basic Flow This use case starts when the Administrator wishes to add, change, and/or delete user
account information from the system.
The system requests that the Administrator specify the function he/she would like to
perform (Add User, Change User Password or Delete a User).
Once the Administrator provides the requested information, one of the sub-flows is
executed
If the Administrator selected Add User, the Add User sub flow is executed.
If the Administrator selected Delete User Account, the
Delete a User Account sub-flow is executed.
If the Administrator selected Change User Password, the Change User Password
sub-flow is executed.
Alternate Flow User Not Found: If a user account with the specified User name does not exist, the
system displays an error message. The Administrator can then enter a different User
name or cancel the operation, at which point the use case ends.
Post-Condition The system shall add, delete, change user password.
3.3.1.2 Manage Student Details
Use Case Name Maintain Students Details
Introduction Allow Registrar to maintain student details. This includes adding student, updating
student, and updating grade.
Actors Registrar
Pre-Conditions Registrar must be logged onto the system before this use case begins.
Post-Condition If use case is successful, student information is added/updated/deleted from the
system. Otherwise the system state is unchanged.
Basic Flow Starts when Registrar wishes to add/modify/update/delete Student and Course
24
information.
The system requests the Registrar to specify the function, he/she would like
to perform (Add/update/delete)
One of the sub flows will execute after getting the information.
Alternate Flow Student not found: If a student with specified id does not exist, the system displays
an error message .The registrar may enter a different id or cancel the operation. At
this point, the Use case ends.
Post-Condition The system shall add student, update student, and update grade.
3.3.1.3 Login
Use Case Name Login
Introduction Introduction: This use case describes how a user logs into the USIURMS.
Actors Administrator, Registrar, Course Advisor, Student, and Lecturer.
Pre-Conditions None
Basic Flow This use case starts when the actor wishes to login to the USIURMS. System
requests that the actor enter his/her username and password. The actor enters his/her
username & password. System validates username and password, and if finds correct
allow the actor to logs into the system.
Alternate Flow Invalid name and password. If in the basic flow, the actor enters an invalid name
and/or password, the system displays an error message.
The actor can choose to either return to the beginning of the basic flow or cancel the
login, at that point, the use case ends.
Post-Condition If the use case is successful, the actor is logged into the system. If not, the system
state is unchanged.
3.3.1.4 Mail Notify
Use Case Name Mail Notify
Introduction This use case allows the administrator to notify all users by e-mail of their respective
usernames and passwords. It allows the registrar and course advisor to send e-mails
to the specified students.
Actors Administrator, Registrar, and Course Advisor.
Pre-Conditions The administrator, registrar, and course advisor must be logged on to the system
before the use case begins.
25
Post-Condition If the use case was successful, the users are able to notify by mail. Otherwise, the
system state is unchanged.
Basic Flow This use case starts when the Administrator, Registrar, or Course Advisor wishes to
notify their recipients (user and students) by mail from the system.
I. The system requests that they specify the function he/she would like to
perform (Notify by mail).
II. Once they provides the requested information, one of the sub-flows is
executed
If they select Notify By Mail, then this sub-flow is carried out by the system
Alternate Flow User Not Found: If a user account with the specified User name does not exist, the
system displays an error message. One can then enter a different User name or cancel
the operation, at which point the use case ends.
Post-Condition The system shall notify by mail, and show success send message report.
3.3.1.5 View Personal Information
Use Case Name View Personal Information
Introduction This use case allows all the system users to view their personal information and
update it according to their usernames and passwords.
Actors Administrator, Course Advisor, Registrar, Student, and the Lecturer.
Pre-Conditions None
Post-Condition If the use case was successful, the user can view their personal information.
Otherwise, the system state is unchanged.
Basic Flow This use case starts when the user wishes to view and modify their personal
information.
I. Enter user name and password.
II. Enter user id and password.
After selecting one of the sub-flows is executed.
Alternate Flow User Not Found: Record of user does not exist. Error message should be displayed.
Post-Condition The system shall display user personal information and update it accordingly.
3.3.1.6 View Student Information
Use Case Name View Student Information
Introduction This use case allows all the course advisor and registrar to view the students
information.
26
Actors Course Advisor and Registrar
Pre-Conditions All must be logged on to the system before the use case begins.
Post-Condition If the use case was successful, Course Advisor and Registrar can view students
information. Otherwise, the system state is unchanged.
Basic Flow This use case starts when the Course Advisor and Registrar wishes to view the
students information.
Entering the students id number
After selecting, the sub-flows is executed.
Alternate Flow User Not Found: Record of student does not exist. Error message should be
displayed.
Post-Condition The system shall display the students information.
3.3.1.7 Manage Course Details
Use Case Name Manage Course Details
Introduction Allow Advisor, lecturer, student to maintain course details. This includes view/ add,
delete, register, replace, drop, and view course.
Actors Registrar, Course Advisor, Lecturer, Student.
Pre-Conditions Registrar, Course Advisor, Lecturer, and Student must be logged onto the system
before this use case begins.
Post-Condition If use case is successful, course information is
viewed/added/deleted/dropped/replaced from the system. Otherwise the system state
is unchanged.
Basic Flow Starts when Registrar, Course Advisor, Lecturer, and Student wishes view, add,
deleted, drop, replace the Course information.
The system requests the Registrar, Course Advisor, Lecturer, and Student to
specify the function, he/she would like to perform
(View/Drop/Replace/Add//delete) a course.
Course code required.
Alternate Flow Course not found: If a course with specified code does not exist, the system
displays an error message. One may enter a different code or cancel the operation. At
this point, the Use case ends.
Post-Condition The system shall view/ add, delete, register, replace, drop, and view course.
27
3.3.1.8 Control Student Activities
Use Case Name Control Student Activities
Introduction Allow s the student to control their various activities. This includes Check
Registration Date, View Transcript.
Actors Student.
Pre-Conditions Student must be logged into the system.
Post-Condition If use case is successful, registration date, and student transcript are viewed from the
system. Otherwise the system state is unchanged.
Basic Flow Starts when wishes Check Registration Date, or View Transcript.
The system requests the Student to specify the function; he/she would like to
perform (Check Registration Date, View Transcript).
Enter student id to check registration date.
Alternate Flow The system displays an error message if date of registration has not reached, or if the
transcript information is unavailable. One cancels the operation. At this point, the
Use case ends.
Post-Condition The system shall display students registration date, and transcript.
3.3.1.9 Manage Lecturer Details
Use Case Name Manage Lecturer Details
Introduction Allow s the lecturer to manage their details. This includes view class list, and enter
grade.
Actors Lecturer.
Pre-Conditions Lecturer must be logged into the system.
Post-Condition If use case is successful, class list is viewed from the system, and the lecturer enters
the grade. Otherwise the system state is unchanged.
Basic Flow Starts when wishes to view class list, and enter grade.
The system requests the lecturer to specify the function; he/she would like to
perform (Enter Grade, View Class List).
Alternate Flow The system displays an error message if class list is unavailable or if the Enter Grade
option is not displayed. The lecturer can cancel the operation. At this point, the Use
case ends.
28
Post-Condition The system shall display the class list, and enter grade.
3.4 Non-Functional Requirements
3.4.1 Performance
The database shall be able to accommodate a minimum of 10,000 records of students.
The software shall support use of multiple users at a time.
3.4.2 Reliability
The system has to operate 99% of the time. The number of defect should not exceed 10 per function.
3.4.3 Availability
The availability of the USIURMS depends on the availability of its servers. Since many critical
applications are running on this server, it is under the control of the system administrators all the time,
who supply the DBMS servers availability, ensuring its backup and recovery issues are dealt with round
the clock.
3.4.4 Security
The system has an authorization mechanism for users to identify their personal profiles. Therefore,
different users will have different authorization levels to access the data. SSL secure connection to web
server and DBMS will be supported. Data integrity for critical variables will also be checked. The system
should utilize certain cryptographic techniques, keep specific log or history data sets, assign certain
functions to different modules, and restrict communications between some areas of the program, check
data integrity for critical variables.
3.4.5 Maintainability
The system can meet the changing requirements easily, since the infrastructure of the system would not
need major changes. The requirements of the software while evolving will be met by just adding new sub-
functions. The maintainability of the system would not be a complex issue.
3.4.6 Portability
All of the code which will be deployed at the web server will be written in PHP 4.0. Now PHP 4.0 scripts
will be on a UNIX server and its possible to move these codes to a Windows environment supporting IIS
or Apache web server with PHP 4.0 and ODBC windows modules installed.
3.4.6 Usability
The system needs to be as simple as possible to use. A logical interface is essential to an easy to use
system, speeding up common tasks. Error prevention is integral to the system and is provided in a number
of formats.
29
3.4.7 Friendliness
The look of the system should be simple and use highly contrasting colors for text.
3.4.8 Privacy
The privacy of all the users of the system should be safe and secured.
3.4.9 Extensibility
The academic plan system should be extended in the future when the amount of students and courses
offered are increased.
3.5 Design Constraints
3.5.1 Standards Compliance
Data Naming: All the terms used in the system should obey academic terminology used in USIU.
