Académique Documents
Professionnel Documents
Culture Documents
UNIVERSITY-AFRICA
SEMESTER/YEAR : FALL/2013
TASK : ASSIGNMENT #2
(INDIVIDUAL MINI-PROJECT)
BY : SHADRACK BENARD
KWEINGOTI
ID NO : 631448
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.
5
1.2 Definitions, Acronyms, and Abbreviations
CGPA Cumulative Grade Point Average
GB Gigabyte
HD Hard Disk
MB Megabyte
OS Operating System
PC Personal Computer
SA Systems Administrator
RO Registrar’s Office
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.
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.
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.
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.
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.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).
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:
This user has to have at least Window 7/Linux OS and Internet browsing skills for administrating
USIURMS user profiles.
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.
3. Specific Requirements
Description of Purpose: This file is taken to update USIURMS Students’ grade information.
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.
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.
12
End Messages: None.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Input: student id
Process: With this function, the database is queried for all the personal information of the student.
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.
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.
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.
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.
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.
Input: none
17
Process: When the advisor logon the system, automatically this function is called and all student lists is
displayed.
Input: student id
Process: When this function is called, the database is queried for all the personal information of the
student.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Administrator
View Student
Information
View Personal
Information
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.
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.
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.
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.
26
3.3.1.8 Control Student Activities
27
Post-Condition The system shall display the class list, and enter grade.
…
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.
29