CHAPTER ONE

1) Introduction
As there are many problems face human being throughout his/her life, it is obvious to solve these
problems using computers. This problem solving process using computer requires knowing
computer application, ability to develop software, having concept of program and applying
modern technology to solve problem.

The project we have prepared Haramaya University Online Student Registration System
(HUOSRS) is also aimed to solve some problems occurred in the Haramaya university registrar
office. The office perform students registration manually which has some short comes such as
consuming time, resource and requires much employers power. So, to reduce these short comes
we have proposed a project Student Online registration. After the automation of this system both
students and office are beneficial.

The project includes background of the registrar and also the systems performed in the office are
described. In addition to these conditions like the problems in the office, objective of the project,
scope of the project, proposed system, system design and detailed design studies are clearly
specified.

Finally, the tools and techniques we use and the schedule is summarized as much as possible to
finish the project in the given time by using our own methodologies.

1|Page
 1.1) Background

Office of registrar of Haramaya University was established for performing basic activities being
carried out in the university. Among these activities registering students, keeping students’ files,
marks and assigning department for fresh students are the major kind of activities related with
the student registration. While doing these activities they depend on rule and regulation adopted
by the campus. Office of Registrar was founded as the Campus established with the help of
Oklahoma State University (OSU), accepting its first students in 1954, and the new campus was
opened in January 1958 by Emperor Haile Selassie. For many years the office had been limited
to register students of agriculture department, but in 1996 while the university was given
permission to open other faculties and departments, the registrar also increases its registration
scope to the opened departments.

The office is an independent, non political and fully secular which is formed and governed by the
university. The primary objective of the office is to work for the academic education. There are
different workers, employers and professionals with their specific job who take part in this office
activity.

All these workers are aimed to serve students in different services. Among these services the
major once are:-

Registering students for courses

Enabling students to use add and drop forms
Correcting grade errors and CGPA
Enabling fresh students to select their department
Posting information

These activities are being performed in manual process. So, those huge activities will consume
much more resources and times. Indeed this situation is the case for the raise of students online
registration system to solve those problem.
 1.2) Problem Definitions

As starting point for problem definition we try to identify how registration of students was being
carried out and we get some information about the system from the registrar office. From our
observation of the student registration process we have collected data and identified the
following problems.

Lack of online registration system

The office consumes manpower, time and resources because of manual service of
student registration system.
students also consume time and resources for registration
Lack of organized data for screening student’s service documents and relevant
information.
Inaccuracy of information (loss of data)
Reports are not processed on time.
Redundant flow of student information.

1.3) Objective of the project

1.3.1) General objectives

The general objective of the project is changing manual registration process to

automated way of registration.

1.3.2) Specific Objectives:-

In addition to the general objective of the project it will also contains the following specific
Objective. These are:-

Assigning department and registering for fresh students

Enabling students to view their grade and CGPA secretly.
Enabling all department heads to send students mark to registrar.
Accelerating user requirement and benefits.
Supplies timely information for the students.
Minimizing data redundancy.
Minimizing loose of data.
Secured means of storing files.
Improved planning and management.
 1.4) Scope the project

When we say scope it is about the size of the project and how much works it contains. So, the
scope of online student registration of Haramaya University focuses on registering all students of
the main campus, Harar campus and Chiro campus. In general speaking, the scope of the project
is specific to the main and its sub campuses.

In addition to this scope can be defined as the sum of the products, services, and results provided
from the project. So, the project is capable of performing the following scenario. These are:-

Assigning department and registering for fresh students

Enabling students to view their grade and CGPA secretly.
Enabling all department heads to send students mark to registrar.
Adding, Updating and searching student information
Generating necessary information.

Data Collection

Before implementation and design requirement analysis is the first step. So, this data collection
method is a precondition for requirement analysis. Knowing this fact we have collected
information from the existing system and used it for proposed system. There are many methods
used to collect data. Among them we have used two methods:

1. Interview
2. Observation
Interview:

We have used this method to gather information by asking the head and employers of the
registrar some basic questions.

Some questions that we asked the registrar are:

How registration process is going on?

During registration time what are there any problems? If there are what are they?
What requirements are needed for the process?
Observation:

This is by observing:

Written documents and procedural manuals

Registration form,
Add and drop form
Withdrawal form
Grade recording mechanism and
Other activities.
 Benefit of the project

For user:-

To get timely information.

To save their time and money.
To access accurate and fast information
For HUR office:-

To easily retrieve user information.

To improve management system.
To solve problem of manual work.
To save time and money and manpower
For developers

Requirement for the partial fulfillment of the Bachelor degree in computer science.
To be familiar on solving real life problems.
To expand knowledge gained from lessons.
 CHAPTER TWO
2) Proposed System
After observing and identifying the current (existing) system, it is mandatory to develop
proposed system. This proposed system should solve the problem of the existing system and
must be advanced. So, the key solution to avoid all the problems mentioned previously is to find
a unified way to solve the problems mentioned earlier. The only unified way is by
computerization. The various entities that interact with the system are identified. In addition to
this, the work flows, functional, non-functional requirement, activities performed by man and by
machine and procedure within the system are being examined to understand and visualize the
system.
2.1) Functional Requirements

These requirements describe the interactions between the system and its environment
independent of its implementation. The environment includes the user and any other external
system with which the system interacts.

This requirement document is prepared with some balance of scope, time, cost and quality
considerations. Operations of the system, which can be realized under the time and resource
limits, are included in the requirements document.
Functional requirements that must be included in the system are listed below:
A. User requirement
The users interface language is English.
Personal Computer with both a standard keyboard and a mouse are required.
The user interface consists of menus and navigations that can be dictated by
user’s responses.
B. Hardware Requirement
The other part of the external interface is hardware interface, this interface describe the hardware
part of the system. So the system needs:-
Computer
Printer
Network cables
Hub (16 port or more)
512 or more MB RAM
Additionally it also needs the use of a computer equipped with a mouse and a standard keyboard.
A monitor with not less than 800 x 600 resolutions and with 256 color capability.
C. Software Requirement
The product requires:-
1) Browsers such as:-
Mozilla fire fox
Google chrome
Opera
Internet explorer and others
2) Operating systems such as:-
Windows 7
Window
XP
In general, the functions of the proposed system are:-
Create account and login
Showing student their grade and CGPA
Sending request to registrar for grade and CGPA errors
Filling add, drop and withdrawal forms.
Student registration
Head of departments send grade and grade change request to registrar and receive
CGPA from.
Placement: - enables students to select department and then register.
Report for students, Head of departments and registrar
Operations such as add, delete, edit and search for all users according to their
authority.

2.2) Non-functional Requirements

Even though these requirements do not directly affect the performance of the system, they are
important. They are concerned with security, performance, usability, maintainability, reliability,
modifiability, efficiency, portability (across operating systems) testability, understandability. The
non functional requirements of the system are presented below:

A. Security requirements

The system must be secured and protected by only the office of registrar. Every user of the
system is not allowed to access data or modify all files in the database without having correct
username, password and their security key. Each member can manipulate the necessary operation
that allowed for them on the database.
In addition to these, since the system runs on the internet environment, there are a lot of security
treat on the system. Therefore, the system should be secure from the malicious and hackers by
developing security key.
B. Performance requirements

The software performs different operations when data types are numeric, text, date and time.
And it also gives an error messages when an authorized person tries to perform some operation
without entering inputs.

C. Maintainability

The system shall be distributed with independent modules or classes for the databases. This
independency bring to easily testability, maintainability, flexibility and easy to use.

In general after the system has been produced, change or improvement may be needed. This
could happen because user need, change of the office plan and need of adding function to the
system.

D. Accuracy

Users need an accurate and correct data from the system that they use for the registration
process.

We can easily imagine the consequences of any decision that made inaccurate and incorrect data
on their basis. We expect to address this major issue through implementing a number of validity
checks such as every fields going to be entered in to the data base of the system.

2.3) System models

The system model is composed of three individual models: -

1) Functional model: represented by use case and Scenario

2) System object model: represented by classes and objects diagrams and
3) Dynamic model: represented by state chart and sequence diagram.

In this section we try to analyze the overall activity of the proposed system by using use
case description, use case diagram, sequences diagrams, activity diagrams and class
diagram scenarios.
 2.3.1) Use cases and Actors
2.3.1.1) Use Cases
Essential use cases that the proposed system consists are:-

1) Login
2) Registration
3) Registration slip
4) Placement
5) Exam result
6) Send grade
7) Grade error
8) Application form
9) Registration report
10) Download course
11) Upload files
12) Update news

2.3.1.2) Actors
The proposed system consists of three major actors for the accomplishment of the system.
These are:-
1) Students
2) Registrar
3) Department head
 2.3.1.3) Use case Diagram

Figure 2.1 Essential use case of proposed system

 2.3.1.4) Use case and actor description

Login Use Case

Use case name Login

Use case identifier UC#1
Actor(s) Students, department head and registrar
Description Students, department head and registrar want to use the webpage
Precondition Students, department head and registrar should create account
Post condition Students, department head and registrar use the webpage

Basic course of Actions

1. Students, department head and registrar want to use the site
2. They have an account
3. They enter their user name, password and security key
4. Press login button
5. The entered fields are correct
6. They logged into the site
7. Use case ends

Alternate of courses of Action

Alternative course A: 2) If they have no an account
2.1) click create account button
2.2) fill all fields
2.3) get your security key
2.4) go to step 3
 Registration Use Case

Use case name Registration

Use case identifier UC#2
Actor(s) Students
Description Students register for course
Precondition The students have an account and security key to login
Post condition Student registration is success full.
Basic course of Actions

1. Students want to be registered for courses

2. Students login to the page
3. Fill all required field on the page
4. Students previous mark is above or equal to the passing mark
5. Registration is successful
6. Students get registration message
7. Use case ends

Alternate of courses of Action

Alternative course A: 3) If the students do not fill each fields correctly
3.1) Message (fill each field with correct data) will be displayed.
3.2) Use case loops to itself
Alternative course B: 4) If students previous mark is less than passing mark
4.1) Use case ends.
 Registration slip Use Case

Use case name Registration slip

Use case identifier UC#3
Actor(s) Student
Description The registered students want to take registration slip
Precondition The student must be registered
Post condition Both of them get and print registration slip.
Basic course of Actions

1. Students want to get registration slip

2. Student registration is success
3. Print registration slip tag will appear
4. Students click on print button
5. Registration slip is printed
6. Use case ends

Alternate of courses of Action

Alternative course A: 3) If the students registration is not success
3.1) use case ends

Department placement Use Case

Use case name Placement

Use case identifier UC#4
Actor(s) Student and registrar
Description Every students are assigned to their department
Precondition The students should have entrance point
Post condition Every students with entrance point are assigned to their
department
 Basic course of Actions

1. Fresh students want to assign to their department

2. Students fill all their information
3. Students enter their entrance point
4. Student select each department orderly
5. Registrar enter number of students for each of departments
6. The system compare every students’ point and check their first choice
7. Students’ point and first choice is ok
8. Assign students to their department
9. Students click show me department button to see their department
10. Use case ends

Alternate of courses of Action

Alternative course A: 7) If the students’ point and first choice is not ok
7.1) the students’ point and second choice is ok
7.2) go to step 8
Alternative course B: 7.1) If the students’ point and second choice is not ok
7.1.1) the students’ point and third choice is ok
7.1.2) go to step 8
Alternative course C: 7.1.1) If the students’ point and third choice is not ok
7.1.1) assign department randomly
7.1.2) go to step 9
 Exam result Use Case

Use case name Exam result

Use case identifier UC#5
Actor(s) Student
Description Every students are able to see their exam result, grade and CGPA
Precondition The students should have to took exam
Post condition Every students can correct error if any
Basic course of Actions
1. Students want to see their exam result
2. They enter their ID No, course code and security key
3. They click show button
4. The entered values are correct
5. Display their exam result
6. Students print their result
7. Use case ends

Alternate of courses of Action

Alternative course A: 4) If entered values are not correct
4.1) error message will be displayed
4.2) go to step 2
 Grade error Use Case

Use case name Grade error

Use case identifier UC#6
Actor(s) Student and registrar
Description Every student is able to correct their result.
Precondition The students exam result has an error
Post condition Every students get the correct result

Basic course of Actions

1. Students want to correct their grade
2. They enter their ID No, course code and security key
3. The entered values are correct
4. Select course which has error and write their idea
5. They click send error button to registrar
6. Registrar see grade error message
7. Registrar check students result
8. Registrar found error
9. Correct error and update students result
10. Sent error correction message to students
11. Use case ends

Alternate of courses of Action

Alternative course A: 4) If entered values are not correct
4.1) error message will be displayed
4.2) go to step 2
Alternative course B: 7) If registrar not found error
7.1) send no error message to students
7.2) use case ends
 Application form Use Case

Use case name Application form

Use case identifier UC#7
Actor(s) Student
Description Students fill add, drop and withdrawal forms
Precondition The students face some problems
Post condition Students can continue their lesson

Basic course of Actions

1. Students want to fill application form
2. They enter their ID No and security key
3. They click show form button
4. The entered values are correct
5. Application form will be displayed
6. Students fill the application form
7. All application form fields are filled correctly
8. Filling application form is success
9. Use case ends

Alternate of courses of Action

Alternative course A: 4) If entered values are not correct
4.1) error message will be displayed
4.2) go to step 2
Alternative course B: 7) If all application form fields are not filled correctly
7.1) fill all fields error message will be displayed
7.2) go to step 6
 Download courses Use Case

Use case name Download courses

Use case identifier UC#8
Actor(s) Student, department head and registrar
Description Student, department head and registrar download courses that the
student registered for
Precondition The students is registered for courses
Post condition Student, department head and registrar can have the courses on
their hand

Basic course of Actions

1. Student, department head and registrar want to download course
2. Students were registered for courses
3. They enter their ID No and security key
4. They click on download link
5. The entered values are correct
6. They get the downloaded courses and print it
7. Use case ends

Alternate of courses of Action

Alternative course A: 2) If student was not registered for grade
2.1) go to step 7
Alternative course B: 5 ) If entered values are not correct
5.1) error message will be displayed
5.2) go to step 3
 Registration report Use Case

Use case name Registration report

Use case identifier UC#9
Actor(s) department head and registrar
Description department head and registrar able to see report when students
register
Precondition The students is registered for courses
Post condition Department head and registrar can identify who registered, how
many students registered

Basic course of Actions

1. Department head and registrar want to get registration report
2. Students were registered for courses
3. Message was sent to department head and registrar
4. Department head and registrar login
5. They see received message symbol on the message tab
6. They click the tab and see the message
7. Use case ends

Alternate of courses of Action

Alternative course A: 2) If student were not registered
2.1) use case ends
 Send grade Use Case

Use case name Send grade

Use case identifier UC#10
Actor(s) department head and registrar
Description department head send students’ grade to registrar for CGPA
calculation
Precondition Teachers have submit students’ grade to head of department
Post condition Department head and registrar use the calculated students’ CGPA

Basic course of Actions

1. Department head wants to gate students’ CGPA
2. The department head collected students’ grade
3. Department head send student’s grade to registrar
4. The system calculate CGPA
5. The registrar receive message for the calculated CGPA
6. Print the CGPA
7. The registrar sent the grade and CGPA back to department head
8. The department head receive message for the calculated CGPA from registrar
9. Print the CGPA
10. Use case ends

Alternate of courses of Action

Alternative course A: 2) If department head not collected students’ grade
2.1) department head try to collect students’ grade
2.2) go to step 3
 Upload files Use Case

Use case name Upload files

Use case identifier UC#11
Actor(s) Registrar
Description The registrar upload files and information for students and
department head
Precondition Registrar wants to distribute information for students and
department head
Post condition Department head and students read the uploaded and get
information

Basic course of Actions

1. Registrar wants to upload files
2. The registrar logged into the site
3. Select the post information tag
4. Select upload button
5. Write information on the text area
6. Click upload button
7. System upload information
8. Uploaded successfully message will be displayed
9. Use case ends

Alternate of courses of Action

Alternative course A: 2) If not logged into the website
2.1) use case end
 Update news Use Case

Use case name Update news

Use case identifier UC#12
Actor(s) Registrar
Description The registrar update news and post it for users
Precondition Registrar wants to distribute information for students and
department head
Post condition Department head and students read the uploaded and get
information

Basic course of Actions

1. Registrar wants to update news for users
2. The registrar logged into the site
3. Select the post information tag
4. Select update news button
5. Write information on the text area
6. Click update button
7. System update information
8. Uploaded successfully message will be displayed
9. Use case ends

Alternate of courses of Action

Alternative course A: 2) If not logged into the website
2.1) use case end
 2.3.2) Class Diagram

Online Registration System

1 1 1 1

* * * *

User Interface
Account Administratoin Database Management Transaction System
-interfaceType
-account -adminId -transaction
-secured
-dbHandle -dbAccessKey +manageTransaction()
+getInterfaceType()
+isValidAccount() +isValidAccount() +isValidTransaction()
+isSecuredInterface()
+manageAccount() +manageAccount()
+platformSupported() +accessDB() +accessDB() * *

* 1 * *
* *
Login *
Account Execute Order
-username -accountId -userId Cancel Order
-password -accountOwner -order -userId
-securitykey -accountInfo +isValidOrder() -order
+isnewUser() * +login() +updateOrderStatus() +iscancellable()
+isLoggedin() +getAccountInfo() +notifyUser() +cancelOrder()
+forgotPassword() +updateAccount() +notifyUser()
* * * *
*
*
Student Department Head Registrar Office
Interface Component
-fullName -name -name
-ok
-idNo -idNo -idNo
-cancel
-age -position -position
-other
-sex -age -age
+isOk() -classYear -sex -sex
+isCancel() -nationality -phoneNo
+isOther() -phoneNo
-state -email -email
-region -fax
-woreda +login()
* +sendGrade() +login()
-fucalty +getReport()
+prepareSlip()
-depratment +uploadFiles()
+getReport()
-email +updateNews()
-phoneNo +getCourses()
*
+login() +setplacement()
*
+register()
+fillForms() 1
+checkGradeError()

Fig 2.2 Class Diagram

 2.3.3 Sequence Diagram

Student Registrar Registration Subsystem Database

FillApplication

Determine Classification

Open Registration Page

Enter Data
Check Duplication

Validated

Check Old Results

Validated
Calculation Save Data

Confirm Save
Issue Registration Report
Print Report

Fig 2.3 Sequence Diagram for Registration

Student Registrar System Database

Fill Form
Enter Stud No for departments

perform opreration
show students' department

accepted
save student information

Confirm Save
registration report
t
show students' departmen

print

Fig 2.4 Department selection sequence Diagram

 System Database
login
check Account

validate
display grade view page

Id,securitykey & course code

check security

validate

Request search grade

Displaye Grade
Displaye Grade

Print

Fig 2.5 Grade View sequence Diagram

Department Head Registrar System Database

Send Grade
Enter grade & cr.hrs

calculate
Display Result

validated
Save

Confirm Save
Report

Send CGPA

Print

Fig 2.6 Calculate CGPA sequence Diagram

Student Department Registrar System

grade error message

check grade

send corrected
Enter grade
update grade

Updated & saved

update CGPA

Updated & saved

Update Report
Updated Grade & CGPA
Updated Grade & CGPA

Print

Fig 2.7 Grade Error sequence Diagram

2.4 Interface
2.4.1 Form
2.4.1.1 Home page interface

Click on your faculty then on your

department. Then login form will
appear as follows.
 2.4.1.2 Login Form Interface

Fill the login fields and

login to the page
If you have no account Click here
and fill the following create
account field
 2.4.1.3 Create Account Form Interface

Fill all fields and click create button. This will create your account so that you can use the system
with your access control.
 2.4.1.4 Add and Drop Form Interface

This interface enable students to fill add and drop form online. Students fill all their personal
details, course to be added, dropped and click submit button.
 2.4.2 Activity Diagram

Fill Login Form

[Department] [Student] [Registrar]

[No]

[Yes]

Browse Page

Department Student
Send Grade Registrar

Grade Error View Grade

Post Info
CGPA
Check Grade

Correct
Students [Yes]

Fill Placement Fields Forms

[ Yes] [No]
Get thier dept
[No]
Register

Fig 2.8 Activity Diagram

 CHAPTER THREE
SYSTEM DESIGN DOCUMENT (SDD)

3.1) Purpose of the System

Registration office is one among offices of Haramaya University that perform student
registration process for more than 30,000 students.

The registration still uses manual registration system that is difficult to perform the activity in
efficient manner, consumes resources and time of both the registrars and students.

The purpose of this new system (Student Online Registration System) will reengineer the current
system, bringing new technology for the office so that students of the campus can be registered
being online without contacting the registrar and check their point online secretly. These
minimize loss of resource such as transport and time.

3.2) Design Goals

The design goals represent the desired qualities of Student Online Registration System and
provide a consistent set of criteria that must be considered when make design decisions. Based
on the non functional requirements the following design goals will have to be achieved in order
to qualify the system as successful.

1. Dependability criteria:
Robustness: The system has to be robust enough to manage any invalid input
from the users.
Reliability: The system has to perform all operations of the registrar with no
errors.
Security: This is one of the most important nonfunctional requirements for
securing all information and data of the office.
2. Cost Criteria:
Deployment cost: The system has to be easy enough to have a cheap training
cost.
3. Maintenance Criteria:
Extensibility: the system must support that new functionalities can be added.
Modifiability: The system has to be highly modifiable to maintain.
Readability: The system has to be readable to assure its modifiability.
Traceability of Requirements: the code should be easy to be mapped to specific
requirements.

4. End User Criteria:

 Utility: The system has been conceived specifically to support the students and
employers.
Usability: The system will be designed in a user friendly fashion, both for
students and employers of registrar.
3.3) System Design Model
3.3.1) Subsystem Decomposition
During the subsystem decomposition we divide the system into smaller subsystem. Each
subsystem is strongly coherence and loosely coupled.

The system will be decomposed based on the use case and different actors defined in the system.
The decomposition shows the existence of the following subsystems.

User management subsystem

Account management subsystem.
Transaction management subsystem.
Storage subsystem.
Database subsystem.

The database subsystem will be implemented by the relational database management system
(RDMS) used to store the persistent data. The storage subsystem will encapsulate the database,
providing a common interface to the other three high level subsystems.

The following figure shows relationship between subsystem decomposition.

 3.3.2) Hardware /Software Mapping
Student online registration system will be web-based so that students and employers access
through the internet. All functionality will be performed in the main host and will be accessed
through Haramaya University website (www.haramaya.edu.et) by all users.

The system will run on windows 7, windows XP and UNIX operating system. The web server
will run over wamp web server version 2. 0.

The programming language used to develop this product will be PHP version 5.2.6 and some
scripting language such as hyper text markup language (HTML), Java script (JS) and we have
used MYSQL version 5.0.51b as the database management system.

The following diagram illustrates software and hardware mapping of the system.

Fig 2.10 Hardware/Software Mapping

This figure shows relationships between subsystem decomposition with class.

3.3.3) Persistent Data Management

The followings are persistent data objects based on the requirement analysis document.

Person: this is information about all the system users. It can be system administrator and
user.
Account: It is information about the registration accounts. It includes the account holder’s
information.
Transaction: Detail information about database transaction when different students
registered at the same time in the same table

This persistent information will be stored in a relational database management subsystem. We

have selected MYSQL as RDBMS due to its versatility, high performance and integration with
the other products that constitute the new platform.

3.3.4) Access Control

The access control for the system is implemented through the capabilities list. This
representation comes up to be more compact and efficient for the system. A capability associates
a class, operation paired with an actor. A capability allows an actor access to an object of the
class. Denying access is another word for denying capability.
 Registrar Capability List:

Class Operation
createAccount(),
Select Menu updateLogin(),
Login()
Create Login Menu CreateStudentLogin(),
CreateDepartmenttLogin()
Create Student Login Form Create(), Update(), Login()
Create Department Login Form Create(), Update(), Login()
Create Login Report Show(),Print(),Exit()

The above table indicates that Registrar can create account for departments, students and give
them access control.

Students Capability List:

Class Operation
createAccount(),
Select Menu updateLogin(),
Login()
Create Login Report Show(),Print(),Exit()

The above table indicates that Students can create account with the help of registrar, edit their
account and print information

Department Head Capability List:

Class Operation
createAccount(),
Select Menu updateLogin(),
Login()
Create Login Report Show(),Print(),Exit()

The above table indicates that Head of Department can create account with the help of registrar,
edit their account and print information
 3.4) Detailed Design
Introduction

Haramaya University Student Online Registration is a system to be developed to change the

manual system into automated system. The system will be uploaded on a central server to be
accessed by multiple users. It will have user-friendly interfaces to interact with the users easily.
User will type their user name and password on the login form and the system will check the
validity of the user in the database. If a match is found the user will be allowed to access the
system with the privilege level assigned to him/her. If a match is not found in the database the
system will display a message telling the user to re-enter the user name and password or else
service will be denied

3.4.1) Object Design Model

1. Performance criteria

Response time. Refers to the time delay the user wait for accessing the page. It is
mainly depend on the connection type of our internet.

Throughput. Refers to the number of tasks/operations that can be done at a time.

Memory: This is the required memory size, so as to run the application properly. The
proposed system will need minimum of 512MB of Memory for client machines and 1
GB for server. And internet connection is the first step of processing. Offline users
don’t have the opportunity to use the site.
2. Durability versus platform dependence

This software product is designed to platform independent software in order to run meeting
the following hardware specifications.

2 GHz processor speed

256 MB RAM
50 GB hard disk
 3. Dependability criteria

Availability. It refers to the degree to which the system is found doing normal
task. The system works as long as connection is available.

Fault Tolerance- ability to operate under erroneous conditions. The system back
up data to avoid loss of data when system crash or damage.

3.4. 2) Database Design

The overall objective in the development of database technology has been to treat data as an
organizational resource and as an integrated whole. Database Management System allows data to
be protected and organized separately from other resources.

Entity Relation Ship Diagram

CreateAccount
DepartmentSelection
PK IdNo
PK Department
Login
Image
FirstName FirstChoice
PK UserName
LastName SecondChoice
ThirdChoice
Password Email ForthChoice
Security Password FivethChoice
Flag Flag SixthChoice
PasswordRecovery SeventhChoice
FK1 UserName

FreshRegistration

PK,FK2 IdNo

Add and Drop FirstName

SeniorRegistration
PK CourseCode MiddleName
PK IdNo LastName
CourseTitle Sex
FirstName MiddleName LastName Sex Age
Age Nationality Faculty Department year Semister CreditHour
Instractor Region
AccadamicYear Photo CourseCode UserName Zone
AdvisorName
Sign Woreda
HighSchool
AveragePoint9
AveragePoint10
AveragePoint11
AveragePoint12
EnterancePoint
Courses Email
Phone
PK CourseCode Photo
FK1 Department
CourseTitle FK3,FK4 CourseCode
CreditHour
Instractor
FK1,FK2 FK3
AdvisorName
Sign
 3.5) Definitions, Abbreviations, Acronym
3.5.1) Definition

Haramaya University Student Online Registration System: is a system going to proposed in

order to give services for students of the campus and to serve Haramaya Registrar office.
Registrar Office: an office that performs student registration process and related activities.
Students: A customers that enrolled in registration activities.

Department Heads: Are actor plays a great role in student registration by submitting student
grades to registrar.
3.5.2) Abbreviations
CGPA: - Cumulative Grade Point average

GB: - Giga Byte

GHz: - Giga Hertz

HURO: - Haramaya University registrar Office

HUSORS: - Haramaya University Student Union.

HUR: - Haramaya University Registrar

HTML: - Hyper Text Markup Language

JS: - Java Script

MB: - Mega Byte

MySQL: - My Structured Query Language

OSU: - Oklahoma State University

PHP: - Personal Home Page

RAM: - Random Access memory

RDBMS: - Relational Database Management System

UC:-Use Case

UNIX: - Universal Network Information Exchange

Windows XP: - Windows Extreme Programming

3.6) References
1. Internet
http://www.docstoc.com/docs/20179356/BANKING-SYSTEM-SYSTEM-DESIGN-
DOCUMENT
http://www.docstoc.com/search/subsystem-decomposition
http://www.haramaya.edu.et
2. MySQL Cookbook author O'Reilly 1st Edition
3. PHP & MySQL author Vikram Vaswani 2nd Edition
4. Advanced PHP for Web Professionals Christopher Cosentino
5. CSS Pocket Reference author O’Reilly 2nd Edition