ENDATITEFA

CEP FILE MANAGEMENT SYSTEM CHAPTER ONE
Chapter One
1. Introduction
1.1 Background of the organization
Haramaya University Continuing education program CEP under the College of continuing
and distance education (CCDE) was established 30 years ago. It started with Certificate
and Diploma Programs in the fields of agriculture delivering education at Haramaya University
and Harar center. After few years, a new CEP centre was established at Dire Dawa and Somali
regional state at Jigjiga.
1.2 Overview of the Project

This SRS Document is prepared for Continuing education program under the college of
continuing and distance education of Haramaya University to develop computerized file
management of the CEP. As the time goes by and technology evolves quickly, people manage to
create an easier life in every aspect by manipulating the rapid growth of technology. So we need
to totally change the existing manual system to computerized system. The basic aim of this
project is to solve the current problem of the department. The Currently working system is not
suitable. They have maintained series of book of student data and record information, it is time
consuming and difficult task to maintain a system process data manually. Considering this
problem of the organization our development team has proposed to develop new system that has
great significance for work efficiency of the College. During the time of automating system there
are essentials requirement that are gathered from clients and end user of the project. The SRS
document describes the basic requirements in the project. The basic purpose of this SRS is used
to collect the entire necessary requirement and translate them to written document. Through this
process the end user is describing what is expected from the software and the development team
also understood what the real need of the customer, what is the necessary knowledge available to
develop the system.
This documentation includes the following topics with their detailed information which are
essential for the development of the system in our project.
Department of Software Engineering 1

 Specific requirements
 Software and hardware Requirement
 Functional requirements
 Non-functional requirement
 Software Design
 System decomposition
 User interface design
1.3 Statement of the problem

During requirement gathering we have notice that the college has done everything manually.
They also manage student files manually. It is highly error prone and tedious work for the
employees to handle the data recording process manually. And it’s also time consuming.
Sometimes there is also a situation that the data or file may be lost.
1.4 Purpose of the project

This project development of CEP has the purpose of introducing new system for the existing
manual system. The project is intended to address the problem of the current available manual
system. It is a web-based program aimed to make easier and more convenient the education
process, a hassle through which students go every semester. It attempts to alleviate these hassles
by providing several services to students through the internet.
The purposes of the project are:
 Carefully analyze the existing manual system.

 Identify user requirements and model those requirements.
 Design new continuous education program that can integrate the current and
future needs of CEP department.
 Implement the system with professionals and users.
 Modeling requirement.
 Designing requirement.
 Implementing and testing requirements.

1.5 Objectives of the project
1.5.1 General objective

This project “CEP File Management System” is to design and develop an automated system
which used to automate file management of CEP.
1.5.2 Specific Objectives
 To overcome the problem of manual applying and registration system
 To provide fast approval for appliers
 Automating file management system of the department
 To Reduce promotion cost
 Enables fast data retrieval from the database
 To make the information's available to the department at their desk whenever required in
just a click way
 To have a centralized control over the records of the students and monitor the changes on
these records
 To allow all relevant information about an individual to be retrieved readily to meet the
Department's needs, to facilitate the individuals' rights of access to their own personal
information.
1.6 Outcome of the system

This system is expected is to overcome the problem stated in the statement of the problem and
listed on our scope of the system. The problem is that every activities of the CEP are carried out
manually. Manually done works are highly error prone, time taking, tedious, requires more
employee and data loose. So our system solves these problems of the department by automating
CEPs activities which related to registration and file management. This CEP FMS is a fully
functional web based system which is capable of providing the following major functionalities.
 Notification for applying/registration

 Student registration
 Registration Payment control
 Generating grade report
 Manage student file and record

1.7 Project scope

1.7.1 In scope
This project will be limited on developing a new system student FMS for CEP. On the
completion of this project the system is expected to provide:-
• Accurate way of recording and storing student information into the database.
• Accurate way of accessing and retrieving student information from the database.
• Centralized user friendly and well organized student records.
• Posting apply notification
• Approve apply request
• Notifying approved applicants
• Preparing grade report
• File Repository and Record management system
• Withdrawal
• Readmission
1.7.2 Out scope

The CEP system to be developed won't provide the following functionalities.
 Class scheduling
 Course prerequisite handling
 Add and Drop
 System not handling post graduate student file
1.8 Limitation
 Lack of online student document verification system.
 Language supported is only English.
 Lack of online payment transaction in the country.

1.9 Methodology
1.9.1 Data Source and Data Collection Methods
Different method of data collection is used to gather information from both primary and
secondary source. These are:-
a) Interview: - in this point we ask to the administrator office of continuing education

program.
b) Document Analysis: - To get more information about our project we have used
documents that help us to develop our project. During the analysis of documents, we give
a special consideration to those documents which can bring more features to our system.
1.9.2 System Analysis and Design Methods
Basically this project would follow the method of object oriented programming approach.
Object-oriented programming offers a new and powerful model for writing computer software.
Objects are "black boxes" which send and receive messages. This approach speeds the
development of new programs, and, if properly used, improves the maintenance, reusability, and
modifiability of software.
1.9.3 Testing methodologies

Testing is the integral part of software development. Poor testing methodologies lead to
unstable products and unpredictable development times. It is very essential to have a testing plan
in place to ensure that the product delivered is robust and stable and is delivered in a predictable
timeline. So, we plan to use the following testing methodologies:-
1.9.3.1 Unit testing
This is the most basic testing mechanism at the developer level. This covers very narrow and
well defined scope. We isolate the code from any outside interaction or any dependency on any
module. Then the testing focus on very small unit of functionality. They provide a simple way to
check smallest units of code and prove that units can work perfectly in isolation. However, we
need to check further that when these units are combined they work in a cohesive manner which
leads us to further types of tests.

1.9.3.2 Integration Tests

Integration Test forms the next class of tests at the developer level. They provide a
mechanism to test the interoperation of smaller units. So we are going to use these testing
methodology to check whether the units are working together to achieve the project goal.
1.9.3.3 Functional Tests

After the integration tests are performed, higher level tests are used. Functional tests check for
the correctness of the output with respect to the input defined in the specification. Not much
emphasis is given on the intermediate values but more focus is given on the final output
delivered.
1.9.4 Development Environment and Programming Tools
Developing this project the team selects the following environment and programming tools
 Microsoft office 2010 used for the documentation part of this project.
 Concerning the development of the database we will use MySQL server integrated in
Wamp server.
 Microsoft Office Visio 2013 and Visual Paradigm for UML 10.2 for modeling and
drawing use case diagram, sequence diagram, class diagram, deployment model and ERD
 Concerning coding we are going to use Notepad++.
1.10 Success criteria of the project

The criteria's that are used to measure the success of the project are the following.

 The proposed system should provide services that were not available on the manual
system.
 The users of the system should be satisfied by the service provided by the proposed
system.
 The amount of time required to search information should be less to work with the new
system.
 The effort or manpower required by the new system should be less than the manual
system.
 The security that the new system provides should be strong enough compared to the
manual system

CEP FILE MANAGEMENT SYSTEM CHAPTER TWO
Chapter Two
2. Software and hardware Requirement
Hardware requirements are:
Processor : Intel Dual core
RAM : 512 MB and above
Hard Disk Utilization : 20 GB and above
Input Devices : Mouse, Keyboard, scanner etc
Output Devices : Monitor, Color Printer, etc
Software requirements are:
Operating System : Any windows version
Front end : PHP 5.3
Back end : MySQL 5.5 integrated in wamp server
Browsers : internet explorer, Mozilla Firefox, Google chrome etc.
Server : Wamp serve

CEP FILE MANAGEMENT SYSTEM CHAPTER THREE
Chapter Three
3. Software requirement and analysis
3.1 Existing system
3.1.1 Overview of the existing system
Haramaya University CEP under the College of continuing and distance education (CCDE)
was established 30 years ago. It started with Certificate and Diploma Programs in the fields of
agriculture delivering education at Haramaya University and Harar centre. After few years, a
new CEP center was established at Dire Dawa and Somali regional state at Jigjiga. The
department gives education service for the students at these sectors. First the students apply to
register by coming personally to one of the specified sectors. Then the department has its own
criteria to approve the student’s application. The center employee/supervisor checks the
registration form filled by the student weather it satisfies the criteria or not. If the student
satisfies these criteria’s he/she will be approved to be registered. Then after the approval, the
student will pay the payment for the courses that he/she will take. Then the student will be
registered and start the class by the schedule posted by the department. The department handles
this information manually. And the file management system is paper based. So, the information
recording or filling and retrieval system is too tedious, error prone, and also time taking.
3.1.2 Problem of the existing system

As we mentioned in the introduction part of this document CEP manage its activities in paper
based basis or manually. Because of this we have find the following problem which described
below.
 There is a searching problems. Since there are so many files of students found in the
record room, searching for student file is time consuming for the record employee. So
that, quickly identifying student file is very difficult. This leads to elongation of the
overall working processes.

 There is control and security problem. Due to little security control an authorized workers
are capable to access student information.
 The use of several forms and copies in the record keeping will incur additional material
cost.
 Very tedious and time consuming advertisement and promotion about the department,
application date and registration date.
 Student's waste time and money by traveling back and forth for application and
registration process since application and registration time is different.
 It is tedious to manage historical data of students which needs much space to keep all the
information regarding the students.
 Since the files or records are stored on a cabinet (shelf) data's are prone for damage and
loose.
 Tasks are vulnerable for mistakes because they are performed by human beings. As a
result works done may not accurate.
 Due to the above problems time needed for work completion is very long.
Taking the above problems into consideration our system is proposed to solve student file
management problems including the registration process since the problem are related to student
file.
3.1.3 Strength and weakness of the existing system
3.1.3.1 Strength
The CEP staff and head trying all their best to keep student file in safe and arrange in the way
they can easily find student record. This is the strong side of the department.
3.1.3.2 Weakness
However, since the students are too many and need more space to store student file
manually. Hence it need many man power and resource supply.
On searching of file as the student file is recorded and stored manually, it needs much
time to search individual file of a student.

3.1.4 Business rule of the existing system

This describes the working rules being followed by the CEP department in the existing
manual system.
Application and admission rules
Without any prejudice to directives given by the ministry of Education, eligible applicants to the
continuing program of HU fall into the following categories.
1. Preparatory Education completes

1.1 To join CEP, must applicants have ESLCE result of 2.0 and above either 10 ro12 grades.
1.2 Applicants who have successfully complete ten-plus-two (10+2) preparatory school
education can apply to the continuing education program.
1.3 Applicants must provide original documents and their required number of photo copies
which the office may require.
1.4 Applicants must pass both the university and grade 12 entrance examination set by the
ministry of education.
1.5 During application, applicants must bring two passport sized photographs.
1.6 Applicants may attach any accredited document he/she may think useful for his/her
competition.
1.7 Applicants must pay application fee which is not refundable incase the department the
student apply to may not opened due to justifiable reasons
2. Upgrading applicants
2.1. Applicants who have ESLCE result of 2.0 and above either 10 ro12 grades can apply.
2.2. Applicants with diploma (12+2 or 10+3) and cumulative grade point average (CGPA) of
2.00 up on graduation from an accredited higher learning institution of similar program
are encouraged to apply.
2.3. Technical and vocational education and training graduates with pertinent qualifications
and who satisfy entrance qualification assessment set by the ministry of education can be
admitted.
2.4. Center of Competence (COC) is mandatory for all applicants having a diploma.
2.5. In case the department is willing to give entrance examination for the applicants, the
applicants must successfully pass the examination.

2.6. The applicants must provide the entire necessary document the institution may require
(ESLCE, Transcripts, Diploma or its equivalent and any other the student thinks is
relevant for competition).
2.7. Applicants is only at nearby centers, but not at the office of the CEP, unless application
for sponsorship.
2.8. Workers, who are engaging in the CEP program of the university, cannot apply to CEP,
until only they are working under the program.
2.9. Workers who are engaging under distance and summer education program can apply to
the education program.
2.10. All applicants must apply within the time period of the application days set by the
office of the CEP.
2.11. All applicants must complete the application form carefully. The office of CEP is not
responsible for incorrectly filled forms.
2.12. The application process is facilitated by the center coordinators until to the screening
process is accomplished and list of accepted applicants are posted.
2.13. Application is open for every one who can full fill the required criteria.
2.14. All applicants should sign an agreement to pay tuition and related fees to the
University.
3. Illegal Admission
3.1. Securing or intending to secure admission using forged academic documents and
examination results is illegal.
3.2. Securing admission by posing oneself as a student to the University system after
withdrawal, dropping out or dismissal is illegal.
3.3. The discovery of the above leads to the immediate and automatic dismissal from the
University and liable to other illegal actions.

4. Registration rules
4.1. Registration process should be accomplished with in the period set by the office of the
CEP or according to the calendar of the university.
4.2. Students should be registered in three normal registration days.
4.3. In the failure to complete registration within three normal days three late registrations
with penalty are allowed. The penalty increases from day one to three.
4.4. In the absence of registering within six days is never incorporated by the office the CEP
as well as by the center coordinators.
4.5. A student, who did not accomplish the registration within the six days mentioned above,
is only recommended to withdraw the program.
4.6. Before registration days, the center coordinators must be sure that the registration slips
provided by the office of the continuing education program contains all the necessary
information. Information such as the minimum and maximum credit hours to be offered
for the students, course code within the respective curriculum of the departments,
sameness of courses credit hours within the curriculum, course break down on the basis
of the advancement.
4.7. The center coordinators shall carefully register the students.
4.8. The center coordinators shall immediately submit the registration slip with the lists of
students identified by their respective departments to the secretary of CEP; after listing
down the students who registered for the semester; the secretary of CEP submits to the
database worker of the continuing education program.
4.9. The center coordinator should check the payment made by the students with the credit
ours the student registered for.
4.10. The database shall enter the registration slip into the database within five days.
4.11. The database worker shall submit the registration slip to the record officer of the CEP.

3.2 Proposed system

3.2.1 Overview of the proposed system
The proposed system mainly focuses on solving the problem of managing student file and
student registration, which was carried out manually, by developing a web based application for
CEP. This system enable the CEP to manage the student file management handled easily and
also it makes the retrieval of those file super easy. Even if the main aim of this project is to
develop a computerized system that manage student file and record, it also perform related work
like applying for registration, registration and different user account management in automated
way.
3.2.2 Product perspective

The system which we are going to develop is new for the organization because there is no
existing computerized system for managing student file in the collage. The general diagram that
shows the process of the CEP file management system is:
User CEP FMS Web server
Database
Fig. 1 General Diagram of CEP FMS

3.2.3 Functional requirements

The functionalities that expect from the proposed system are going to be described by
classifying them in four different modules. They are
Student module
This system module describes the functions that can be done by the student
 The student can apply for registration
 Once the student has been registered he/she can create his/her own account by
his/herself
 He/she can send their withdrawal request at the time of different difficulty by
logged in to his/her own account
 Student can view and get their grade report form their page
Registrar module
This system module describes the functions that can be done by the registrar staff
 The registrar staff can handle the different request sent from the student i.e.
approval and rejection
 The registrar staff handle student registration process
 The registrar staff is responsible for generating and giving student ID card
 They are responsible managing student grade related issues.
Finance Module
This system module describes the functions that can be done by the finance staff
 The finance staff is responsible for handling student payment
Administrator module
This system module describes the functions that can be done by the administrator.
 The administrator is responsible for managing users account.

 He/she prepare and give student tempo
3.2.4 Non – Functional Requirements

3.2.4.1 Workability
The system should be Suitable for the all stakeholder of CEP. It should be accurate in
performing its functions and secured enough from attacks by external users. It should be fully
functional in terms of providing all the functions expected it to perform.
3.2.4.2 Reliability
The system should be reliable and matured enough in giving its service. It should have a fault
tolerance mechanism in which it can recover fast from problems that may occur.
3.2.4.3 Usability
The system should be understandable by all users. The interface should be easy to use and it
should have a customary look and feel so that users can easily be familiar with the system. It
should be easy to learn and operate. It should be usable for accomplishing tasks to the client.
3.2.4.4 Efficiency
The system should be efficient and the response time should be minimal. It should be capable
of running on minimum hardware requirements and with the familiar operating systems.
3.2.4.5 Maintainability
The System should be easily maintainable in case of problems and gives consistent service at
all times without fluctuation until there is internet connection and should be testable.
3.2.4.6 Portability
The system should be portable in running on different platforms.
3.2.4.7 Correctness
The system provides correct response to the correct request.
3.2.4.8 Concurrency
The system should support multiple accesses of users. It should give service to multiple users
concurrently.

3.2.4.9 Availability
The system is available for the user whenever there is an internet connection.
3.2.4.10 User Interface

The interface of the system should be user friendly, that is, it should be understandable, usable
and corrective.
3.2.4.11 Security
The system should be secured from external attackers and internal misuse. It should have a
user’s database and should authenticate each user on log in and should grant user specific
services. The confidentiality of the information gathered during requirement analysis and later
phases are kept private and used only for the development of the system internally. This helps to
prevent external parties and unauthorized groups from getting to know and attacking the system.
3.3 Assumptions and Constraints

3.3.1 Assumptions
 We assume that the users have Internet access whenever they want to use the system.
 We assume that departments will prepare and submit course offering before student
registration is started.
 We assume that the students have some knowledge of :
 English language;
 his/her current state: the student needs to know what his ID number and his
password are;
 The CEP website: the student needs to know how to reach the system
3.3.2 Constraints
Some of the constraints during the development of our project
 The time to build our project is not enough to include more functionality to the
system.
 At the time of data gathering employees were not available at their office.
 The complexity and vastness of CEP business idea.

CEP FILE MANAGEMENT SYSTEM CHAPTER FOUR
Chapter Four
4. Software Design
4.1 Use case identification and specification

Table 1. List of CEP FMS Use Cases and their description
No SUC ID SUC Name SUC Description
1 SUC-01 Registration This system process, enable the new student to

Request apply for registration by filling all the necessary
information.
2 SUC-02 Request This system process, helps the registrar staff view
Approval registration request from the student. Then he/she
checks whether the student fulfill the requirement
or not and approve the request.
3 SUC-03 Registration This system process, used for updating payment

payment status of the student after they pay registration fee.
4 SUC-04 Registration This system process helps to register approved and

paid applicants, senior students and readmission
students with withdrawal case or dismissal with
readmission with dismissal with readmission or by
withdrawal case.
5 SUC-05 Generate Id This system process used to prepare student ID

card card.
6 SUC-06 Create student This system process used to create an account for
account the student by himself/herself by using the pass
code and ID number generated during registration.
7 SUC-07 Manage user This system process, enable the system

account administrator to manage all user account of the

system. This is user account creation and deletion.
8 SUC-08 Give Tempo This system processes preparing graduated student

Tempo and giving Tempo for the student on his
request for his Tempo.
9 SUC-09 Insert grade In this system process registrar insert students

grade delivered for each courses to the system.
10 SUC-10 Login In this system process registrar insert students

grade delivered for each courses to the system.
11 SUC-11 Change This use case describes how users can change their
password user password.
12 SUC-12 Grade Report In this business process, the registrar prepares

grade report for every student on the basis of
individual course grade result submitted by the
lectures and student get his/her grade report
through his/her account.
13 SUC-13 Update grade This system process, enable the registrar to update
a student grade for which the student got F for the
previously taken course and modify student grade
report.
14 SUC-14 Withdrawal This system process, enable the student to request

request for withdrawal in the time of different difficulties
by mentioning the reason along with the request.
15 SUC-15 Withdrawal This system process, enable the student to request

approval for withdrawal in the time of different difficulties

by mentioning the reason along with the request.
4.2 Actor identification and specification

Table 2: actor identification and specification
Actor Name Actor role
Student In the system the student can send request both for
registration and withdrawal, can see his/her
semester grade report, create account and change
password.
Registrar Staff The registrar staff will handle student registration

process and file management.
Finance Staff Finance staff handles the student payment process.
System Administrator System administrator is the one who is responsible

to manage system user’s user account and tempo
preparation process.

4.3 Use case
Fig.2 Use case diagram

4.4 Use Case Diagram Description

Table 3: Use case description for Registration request
Use Case ID: SUC-01
Use Case Name: Registration request
Actors: Student
Description: This system process, enable the new student to apply for registration by
filling all the necessary information.
Trigger: When the student wants to apply for registration
Preconditions: The student should be new student
Normal Flow: 1. The user selects “Request for registration” option

2. The System displays application form
3. The user enters all the necessary data on to the form.
4. The user click Submit button
5. System replay success message
6. Use case end
Post conditions: The new student apply for registration
Alternative A3. If all the data is not filled

Flows:
1. System display an error message
2. Return to step 2
3. Use case end

Fig.3 Sequence diagram for Registration request
Table 4: Use case description for Request Approval

Use Case ID: SUC-02
Use Case Name: Request Approval
Actors: Registrar staff
Description: This system process, helps the registrar staff view registration request
from the student. Then he/she checks whether the student fulfill the
requirement or not and approve the request.
Trigger: When there is student request for registration

Preconditions: There should be new student request
Normal Flow: 1. The user selects “Registration Request” option.

2. The System displays the list of students’ request.
3. User enter student full name and view detail button
4. The system display student detail
5. The user check student document
6. User click on approve button
7. System save approved student
8. User send E-mail notification for the student
9. Use case end
Post conditions: The student registration request approved
Alternative A4. If user enter wrong name

Flows:
1. System display error message
2. Use case return to step 2
3. Use case end
A5. if request is not approved
1. System delete student registration request

3. Use case end
Post condition: Request rejected

Fig. 4 Sequence diagram for Request Approval
Table 5: Use case description for Registration payment
Use Case ID: SUC-03
Use Case Name: Registration payment
Actors:  Finance staff
 Student
Description: This system process, used for updating payment status of the student after
the student pay registration fee.
Trigger: When the student wants to pay registration fee
Preconditions: The student must be approved to be registered or promoted to next

semester
Normal Flow: 1. Finance staff select “New student payment” option
2. System prompt the user to enter full name and department
3. User enter the data and click on ok
4. System display semester slip which contain course to be taken and

credit hours for the student with payment amount
5. User click on print button
6. System print the slip
7. Student pay the fee and get semester slip
8. Finance staff click on pay button
9. System update student payment status
10. Use case end
Post conditions: The student payment status updated
Alternative A1. If the student is senior

Flows:
1. Finance staff select “Senior student payment” option
2. System display the list of students that can be registered in that

semester
3. User enter the data and click on ok
4. System display semester slip of the student
5. User click on print button
6. System print the slip

7. Student pay the fee and get clip
8. Finance staff click on pay button
9. System update student payment status
10. Use case end
Fig. 5 Sequence diagram for Registration Payment

Table 6: Use case description for Registration

Use Case ID: SUC-04
Use Case Name: Registration
Actors: Registrar Staff
Description: This system process helps to register approved and paid applicants, senior
students and readmission students with withdrawal case or dismissal with
readmission.
Trigger: When the approved student wants to registration
Preconditions: The student should be approved.
Normal Flow: 1. The user selects “New student registration” option.
2. The System displays a list of paid students.
3. The user enters full name and click "Register" button in the same
page.
4. System automatically gives Id number and passcode to student.
5. System register student data.
6. System display to the user student information, passcode and id

number with email form.
7. The user enters displayed information in email form and click send
email button from the same page.
8. System send email to the student
9. use case end
Post conditions: The student will be registered
Alternative A1. If the student is senior

Flows:

1. the user select “Senior student registration” option
2. system prompt the user to enter academic year and department
3. user fill the data and click on ok button
4. system display list of the students
5. The user check payment status of the student
6. The user inserts the student ID and click on “update” option.
7. The system updates the students status
8. Use case end
A1.1 if the student is readmission with withdrawal or dismissal with

readmission
1. User select “readmission” option

2. System display list of students with readmission status
3. User check student payment status and click on register button
4. System register the student
5. Use case end

Fig. 6 Sequence diagram for Registration

Table 7: Use case description for Generate ID card
Use Case ID: SUC-05
Use Case Name: Generate Id card
Description: This system process used to prepare student ID card.
Trigger: When the student wants his/her Id card.
Preconditions: The student must be registered.
Normal Flow: 1. The registrar staff select “Generate ID Card” option
2. The system display all the registered students in that year
3. The user enter student ID and click on generate ID button
4. The system display student ID card
5. The user click on print button
6. The system prints student ID card
7. Use case end
Post conditions: Student gets his/her ID card.
Alternative A3. If user enters wrong student ID number

Flows:
3. Use case end

Fig. 7 Sequence diagram for Generate ID
Table 8: Use case description for Create Student Account
Use Case ID: SUC-06
Use Case Name: Create student account
Actors: Student
Description: This system process used to create an account for the student by
himself/herself by using the pass code and ID number generated during
registration.
Trigger: When the student want to have his/her own account.

Preconditions: The student must be registered.
Normal Flow: 1. The student click on “create account” button

2. System display the form for creating account
3. Student fill the form including passcode generated during
registration and click on sign up button
4. System verify the information filled by the student
5. System replay account created successfully message and delete
passcode
6. Use case end
Post conditions: Student account created.
Alternative A.1 if the user forget his/her password

Flows:
1. User click on forget password option
2. The system display the form
3. Student fill the form and submit
4. The system display the password
5. Use case end
A.4 if the student fill the wrong information
1. system replay error message
2. Go to step 3
3. use case end

Fig. 8 Sequence diagram for Create student account
Table 9: Use case description for Manage user account

Use Case ID: SUC-07
Use Case Name: Manage user account
Actors: System administrator
Description: This system process, enable the system administrator to manage all user
account of the system. This is user account creation and deletion.
Trigger: When the user want to manage user account.
Preconditions: The student and staff leave the collage
Normal Flow: 1. The user select “manage user account” option
2. User select manage operations
3. User perform the operation
4. System prompt to verify the operation
5. User verify the operation
6. Success message sent to the user from the system
7. End use case
Post conditions: User accounts managed by the administrator
Alternative A.5 if the operation is not successful

Flows:
1. system replay error message
2. use case continue from step three
3. end use case

Fig. 9 Sequence diagram for Manage user account
Table 10: Use case description for Give Tempo
Use Case Id: SUC-08
Use Case Give Tempo

Name:
Use Case This system processes preparing graduated student Tempo and giving Tempo
Description for the student on his request for his Tempo.
Actors: Registrar
Preconditions Student must be graduated.

:

Triggers: Student graduation.
Normal 1. Registrar select tempo option

Flow: 2. System prompting to enter department and year of graduation
3. User enter department and year of graduation
4. System display a list of graduated students with their ID
5. Registrar enter student ID and press generate tempo button
6. System retrieve student file on the tempo page.
7. Registrar press print option.
8. System print student tempo.
9. Use case end
Post Student tempo is generated and printed.
condition:
Alternate A1.If student comes after some time and forgot his ID
Flow:
1. Registrar selects search student option
2. System displays the form to search a student.
3. Registrar insert student full name, year of graduation and department.
4. System retrieve all students basic information and prompt to insert Student
ID
5. Registrar insert student ID and press generate tempo button.
6. System display student tempo.
7. User selects print option.
8. System print tempo.
9. Use case end
Post condition: - Student tempo is generated and printed.
A1.4 If student status is not graduated
1. System displays error message informing to insert valid graduated

student ID.
2. Use case end.

Post condition: - error message generated.
Fig. 10 Sequence diagram for Give Tempo
Table 11: Use case description for Insert Grade
Use Case Id: SUC-09

Use Case Name: Insert grade
Use Case In this system process registrar insert students grade delivered for each
Description courses to the system.
Actors: Registrar
Precondition: Registrar must login.
Triggers:
Normal Flow: 1. Registrar select insert grade option.

2. System displays a form for inserting student grade.
3. Registrar insert the grade for all students into the system.
4. Click save button.
5. System save the data and replay success message
6. Use case end
Post condition: Student grade result inserted and stored.
Alternate Flow:

Fig. 11 Sequence diagram for insert Grade

Table 12: Use case description for Login
Use Case Id: SUC-10
Use Case Name: Login
Use Case This use case describes how a user logs into the CEP System.
Description
Actors:  Student
 Registrar
 Finance
 System Administrator
Preconditions:  Actors must have account.
Triggers: When the actor wishes to log into the CEP System.
Normal Flow: 1. The actor click login menu bar

2. The system display login form
3. The user enter user id and password
4. The system validates the entered information.
5. The system display user page.
6. User logged in to his/her own page
7. use case end
Post condition: If the use case was successful, the actor is now logged into the system. If not, the
system state is unchanged.
Alternate Flow: A4. Entered User Id or password is Invalid
1. The system informed the user an error message

2. go to step 3
3. end use case

Fig. 12 Sequence diagram for Login

Table 13: Use case description for Change Password
Use Case Id: SUC -11
Use Case Change password

Name:
Use Case This use case describes how users can change their user password.
Description
Actors:  Student
 Registrar
 Finance
 System Administrator
Precondition  Actors must have account and logged in to his/her account.
Triggers: When the actor wishes to change his/her user password.
Normal 1. The user select change password menu (option)

Flow: 2. System display change password form
3. The user fill the change password form
4. The user submit the form
5. The system validate the inserted data, save and success
7. use case end
Post If the use case was successful, the actor changes his/her password. If not, the
condition: system state is unchanged.
Alternate A4.If the user insert wrong information

Flow:
2. The continues from step 2
3. end use case

Fig. 13 Sequence diagram for Change password
Table 14: Use case description for Grade report

Use Case ID: SUC-12
Use Case Name: Grade report
Description: This system process, used for preparing student grade report from the
grade submitted by the lecture. Then the student can view its grade report
by logged in to his/her own account.
Trigger: The student wants to get his/her grade report
Preconditions: The lecture have to submit student semester grade report
Normal Flow: 1. Registrar staff select “grade report” option
2. System prompt the user to enter department, academic year and

semester
3. User fill the form and click on ok
4. System display list of students with their id number
5. User enter id and click on prepare grade report
6. System retrieve grade submitted by lectures and prepare grade

report
7. System save grade report and student academic status
8. Use case end
Post conditions: Student get his/her grade report
Alternative A5. If registrar staff enter incorrect id

Flows:
1. System generate error message

3. Use case end
Fig. 14 Sequence diagram for Grade Report
Table 15: Use case description for Update grade

Use Case ID: SUC-13
Use Case Name: Update grade
Actors: Registrar
Description: This system process, enable the registrar to update a student grade for
which the student got F for the previously taken course and modify
student grade report.
Trigger: When the student want to add a course that he/she have F grade
previously
Preconditions: Course must be taken by the student and got new result.
Normal Flow: 1. The registrar select “update grade” option
2. System displays the form prompting to enter student's ID and

course code.
3. Registrar enters students ID and course code and click on submit

button.
4. System display previous course result.
5. Registrar enters the new grade and press change button.
6. System display success message
7. Use case end
Post conditions: Course Grade and grade report is modified.
Alternative Flows:

Fig. 15 Sequence diagram for update grade
Table 16: Use case description for Withdrawal request
Use Case ID: SUC-14
Use Case Name: Withdrawal request
Actors: Student
Description: This system process, enable the student to request for withdrawal in the
time of different difficulties by mentioning the reason along with the
request.
Trigger: When the student want to withdraw.
Preconditions:
Normal Flow: 1. Student select “withdrawal request” option

2. System display the form to be filled
3. User fill the form and click submit button
4. System checks all the fields are filled

5. System save the request

6. System replay success message
7. Use case end
Post conditions: Student sends withdrawal request
Alternative Flows: A4. If the form is not filled completely

3. Use case end
Fig. 16 Sequence diagram for Withdrawal request

Table 17: Use case description for Withdrawal Approval
Use Case ID: SUC-16
Use Case Name: Withdrawal approval
Description: This system process, enable the student to request for withdrawal in the
time of different difficulties by mentioning the reason along with the
request.
Trigger:
Preconditions: Withdrawal request have to be sent from the student
Normal Flow: 1. User select “withdrawal approval” option

2. System display list of student who are asking for
withdrawal with their Id’s
3. User enter student Id and click on view button
4. System display student request details
5. User check the student request and approve
6. System update student status and save its data
7. User send an email notification from the page to the
student
8. Use case end
Post conditions: Student request will be approved
Alternative Flows:

Fig. 17 Sequence diagram for withdrawal approval

4.5 State Transition Diagram

A state transition diagram shows the states of a single object, the events or the messages that
cause a transition from one state to another and the action that result from a state change. It will
not be created for every class in the system. In another word state represents a stage in the
behavior pattern of an object. It have initial and final states. There is a transition from one state
to another and it's triggered by an event that is internal to the object. It depicts the dynamic
behavior of an entity based on its response to events showing how the entity reacts to various
events depending on the current state. It models the life cycle of a single object. It depicts the
different states an object can have, the events that cause the object to change state over time and
the rules govern the objects transition between states. Components of State diagram:
 Start State
 Stop state
State Transition State transition diagrams for CEP FMS is described below
Fig. 18 State transition for login

State transition diagram for Request
Fig. 19 State diagram for Request

State transition diagram for registration
Fig. 20 State diagram of registration

State transition diagram for change password
Fig. 21 State diagram of change password

State transition diagram for create account
Fig. 22 State diagram of create account

State transition diagram for request approval
Fig. 23 State diagram of request approval
4.6 Class diagram

UML Class Diagrams capture the logical structure of a system as a series of classes, their
features and the relationships between them or in other way class diagram shows the existence of
classes and their relationships in the logical view of a system. Class itself represented as a box
with name, attributes, and methods.

Fig. 24 Class diagram for CEP FMS

4.7 Entity Relationship diagram
Fig. 25 Entity relationship diagram for CEP FMS

4.8 Deployment Modeling
A deployment diagram in the Unified Modeling Language models the physical deployment
of artifacts on nodes. To describe a web site, for example, a deployment diagram would show
what hardware components ("nodes") exist (e.g., a web server, an application server, and a
database server), what software components ("artifacts") run on each node (e.g., web application,
database), and how the different pieces are connected
Nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within
the boxes. Nodes may have sub nodes, which appear as nested boxes. A single node in a
deployment diagram may conceptually represent multiple physical nodes, such as a cluster of
database servers.
Fig. 26 Deployment modeling diagram

4.9 System decomposition
CEP FMS
Student Administrator Registrar Staff
Prepare Generate ID
Login Tempo card
Register
Manage Finance Staff
account
Change
Request password Change Prepare
password grade
Delete report
Create account
View Grade
account
Report
Control Payment Approve
Login Request
Withdrawal Registration
Fig. 27 Interface for system decomposition

CEP FILE MANAGEMENT SYSTEM CHAPTER FIVE
Chapter Five
5. Output Screen
The following snap shot show some part of the system prototype of the system that we are
going to develop.
Fig. 28 Interface for home page
This figure shows the home page of CEP FMS. This page is displayed after the user
browse HU website and chooses HU CEP FMS option. In this page, the student can get

information about the department like: - background of the CEP, notice, announcements etc.
using the options on the menu bar the user can perform some operations like: - Login, request for
registration, can see course offerings.
Fig. 29 Interface for request page
This figure shows the request page of CEP FMS. This page is displayed after the user
browse HU CEP FMS and chooses request for registration option. In this page, the new student
can request for registration by filling all the specified criteria and click on submit button.

Fig. 30 Interface for login page
This figure shows the login home page of CEP FMS. This page is displayed after the
user browse HU CEP FMS and chooses login option found on the menu bar of home page. In
this page, the admin, registrar staffs, finance staffs and students after registration can login in to
the system by using their user ID and password. And new student can create his/her account by
using signup option.

Fig. 31 Interface for administrator page
This figure shows the administrator page of CEP FMS. This page is displayed after the
user login. In this page, the administrator can perform operations like: - Managing user account
under this option the administrator can perform activities like creating and deleting accounts,
preparing tempo for the student, change his/her account, and finally Logout.

CEP FILE MANAGEMENT SYSTEM CHAPTER SIX
Chapter Six
6. Conclusion
An effort has been made to study CEP of HU as partial fulfillment of BSc degree in Software
Engineering. In doing the study the team has tried to follow object oriented system analysis and
design methodology.
Since the success and failure of any system depends on gathering the right information
through different fact-finding techniques and user involvements, the team has made the best
effort to gather requirements. After a detail review and study of the existing system of CEP FMS
models have been designed to reflect the new system that is supposed to solve problems.
Designing computerized CEP FMS of HU helps to maintain a computer based student file
management.
In order to solve different problems existed the team has tried to propose a solution that at
least reduce the existed problems and model the proposed system using different tools and
methodologies. We believe that different tools and techniques has helped us a lot in capturing
real user requirements and model the right system for the users for their day to day transactions.
Thus it should have the precedence in know-how and experience in collecting, processing and
utilizing information.

CEP FILE MANAGEMENT SYSTEM CHAPTER SEVEN
Chapter Seven
7. Future enhancement
Nowadays, the world is highly becoming a competitive world. Organizations have to divert
their attention on using the recent technology to be on the first line and competitive. As
described in our document this CEP FMS system has its own limitation. So there are some
enhancements can be made in the future to make the system perfectly functional by solving its
limitation. Some of the enhancements can be made are
 By including online payment system student registration can be completed by the time of
registration.
 Making the system to handle course prerequisite add and drop functionality can be added
to the system.
 Enabling the system to handle registration and FMS of postgraduate students.
 System can be made more user interactive by providing additional language features for
the system.
 Making Class scheduling system to be handled by the system improves system
functionality.

CEP FILE MANAGEMENT SYSTEM CHAPTER NINE
Chapter Eight
8. Acronyms and Definition of Terms
CCDE-College of Continuing and Distance Education
CEP- Continuing Education Program
CEP FMS- Continuing Education Program File Management System
COC- Center of Competence
SRS-Software Requirement Specification
UML- Unified Modeling Language
ERD-Entity Relationship Diagram
RAM- Random Access Memory
PHP-Hypertext Preprocessor
ESLCE-Ethiopian School Leaving Certificate Examination
SUC-System Use Case
ID-Identification
HU-Haramaya University

CEP FILE MANAGEMENT SYSTEM CHAPTER NINE
Chapter Nine
9. Reference
1. Guideline of SRS
2. HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) 4th ed., Modern Systems
Analysis and Design, Benjamin/Cummings, Massachusetts.
3. Software_Engineering_An_Integrated_Approach_By_Pankaj_Jalote
4. WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems
Analysis and Design Methods, Irwin/McGraw-Hill, New York, NY.
5. www.elearning.edu
6. www.ieee.com
7. www.haramaya edu.com
8. www.100projects.com

ENDATITEFA

Uploaded by

Copyright:

Available Formats

ENDATITEFA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ENDATITEFA

Uploaded by

Copyright:

Available Formats

CEP FILE MANAGEMENT SYSTEM CHAPTER ONE

1.1 Background of the organization

1.2 Overview of the Project

Department of Software Engineering 1

1.3 Statement of the problem

1.4 Purpose of the project

The purposes of the project are:

 Carefully analyze the existing manual system.

Department of Software Engineering 2

1.5 Objectives of the project

1.5.1 General objective

1.6 Outcome of the system

 Notification for applying/registration

Department of Software Engineering 3

1.7 Project scope

• Centralized user friendly and well organized student records.

• Posting apply notification

• Approve apply request

• Notifying approved applicants

• Preparing grade report

• File Repository and Record management system

1.7.2 Out scope

Department of Software Engineering 4

1.9.1 Data Source and Data Collection Methods

a) Interview: - in this point we ask to the administrator office of continuing education

1.9.2 System Analysis and Design Methods

1.9.3 Testing methodologies

1.9.3.1 Unit testing

Department of Software Engineering 5

1.9.3.2 Integration Tests

1.9.3.3 Functional Tests

1.9.4 Development Environment and Programming Tools

1.10 Success criteria of the project

Department of Software Engineering 6

Department of Software Engineering 7

Department of Software Engineering 8

3.1 Existing system

3.1.1 Overview of the existing system

3.1.2 Problem of the existing system

Department of Software Engineering 9

3.1.3 Strength and weakness of the existing system

Department of Software Engineering 10

3.1.4 Business rule of the existing system

Application and admission rules

1. Preparatory Education completes

Department of Software Engineering 11

Department of Software Engineering 12

Department of Software Engineering 13

3.2 Proposed system

3.2.2 Product perspective

User CEP FMS Web server

Fig. 1 General Diagram of CEP FMS

Department of Software Engineering 14

3.2.3 Functional requirements

 The student can apply for registration

 The finance staff is responsible for handling student payment

 The administrator is responsible for managing users account.

Department of Software Engineering 15

 He/she prepare and give student tempo

3.2.4 Non – Functional Requirements