College of Computer Science & Engineering Department of Computer Science

Orientation Students Information System

OSIS
Software Requirements Specifications

Semester 011 Prepared by Majed Al-Sehli, 972049 Mohammad Al-Harbi, 972031 Prepared for Dr. Abdullah Al-Sukairi

Saturday, October 20, 2001

CONTENTS

CONTENTS......................................................................................................................... 1 1. INTRODUCTION ........................................................................................................... 2

1.1 1.2 1.3 1.4 PURPOSE ........................................................................................................................ 2 SCOPE ............................................................................................................................ 2 ABBREVIATIONS............................................................................................................ 2 OVERVIEW .................................................................................................................... 3

2. OVERALL DESCRIPTION............................................................................................ 3
2.1 PRODUCT FUNCTIONS ....................................................................................................... 3 2.1.1 MAINTAIN ATTENDANCE INFORMATION.............................................................. 3 2.1.2 MAINTAIN COURSE AND SECTION INFORMATION................................................ 3 2.1.3 MAINTAIN SCORE INFORMATION ......................................................................... 4 2.1.4 GENERATE REPORTS ............................................................................................ 4 2.2 SAMPLE STORYBOARDS ................................................................................................... 5 2.2.1 MAINTAIN STUDENTS ATTENDANCE ................................................................... 5 2.2.2 SYSTEM ALLOCATING LETTER GRADES .............................................................. 5 2.3 USER CHARACTERISTICS .................................................................................................. 6 2.4 CONSTRAINTS ................................................................................................................... 6

3. SPECIFIC REQUIREMENTS......................................................................................... 6
3.1 FUNCTIONAL REQUIREMENTS .......................................................................................... 6 3.1.1 AUTHORITIES AND AUTHENTICATION ................................................................. 6 3.1.2 STUDENT INFORMATION ...................................................................................... 7 3.1.3 STUDENT ATTENDANCE ....................................................................................... 8 3.1.4 TEACHER INFORMATION ...................................................................................... 9 3.1.5 COURSE INFORMATION ........................................................................................ 9 3.1.6 SECTION INFORMATION...................................................................................... 10 3.1.7 EXAM INFORMATION .......................................................................................... 11 3.1.8 REPORTS ............................................................................................................. 11 3.1.9 HISTORY ............................................................................................................. 12 3.2 NONFUNCTIONAL REQUIREMENTS ................................................................................. 13 3.2.1 DEVELOPMENT PLATFORM ................................................................................ 13 3.2.2 RECOVERY.......................................................................................................... 13 3.2.3 SECURITY ........................................................................................................... 13

1. INTRODUCTION
1.1 Purpose
This document contains the requirement specifications of OSIS (Orientation Students Information System) software package to be developed by Majed Al-Sehli and Mohammad Al-Harbi for the Deanship of Educational Services, Orientation Program (OP). OP is a rapidly developing orientation program in KFUPM. The intended audience of this document is the designers, the Senior Project professor, and the System Coordinator of the OP. The design of OSIS will be based on an approved version of this document.

1.2

Scope
OSIS is to be designed and developed specifically for the OP. It will be used to

keep track of all the personal and academic information managed by the OP. The OSIS has to be capable of maintaining students, courses, and teachers information. Using OSIS, it will be possible for the OP to maintain up-to-date and accurate attendance, exams scores, and letter grades for students, teacher-section assignments, and produce reports about them.

1.3

Abbreviations

Abbreviations used in this document are given below for reference. OP OSIS DN Orientation Program, the customer Orientation Students Information System Denial grade

1.4

Overview
The rest of this SRS document gives an explicit description of the OSIS. It

describes the product environment constraints and lists the functional and nonfunctional requirements of the OP.

2. Overall Description
2.1 Product functions
2.1.1 Maintain Attendance information Each teacher takes attendance of his students and delivers the attendance sheet to the system administrator. The administrator enters the attendance information and saves it using the "section attendance" form in the system. He can modify this information at any time through the same form. If a student presents an official excuse for absence, his absence is changed to excused and the administrator enters the excuse information through a special form in the system. The system adds recorded absence. Every number of lateness or penalties is counted as an absence. This number is decided in the beginning of every semester and saved in the system configuration. 2.1.2 Maintain Course and Section Information The administrator enters the course information, namely, the department, course number, credit hours, number of exams, attendance rules, and semester. This is done through a special course form. Course information can be changed using the same form. The administrator also enters the sections information, namely, the course, section number, time, days, and semester. The administrator assigns teachers to them using the same form.

Another form is used to assign students to sections. This can be modified later using the same forms. 2.1.3 Maintain Score Information The administrator enters the major and final exams scores as soon as he obtains the marks either from the teachers or from the ITC. A special form in the system allows the administrator to enter the information. The form specifies the course, number of exam, student IDs and scores. He can modify this information using the same form at any time. The system calculates averages and totals for each section and course. The administrator enters the cut-off points as the courses coordinators provide them and the system uses them to allocate letter grades to students. 2.1.4 Generate Reports The system generates different kinds of reports. It generates weekly attendance sheets for each section listing enrolled students IDs and names. It also generates reports of students absences for sections and individuals. If a student approaches the maximum

number of absences, which is set by course coordinator, it generates a warning report. If a student exceeds this maximum number of absences, the system generates a DN report. Exams scores are also reported to teachers and students. The user can print any of the mentioned reports using a special report form.

2.2 Sample Storyboards

2.2.1 Maintain Students Attendance

1 Teacher collects attendance data and passes it to the admin. 6 5 Admin. logs into the OSIS and chooses section or student

Insert given attendance data

Generate warning and DN reports 4

System performs calculations

2.2.2 System Allocating Letter Grades

1 Exams scores prepared by teachers or ITC 6 9 7 5 Admin. logs into the OSIS and chooses section or student

2 Insert given exams scores

Generate the letter grades 8

Decide cut-off points for grades 4

System performs calculations

2.3 User characteristics

The users of OSIS are educated people with at least a bachelor degree. Using OSIS does not require any special computer skills because it is required to be a web-based application that can be accessed over a local network using any web browser.

2.4 Constraints
The configuration of the system should not be hard-coded. Future changes in the OP should be easily accommodated. OSIS configuration includes the number of exams for a specific course in a semester, the number of lateness or penalties to be counted as an absence, and the cut-off points and weights for exams.

3. Specific Requirements
3.1 Functional Requirements
3.1.1 Authorities and Authentication The system shall provide different levels of access according to the authority of the user. Namely, there are two different types of users: Administrator: there is only one administrator of the system. He has the authority to add, delete, and edit information. Nevertheless, he shall have all the privileges that other users have. Viewer: viewer users cannot add, delete and edit any data. They can only view and search the database to obtain the needed information.

The system shall provide user authentication by asking for a user name and a password to enforce authority levels and security. A new user can be added to the system only by applying to the administrator. He must be a staff or faculty at KFUPM. When signing in, the system shall check if the user is the administrator or a viewer. If a user forgets his password, the system should send it to his email.

3.1.2 Student Information The system shall maintain students personal information. Namely, student's name, ID number, status, type, father's name, address, phone number, and e-mail. A list of enrolled students is provided at the beginning of each semester. The administrator shall be able to create records for new students and edit any previous records. The administrator and viewer shall be able to view students records for every semester. The system shall maintain a status and a type for each student in every course per semester. The administrator shall be able to change the status and type. For status, a student can be active or expelled with a DN grade. For type, a student can be regular or audit.

3.1.3 Student Attendance The system shall maintain student absence information for each course. The administrator shall enter the absence record as given by teachers for a single student or a whole section. The administrator shall be able to edit absences at any time. If the student provides an official excuse, the absence is not counted. The administrator enters excuse information for later reference. The excuse reason, date, and whether it includes exams or not are recorded.

The system shall add absences for each student and report warnings for excess absences as the administrator specifies for each course. The administrator and viewer shall be able to view absence records for each section or individual student. The system shall maintain student lateness information for each course. The administrator enters the lateness record as given by teachers. The administrator shall be able to edit lateness at any time. The system shall add the number of lateness for each student. If they add up to a number, specified by the course coordinator, then the absence record of the student is incremented by one. The administrator and viewer shall be able to view lateness record for each section or individual student.

The system shall maintain any penalty information for each student. The administrator shall be able to enter a penalty record for a student in a specific lecture, as provided by the teacher. The administrator shall be able to edit a penalty at any time. The system shall add the number of penalties for each student. If they add up to a number, specified by the course coordinator, then the absence record of the student is incremented by one. The administrator and viewer shall be able to view the penalties recorded in each section and for each student.

3.1.4 Teacher Information The system shall maintain teachers' information. This includes teacher's name, ID, phone number, office location, mailbox, and e-mail. The administrator shall be able to add and modify teachers. For each teacher, maintain personal information. For each semester, maintain assigned sections information.
The administrator and viewer shall be able to view teachers' personal information and academic information for each semester.

3.1.5 Course Information The system shall maintain courses information for each semester. Course information includes its name, number, credit hours, and notes.

For each course, specify the following: Number of exams. Number of absences to issue a warning. Number of absences to issue a DN grade. Number of lateness and penalties to be counted as an absence.

For English courses, include the following with their percentage in the total score: Oral exam. Typing and word processing.

3.1.6 Section Information The system shall maintain all information regarding sections for every course in a semester. The registrar provides a list of all sections and enrolled students. The administrator shall be able to add and modify a students enrollment record in a section. The administrator shall enter and modify section times. The administrator shall assign a teacher for a section. For each English section, there are four classes and two partner teachers. Each one teaches two classes of his partners section.

10

The administrator and viewer shall be able to view sections students, teachers and times for every semester.

3.1.7 Exam Information The system shall maintain all exams information for each student. number, weight, week in which the exam is to be held, and note. The administrator should enter the number of exams for a course with their weights, as the coordinator of that course decides. Results of multiple-choice exams are given by the ITC as a text file. The administrator shall be able to enter and edit exams marks for each student in every course. The system shall calculate the total marks and averages. The system shall assign letter grades based on cut-off points given by coordinators and entered by the administrator. Namely, exam

3.1.8 Reports The system shall generate reports that can be used by the dean, teachers, and students as needed. For each course, the system should generate the following: Bar chart reports of average scores in exams to be used to decide cut-off points for letter grades. Mean, total and letter grade statistics for each semester.

11

For each section, the system should generate the following: A list of all students, ID and name (attendance sheet). Absence report for a whole section. Exams score by student with overall statistics.

For each student, the system should generate the following: Personal information and academic status. Total number of absences, lateness, penalties, and excused absences in each course for each semester. Warning reports for excess absence in a course. DN-grade notice, when expelled from a course. Exams scores and letter grades.

For each teacher, the system should generate the following: Personal and academic information. List of assigned sections with time and population.

3.1.9 History The system shall maintain all the information for every semester as history, which can be accessed and manipulated in the same manner as described above.

12

3.2 Nonfunctional Requirements

3.2.1 Development Platform The back-end shall run on Windows Server 2000 with SQL Server 2000. The front-end can run on any operating system that can be connected to the OP LAN and is capable of running a web browser. The front-end code shall be implemented using Jscript. Windows and Internet Explorer are recommended. 3.2.2 Recovery No checkpoint, recovery, or restart is proposed. Backups are to be taken regularly and reloading from backups will be done in case of corruption. 3.2.3 Security The system security shall be table-based. User names and passwords are saved in a table in the database managed by the administrator using a special form. Authorized persons on providing a user name and a password can log-on. Password changing capability will be part of OSIS, to enable users to change their passwords. When a user logs on, the OSIS authenticates him, determines his level of authority, then affords privileged features.

13