Escolar Documentos
Profissional Documentos
Cultura Documentos
UNIVERSITY-AFRICA
COURSE TITLE
INFORMATION SYSTEMS
ENGINEERING
COURSE CODE
APP4030
SEMESTER/YEAR
FALL/2013
TASK
ASSIGNMENT #2
(INDIVIDUAL MINI-PROJECT)
PROJECT TITLE
REGISTRARS MANAGEMENT
SYSTEM SPECIFICATION
DOCUMENT
PRESENTED TO
BY
SHADRACK BENARD
KWEINGOTI
ID NO
631448
SUBMITED ON
Contents
Preface ...................................................................................................................................................... 5
1.
Introduction ........................................................................................................................................... 5
Purpose.......................................................................................................................................... 5
1.1
2.
1.2
1.3
References ..................................................................................................................................... 7
1.4
Overview ....................................................................................................................................... 7
2.1
2.1.1
System Interface.................................................................................................................... 7
2.1.2
2.1.3
2.1.4
2.1.5
Communications Interfaces................................................................................................... 9
2.1.6
2.1.7
Operations ............................................................................................................................. 9
2.1.8
2.2
3.
2.2.1
2.2.2
2.2.3
Course Functions..................................................................................................................... 11
2.3
2.4
2.5
2.6
Apportioning of Requirements.................................................................................................... 12
3.2
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:
GPA
DBMS
GB
Gigabyte
HD
Hard Disk
HTTP
HTML
IEEE
IIS
MB
Megabyte
USIURMS
Mbps
ODBC
OS
Operating System
PC
Personal Computer
PHP
RAM
SA
Systems Administrator
RO
Registrars Office
SPS
SSL
TCP/IP
Paperless Office
Course Information:
Refers to information including course code and course name, and course
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 :
Transcript
Information:
User:
1.3 References
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.
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).
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).
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 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 course advisors can display students name, courses taken, courses not yet taken, prerequisite courses, major, concentration, GPA and CGPA.
11
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.
12
13
Process: The administrator activates the function and enters the user id, name, surname, department, email 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.
14
Output: Error or e-mail notification to the user(s) and confirmation message will be displayed.
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 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
18
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.
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.
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 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.
21
Registrar
Mail Notify
Administrator
View Student
Information
View Personal
Information
Login
Course Advisor
Manage Course
Details
Control Student
Activities
Lecturer
Manage Lecturer
Details
22
Student
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
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
Basic Flow
23
information.
The system requests the Registrar to specify the function, he/she would like
to perform (Add/update/delete)
Alternate Flow
One of the sub flows will execute after getting the information.
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
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.
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
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.
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.
This use case allows all the system users to view their personal information and
update it according to their usernames and passwords.
Actors
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.
II.
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.
This use case allows all the course advisor and registrar to view the students
information.
25
Actors
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
Allow Advisor, lecturer, student to maintain course details. This includes view/ add,
delete, register, replace, drop, and view course.
Actors
Pre-Conditions
Registrar, Course Advisor, Lecturer, and Student must be logged onto the system
before this use case begins.
Post-Condition
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.
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
Introduction
Allow s the student to control their various activities. This includes Check
Registration Date, View Transcript.
Actors
Student.
Pre-Conditions
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
The system requests the Student to specify the function; he/she would like to
perform (Check Registration Date, View Transcript).
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
Introduction
Allow s the lecturer to manage their details. This includes view class list, and enter
grade.
Actors
Lecturer.
Pre-Conditions
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
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.
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