Vous êtes sur la page 1sur 29

UNITED STATES INTERNATIONAL

UNIVERSITY-AFRICA

COURSE TITLE : INFORMATION SYSTEMS


ENGINEERING

COURSE CODE : APP4030

SEMESTER/YEAR : FALL/2013

TASK : ASSIGNMENT #2
(INDIVIDUAL MINI-PROJECT)

PROJECT TITLE : REGISTRAR’S MANAGEMENT


SYSTEM SPECIFICATION
DOCUMENT

PRESENTED TO : DR. G. CHEGE (Ph. D)

BY : SHADRACK BENARD
KWEINGOTI

ID NO : 631448

SUBMITED ON : 30TH OCTOBER, 2013

1
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

2
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

3
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

4
Preface
This document contains the Software Requirements Specification (SRS) Document for the United States
International University Registrar’s Managements System (USIURMS). The main aim is to automate all
the functions of the Registrar’s 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 Registrar’s 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 Registrar’s 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.

5
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 Registrar’s 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

6
instructor.

Record Keeping Refers to courses taken at each semester, course dropping, course adding, course
Process: replacing and personnel record entry processes.

Student Personal Refers to personal records of student.


Information :

Transcript Refers to information containing student name, course codes, course title,
Information: academic status, grade, semester, year, and CGPA.

User: Refers to the USIU’s 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.

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

8
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 registrar’s 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).
 Student’s personal information can be accessed depending on the user’s 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 student’s 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).

9
 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.

10
 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, it’s 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

Registrar’s 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.

11
2.4 General Constraints
The software development team obeys the IEEE standards. Academic rules also have to be observed
throughout the entire requirement’s 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: Registrar’s 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.

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

13
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 user’s 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.

14
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 student’s personal information.

Input: student id

Process: By this function, the database is queried for all the personal information of the student.

15
Output: All students’ personal information form is displayed.

3.2.3.5 Update Student


Introduction: USIURMS shall enable registrar to update selected student’s 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.

16
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

17
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 student’s 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 student’s 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

18
Process: When this function is called, the database will be queried for the student’s courses information
about courses yet to be taken. According to the result, student’s 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 student’s 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.

19
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 student’s 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

20
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 student’s grade to be used by RO.

Input: student’s 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 student’s 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.

21
3.3 Use Cases

3.3.1 Registrar Management System-Use Case Diagram

Registrar Management System


Manage User
Accounts
Maintain Students
Details

Mail Notify Registrar

Administrator

View Student
Information

View Personal
Information

Course Advisor Login

Manage Course
Details

Control Student
Activities
Student

Manage Lecturer
Lecturer Details

22
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

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

24
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 student’s
information.

25
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 student’s
information. Otherwise, the system state is unchanged.
Basic Flow This use case starts when the Course Advisor and Registrar wishes to view the
student’s 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 student’s 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.

26
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 student’s 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.

27
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 server’s 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 it’s 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.

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

29