Interoduction

Overview

Purpose

1.1. Scope of the Project

The office of registrar has many duties. Hence dealing with automation of service it provides doesn’t go with
the short time that we have. So we limit ourselves to the following areas.
 Student registration
 Student admission
 Student Grade
 Readmission
 Withdrawal/drop out
 Add/drop courses
 Prepare student copy
Our system does not include the following systems
 Student placement
 Class scheduling
 Exam scheduling
 HR management
 Payment/financial management

1.1.1. Description, Definitions and Abbreviation

Description
This is a Student Registration system developed for CPU University College of Ethiopia so that it deals
with many students’ records with their results Hence dealing with automation of service the system
provides Student registration, Student admission, Student Grade, Readmission, Withdrawal/drop out,
Add/drop courses and Prepare student copy

Definitions

 Admission:is processing of application there by selecting and recording applicants.

 Exemption: exempting from taking some courses due various reasons. Some are – physical
disability, course already taken.
 Add/drop: adding a new course during the add/drop schedule and dropping course that has been
register previously with consultation of advisors.
 Withdraw/drop out-student may terminate his/her education formally (withdrawal) or informally
(drop out).
 Readmission: a dismissed, withdraw or dropped out student may be allowed to be readmitted if
she/he fulfills the requirements of department she/he is enrolled in.
 Promotion: after the grades of students have been submitted by instructors and status determined
students will be promoted to the next level of education
  Reports: show the overall number of students taking various cases as criteria in a specified period
of time
 Certification: this category deals with requirements that relate to certifying the students at different
level of his/her education.

Abbreviations
 GPA:-Average grade point.
 CGPA:-cumulative Average grade point.
 CPUORGS:-CPU Online Registration and Grading System

Current system

Propsed system

Over view

1.2. Functional Requirements

 Student’s data process:
 Registration
 Admission
 Add/drop
 Withdraw/drop out
 Readmission
 Grade related information: this category of requirements shall deal with:
 Preparation of grade submission forms for instructors
 Preparation of grade reports.
 Determination of status: Pass warning, probation and dismissal based on the rules and
the regulation of CPU registrar.
 Graduation Process: this requirement shall address the activities performed while students are to
graduate at the end of their stay at the university.
This are:
 Computation of major minor credit hour and grade points for the candidate students.
 Preparing check list of graduation students.
 Preparing degree for graduates.

 Certification process- this category deals with requirements that relate to certifying the students
at different level of his/her education. Some of these requirements are:
 To whom it may concern: for active students as well as for inactive students.
 Student copy (transcript) preparation: for active, inactive as well as graduate students.
 Temporary degree for graduates.
 Forms: This requirement is related to preparation of the various forms that the registrar uses in
its day to day activity. Those forms are:
  Student’s registration form.
 Student admission application form.
 Grade submission form.
 Grade compliant form.
 Grade change form.
 Student’s clearance form.
 Readmission request form.
 Add/drop form.
 Academic Calendar: preparation of flexible academic calendar for various programs.
 Control and checking mechanism: the system should able to prevent and control during its
process when the following list of cases are preparing against academic rules and Regulation of
University.
 Registration beyond the maximum credit
 Prerequisite for adding course
 Readmission acceptance below cut point GPA first dismissal
 Repeating of courses more than twice
 Mixing program other than their own program unless otherwise decided by senate
and academic commission
 Graduation requirement credits
 Graduation approval with having a ”F” grades
 Graduation approval with CGPA less than 2.00 both in cumulative in the major GPA.
 Web based information delivery: the system should deliver the following information to users in
web browser.
 Viewing university structure
 Schools
 Streams
 Departments
 Programs
 Curriculum
 View course offering
 Online registration
 Viewing of student data
 Viewing details of the student’s data for decision making on cases of problematic
students.
 Viewing of lists of students categorized by their status
 Viewing of forms
 Be able to download the various forms necessary in the day to day operations the
university
 View academic calendar
 Providing training to end users and system administrators.
 Providing users guide manual how to work with the system friendly.
 Process of data migration from access (existing) to newly designed system.
1.3. Non-functional Requirements
1.3.1. Availability
The system must be available to the intended users twenty four hours per day.
1.3.2. Data integrity
 Data will be critical to its success as a system.
 Extensive data validation and review will be performed both before data are upload to the
system and as part of upload process
1.3.3. Documentation
In the process of interacting with this system the users and the users of Online Registration System can be
easily access the software using the following documentation types:
 Help desk
 User guides
 Documentation (SRS, system design and architecture).
1.3.4. Hardware and software considerations

Here the requirements can be viewed in two directions the user side and the organizational side
(servers).

 Hardware requirements

The following sub-sections discuss the various aspects of hardware requirements.

Processing power

 x86 architecture
 Intel Pentium CPUs

Memory & Secondary storage

 RAM: 512 MB and above

 250GB Hard-disk: and swap space (if RAM is insufficient).

Peripherals

 CD-ROM drives,
 Network devices, etc.

 Software requirements
Platform

Typical platforms include a computer's

 X86 /64 architecture,

 Operating system: Microsoft Windows 7, windows 10
 Programming languages and their Runtime libraries.
 Web browser
 It supports all browser application.

1.4. User Interface Specification

The developed system provides both desktop application and web application user interfaces that are
compatible with window platforms and browsers. The users or who navigate the other interface of the system
to retrieve the collections of the system is also expected to know basic understanding on how to use it.
 User Interface Identifier Interface 1
User Interface Name Login
User Interface Description Login into Online Registration System home page
Relationship Logs to the system
Steps followed to use the interface
1. Type the ORS URL in address bar of web browser
2. Displays the login page of Online Registration System
3. Login into the system by using valid username and password.
4. The home page is display on the user screen

 User Interface Identifier Interface 2

User Interface Name Home page
User Interface Description it serves as to find Online Registration System home page
Relationship Search services
Steps followed to use the interface
1. Login into the system by using valid username and password.
2. The home page is display on the user screen
3. Search services/ search web
4. Select the service that the user want from the list of services and click on it.
The page selected service is display on the user screen.
1.5. Use Case Diagram and Description
1.5.1. Use Case Diagram

7.2.2. Scenario Design

Scenario 1

Name of use case: create account

Participating instance actor: Registrar officer,
Entry condition:
1. Registrar officer login to the system by using his account.

Flow of events:
1. Registrar Officer Click on the create account link from the ORGS home page.
2. The system displays the create account form.
3. Registrar Officer fill the form and click on generate button.
4. The system generates new user account with username and password.
5. Registrar Officer sends this new username and password to the user.

Alternate Case:
6. If Registrar Officer made error when he fill the form and click the generate button with error, the system displays
an error message and it allows to try again.
7. Registrar Officer clicks on the clear button to clean the text field.

Exit condition: The system saves all necessary users’ information in the user account table.
Special requirement: when he performs this task connection should not be down.
Scenario 2

Name of use case: login

Participating instance actor: Lecturer, Student, School officer, Department, Record worker,
Registrar Officer
Entry condition:
1. The users have valid username and password.
2. The users also have the URL (web site) of Online Registration and Grading System.

Flow of events:
1. The user writes the URL of ORGS in address bar of web browser and press enter key from the keyboard.
2. The system displays the ORGS login page on the user screen.
3. The user clicks on the login button.
4. The system allows the user to enter their username and password.
5. The user fills the username and password and clicks on the sign in button or press enter key from the keyboard.
6. The system displays the ORGS home page.

Alternate Case:
7. If the username and password are invalid, the system displays an error message and allows the user to try again.

8. If the user forgets or wants to change username or password, the system allows to the user to change the
username or password by asking same security questions.

Exit condition: The system saves all necessary information’s of the user’s activity when he/she interacts with
system.
Special requirement: when the user performs this task connection should not be down.
Scenario 3

Name of use case: Register

Participating instance actor: Student
Entry condition: Student logs in to the system using his account.
Flow of events:
1. Student clicks on the Registration link from the ORGS home page.
2. The system displays student registration form.
3. Student fills the form and click on submit button.
4. The system displays successfully registered message

Alternate Case:
5. If the registered record exists in the database, the system displays the student already registered message.
6. If the input data has errors, the system display error message & allow try again

Exit condition: The system saves the record.

Special requirement: when Student performs this task connection should not be down.
Scenario 4

Name of use case: Upload Files

Participating instance actor: Record worker
Entry condition: Record worker logs in to the system using his account.
Flow of events:
1. Record Worker click on the Attach File Button from the ORGS home page.
2. The System displays Upload files form.
3. Record Worker Browse the file in to the form and click on Submit button.
4. The system Upload the File and Displays Successfully upload message.

Alternate Case:
5. If Record Worker made a mistake in the data entry, the system displays error message and allow making
correction.

Exit condition: The file Uploaded successfully

Special requirement: when the Record Worker performs this task connection should not be down.

Scenario 5
Name of use case: add/drop course
Participating instance actor: Student
Entry condition: Student logs in to the system using the account.
Flow of events:
1. Student clicks on add/drop course link from the ORGS home page.
2. The system displays students add/drop course form.
3. Student fills the form properly (to fill total credit text field click on sum button after fill the credit hours of all
courses that are added or dropped or both).
4. Finally Student click on the submit button.
5. The system displays successful submit message.

Alternate Case:
6. If the Student made error when she fill the form and submit with error, the system displays an error message and
it allows to try again.
7. Student clicks on clear button to clean the text field.
8. When the credit hour is over flow or bellows the limit the system displays an error message and not permitted to
add or drop course.
Exit condition: If the submission is successful, the system saves the record data successfully.
Special requirement: when the Student performs this task connection should not be down.
Scenario 6

Name of use case: submit grade

Participating instance actor: Lecturer
Entry condition: Lecturer logs in to the system using his account.
Flow of events:
1. The Lecture clicks on submit grade link from the ORGS home page.
2. The system displays the grade submission form.
3. The Lecture fills the form properly and click on submit button.
4. The system displays successful submit message.

Alternate Case:
5. If The Lecture made error when he fill the form and submit with error, the system displays an error message and
it allows to try again.
6. The Lecture clicks on clear button to clean the text field.

Exit condition: If the submission is successful the system saves the record data successfully.
Special requirement: when The Lecture performs this task connection should not be down.
Scenario 7

Name of use case: prepare academic calendar

Participating instance actor: Registrar officer
Flow of events:
1. Registrar officer clicks on the academic calendar link.
2. The system displays the previous academic year calendar

3. Registrar officer prepares or uploads the current academic year calendar and posts it on that page.
4. The System displays the successful post message.
Alternate Case:
5. If Registrar officer made mistake on the academic calendar, the system allows to delete or modify post.

Exit condition: If the post is successful, the page modified successfully and the system saves that page.
Special requirement: when the he performs this task connection should not be down.
Scenario 8

Name of use case: Modify Account

Participating actor: Registrar officer
Entry condition: Registrar officer logs in to the system using his account.
Flow of events:
1. Registrar officer clicks on modify account link from the home page of the ORGS.
2. Registrar officer clicks on search user account button.
3. The System displays search options (by name, by ID).
4. Registrar officer searches using one search method.
5. The system displays the user’s profile.
6. Registrar officer clicks on the update button to modify account.

Alternate Case:
7. If there is a mistake in the data entry, the system displays error message and it allows to make correction.
Exit condition: The user account is modified successfully.
Special requirement: when the Registrar officer performs this task connection should not be down.
Scenario 9

Name of use case: Prepare grade report

Participating actor: Lecture
Entry condition: Lecture logs in to the system using his account.
Flow of events:
1. Lecture clicks on “prepare grade report” link from the ORGS home page.
2. The System displays the grade report form.
3. Lecture fills the form properly and clicks on generate button.
4. The system generates the grade report.

Alternate Case:
5. If there is a mistake in the data entry, the system displays error message and it allows making correction.

Exit condition: The Grade Prepare successfully.

Scenario 10
Name of use case: View status
Participating actor: Student, Lecturer
Entry condition: The user logs in to the system using their account.
Flow of events:
1. The user clicks on view status link from the ORGS home page.
2. The System displays view status form.
3. The user fills the form properly and clicks on view button.
4. The System displays the user’s status.

Alternate Case:
5. If there is a mistake in the data entry, the system displays error message and it allows to the user to make
correction.

Exit condition: The user views his/her status.

Special requirement: when The User performs this task connection should not be down.
Scenario 11

Name of use case: Inform legislation

Participating actor: Registrar officer
Entry condition: Registrar officer logs in to the system using his account.
Flow of events:
1. Registrar officer clicks on “Rules” link from the ORGS home page.
2. The system displays the previous business rule.
3. Registrar officer prepares or uploads the current business rule and posts it on that page.
4. The System displays the successful post message.

Alternate Case:
5. If there is a mistake in the post (business rule), the system allows to make correction.

Exit condition: If the post is successful, the page modified successfully and the system saves that page.
Special requirement: when Registrar officer performs this task connection should not be down.
 1.1.1. Use Case Description

Description 1

Use case name Submit Grade

Use case number 1
Use case To submit student’s grade in to student database table of the system.
description
Uses
Participating Actor Instructor
Pre-condition The instructor login into the system by using valid username and
password.
The instructor knows the grade submission date.
The instructor work students grade in Excel.
The instructor identifies students that add courses or not.
Flow of events 1. The instructor clicks on my-course link.
2. The system displays all courses that the instructor teaches in the
academic year.
3. The instructor clicks on the submit grade button on the course that the
instructor want to submit grade.
4. The System displays the grade submission form.
5. The instructor fills all the necessary information and upload the grade.
6. System checks the inputs validation.
7. The instructor views the confirm message.
Post condition System saves the inserted grade.
Alternative flow of If the instructor submit incorrect student grade, the system displays
events permission message or activation date.
Description 2

Use case Login

name
Use case 2
number
Use case To login in to the user account.
description
Uses
Participating Student, lecture, School officer, Department officer, Record worker,
Actor Registrar Officer
Pre-condition The users have their valid username and password.
Flow of 1. The system is a login link when users click the link. The link has a
events sign in prompt.
2. The user inserts username and password.
3. The system checks the username and password whether it is valid or not.
4. The system allows the user to login into the system.
5. If the user insert invalid username and password, the system display
an error message and allows trying again.
Post condition The user successfully login into the system.
Alternative If the user forget or want to change username or password the system
flow of events allows them to change the username or password.
Description 3

use case name Attach Files

use case number 3
use case description To Upload any file of the College.
Uses
Participating Actor Record worker
Pre-condition Record worker login in the system.
Flow of events 1. Record worker clicks on “prepare student copy” link
from ORGS home page.
2. The System displays the form.
3. Record worker fills the form properly and clicks on generate
button.
4. The system displays the student copy.
Post condition The system display successful preparation message.
Alternative flow of If there is a mistake in the data entry the system displays error
events message and it allows to make correction.
Description 4
use case name Prepare grade report
use case number 5
use case description To prepare student grade report.
Uses
Participating Actor Lecture
Pre-condition Lecture login into system.
Flow of events 1. Lecture clicks on “prepare grade report” link from the ORGS
home page.
2. The System displays the grade report form.
3. Lecture fills the form properly and clicks on generate button.
4. The system generates the grade report.
Post condition The system display successful message.
Alternative flow of If there is a mistake in the data entry the system displays error
events message and it allows making correction.
Description 5
Use case name Add/Drop course
Use case number 6
Use case description Students to add/drop courses in to the student database table.
Uses check for prerequisites
Participating Actor Students
Pre-condition Students login in to the system.
Flow of events 1. Student clicks on add/drop course link from the ORGS home
page.
2. The system displays students add/drop course form.
3. Student fills the form properly (to fill total credit text field
click on sum button after fill the credit hours of all
courses that are added or dropped or both).
4. Finally she click on the submit button.
Post condition The system displays successful submit message.
Alternative flow of events If Student made error when fill the form and submit with
error, the system displays an error message and it allows to
try again.
Description 6
Us use case name create account
Us use case number 7
Us use case description To create new account to the user
Us uses
Pa Participating Actor Registrar officer
Pre-condition Registrar officer login in to the system.
Registrar officer has full information about authorized user
(full name, id, e-mail).
Flow of events 1. Registrar officer click on the create account button.
2. The system displays the create account form.
3. Registrar officer fills the form and click on signup button.
4. The system generates new user account with username
and password.
5. Registrar officer sends this new username and password to the
user by using their e-mail address.
Post condition The system display successful message.
Alt Alternative flow of If the message or username and password don’t reach to
events the user or get problem by any means, the system allows to
checks and solves the problem of that username and
password.
Description 7
use case name Prepare academic calendar
use case number 9
use case description To prepare Academic Calender students.
Uses
Participating Actor Registrar officer
Pre-condition Registrar officer login to system from the home page of the
ORGS.
Flow of events 1. Registrar officer clicks on the “academic calendar” link from
the home page of the ORGS.
2. The system displays the previous academic year calendar.
3. Registrar officer prepares or uploads the current academic
year calendar and posts it on that page.
Post condition The System displays the successful post message.
Alternative flow of events If registrar officer made mistake the system allows deleting
or modifying post.
Description 8
use case name View status
use case number 11
use case description Students look Grade information.
Uses
Participating Actor Students
Pre-condition Students login into the system.
Flow of events 1. The user clicks on view status link from the ORGS home
page.
2. The System displays view status form.
3. The user fills the form properly and clicks on view button.
4. The System displays the user’s status.
Post condition
Alternative flow of If there is a mistake in the data entry, the system displays
events error message and it allows to the user to make correction.
Description 9

use case name Register

use case number 13
use case description To register active students.
Uses
Participating Actor Student
Pre-condition Student logs in to the system.
Flow of events 1. Student clicks on the Register button.
2. The system displays student registration form.
3. Student fills registration data and click on Register button.
Post condition The system displays successfully registered message.
Alternative flow of If the input data has errors the system display error message &
events allow to try again
Description 10

use case name Modify account

use case number 14
use case description To modify user account in the system.
Uses
Participating Actor Registrar officer
Pre-condition Registrar officer login into the system.
Flow of events 1. Registrar officer clicks on modify account link from the
home page of the ORGS.
2. Registrar officer clicks on search user account button.
3. The System displays search options (by name, by ID).
4. Registrar officer searches using one search method.
5. The system displays the user’s profile.
6. Registrar officer clicks on the update button to modify
account.
Post condition The system modify successfully.
Alternative flow of If there is a mistake in the data entry the system displays error
events message and it allows making correction.
glossary