ExamScheduling System Documentation

BAHIR DAR UNIVERSITY
BAHIR DAR INSTITUTE OF TECHNOLOGY

FACULITY OF COMPUTING
INFORMATION SYSTEM
PROJECT ON
WEB BASED EXAM SCHEDULINGSYSTEM FOR BIT
SUBMITTED
IN FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF
BACHELOR OF SCIENCE
IN
INFORMATION SYSTEM
BY
Mekuannt Zeleke
Minale Andualem
Yinebeb Admassu
2008 E.C
Bahir Dar Ethiopia
Web Based Exam Scheduling System for BiT 2008E.C
A Project Submitted to faculty of Computing in Bahir Dar University in

Fulfillment of the Requirements for the Degree of Bachelor of Science in
INFORMATION SYSTEM
Advisor: Getinet Mamo
2008 E.C
Bahir Dar, Ethiopia
Declaration
The Project is our own and has not been presented for a degree and/or course project in any other
university and all the sources of material used for the project have been duly acknowledged.
Name and signature of project group members.

Name Signature
1. Mekuannt Zeleke ---------------------------
2. Minale Andualem - --------------------------
3. YinebebAdmassu -----------------------------
Faculty: faculty of Computing

Program: INFROMATION SYSTEM
Project subject: “web based exam scheduling system for BiT”
P a g e i | 82
This is to certify that I have read this project and that in my opinion it is fully adequate, in scope
and quality, as a project for the degree of Bachelor of Science.
Instructor Getinet Mamo.
------------------------------------- ------------------------------
Name of Advisor Signature
Examining committee members signature Date

1. Examiner 1-------------------- ----------------- ----------------
2. Examiner 2-------------------- ----------------- ----------------
It is approved that this project has been written in compliance with the formatting rules laid
down by the faculty of the university.
P a g e ii | 82
ACKNOWLEDGMENT
First and foremost, we would like to thank almighty God that permits us to do and enable
us to be successful in our final year project and to be complete without any problem as his
permission. We also greatly thanks to our advisor Getinet Mamo, who have given timely advice
as well as encouragement to completion of our project and his continuous support in every phase
of this project. Then we would like to thanks instructor of faculty of computing who helps as by
giving information about the project, some of the instructor who helped us in this project are
Prof. Esubalew Alemneh and Dawud Nesru, we want to thanks all of them. Finally, giving great
thanks for our parents who are always with us in all our educational participations and who give
us great attention for our final project success with their financial and idea support.
Group members.
Table Contents page

ACKNOWLEDGMENT .................................................................................................................................... iii
LIST OF SYMBOLS ........................................................................................................................................ vii
P a g e iii | 82
Abstract ...................................................................................................................................................... viii

CHAPTER ONE ............................................................................................................................................... 1
1.1 Introduction ........................................................................................................................................ 1
1.2 Background ......................................................................................................................................... 1
1.2.1 Vision ........................................................................................................................................... 1
1.2.2 Mission ........................................................................................................................................ 1
1.3Existing system study .......................................................................................................................... 2
1.3.1 Problem of existing system ......................................................................................................... 2
1.4 proposed system ................................................................................................................................ 2
1.5Objective of the project ...................................................................................................................... 3
1.5.1 General objective ........................................................................................................................ 3
1.5.2 Specific objective ......................................................................................................................... 3
1.6 Scope of the project ........................................................................................................................... 3
1.7 Methodology and tools ...................................................................................................................... 4
1.7.1 Data gathering methodology ...................................................................................................... 4
1.7.2 Tools used for this project .......................................................................................................... 4
1.8 Significance of the Project ................................................................................................................. 4
1.9 Organization of the project ................................................................................................................ 5
1.10 Definitions and Abbreviations ......................................................................................................... 5
CHAPTER TWO .............................................................................................................................................. 6
SYSTEM FEATURES ........................................................................................................................................ 6
2.1 Introduction ........................................................................................................................................ 6
2.2 Existing System Description ............................................................................................................... 6
2.3 Proposed System Description ............................................................................................................ 6
2.4 Functional Requirements ................................................................................................................... 7
2.4.1 User requirements ...................................................................................................................... 7
2.4.2Interface requirements .............................................................................................................. 13
2.4.3 Software requirements ............................................................................................................. 13
2.4.4Hardware requirements............................................................................................................. 14
2.4. 5 System requirements ............................................................................................................... 14
2.5 Use case diagram.............................................................................................................................. 14
2.5.1 Use case documentation ............................................................................................................... 16
P a g e iv | 82
2.6 Non-functional requirements ......................................................................................................... 27

2.6.1Robustness ................................................................................................................................. 28
2.6.2Availability .................................................................................................................................. 28
2.6.3 Flexibility.................................................................................................................................. 28
2.6.4 Performance .............................................................................................................................. 28
2.6.5 Security ...................................................................................................................................... 28
2.6.6 Usability ..................................................................................................................................... 28
2.6.7 Portability .................................................................................................................................. 29
2.6.8 Efficiency.................................................................................................................................... 29
2.8 ACTIVITY DIAGRAM .......................................................................................................................... 29
2.9 Sequence Diagram............................................................................................................................ 39
CHAPTER THREE .......................................................................................................................................... 48
SYSTEM DESIGN .......................................................................................................................................... 48
3.1 Deployment Diagram ....................................................................................................................... 48
3.2 CLASS DIAGRAM ............................................................................................................................... 48
3.3 User interface diagram ................................................................................................................... 51
3.4 Entity relationship diagram ............................................................................................................. 56
3.4.1Entity description ....................................................................................................................... 57
3.5 Mapping ER diagram ........................................................................................................................ 62
3.6 NORMALIZATION.............................................................................................................................. 64
3.6.1 First normal form ...................................................................................................................... 64
3.6.2 Second normal form .................................................................................................................. 66
3.6.3 Third Normal Form .................................................................................................................... 68
3.7 Algorithm Design .............................................................................................................................. 69
Bibliography ................................................................................................................................................ 72
LIST OF FIGURES page
Figure 1use case diagram............................................................................................................................ 15

Figure 2 activity diagram for login .............................................................................................................. 30
P a g e v | 82
Figure 3 activity diagram for view exam schedule...................................................................................... 31

Figure 4activity diagram for logout. ............................................................................................................ 32
Figure 5 activity diagram for send feedback ............................................................................................... 33
Figure 6 activity diagram for update exam schedule ............................................................................... 34
Figure 7activity diagram for generate exam schedule ............................................................................... 35
Figure 8 activity diagram for delete exam schedule. .................................................................................. 36
Figure 9 activity diagram for create user account. ................................................................................... 37
Figure 10 activity diagram for Reset user password ................................................................................... 38
Figure 11 sequence diagram for login. ....................................................................................................... 39
Figure 12 sequence diagram for view exam schedule ................................................................................ 40
Figure 13 sequence diagram for update exam schedule ............................................................................ 41
Figure 14 sequence diagram for send feedback ......................................................................................... 42
Figure 15 sequence diagram for log out ..................................................................................................... 43
Figure 16 sequence diagram for generate exam schedule ......................................................................... 44
Figure 17 sequence diagram for delete exam schedule ............................................................................. 45
Figure 18 sequence diagram for create users account. .............................................................................. 46
Figure 19 sequence diagram for reset password........................................................................................ 47
Figure 20 deployment diagram ................................................................................................................... 48
Figure 21 Class diagram .............................................................................................................................. 50
Figure 22 user interface for login................................................................................................................ 51
Figure 23 user interface for program manager home page. ...................................................................... 52
Figure 24 user interface for program manager generate exam schedule. ................................................. 52
Figure 25 user interface for program manager update exam schedule . ................................................... 53
Figure 26 user interface for program manager delete exam schedule. ..................................................... 53
Figure 27 user interfaces for system admin create account form. ............................................................. 54
Figure 28 user interface for invigilators view exam schedule . .................................................................. 54
Figure 29 user interface for students view exam schedule. ....................................................................... 55
Figure 30 user interface for student send feedback. .................................................................................. 55
Figure 31 entity relationship. ...................................................................................................................... 56
LIST OF TABLES page

Table 1 use case description for login......................................................................................................... 16
Table 2 use case description for logout. ..................................................................................................... 17
Table 3 Use case description for change username and password. ........................................................... 18
P a g e vi | 82
Table 4 use case description for generate exam schedule. ........................................................................ 19

Table 5 use case description for delete exam schedule. ............................................................................ 20
Table 6 use case description for update exam schedule ............................................................................ 21
Table 7 Use case description for view feedback. ........................................................................................ 22
Table 8 Use case description for View exam schedule ............................................................................... 23
Table 9 use case description for send feedback. ........................................................................................ 24
Table 10 Use case description for create account. ..................................................................................... 25
Table 11 Use case description for Reset user account. .............................................................................. 26
Table 12 Use case description for Reset user password. ............................................................................ 27
Table 13 entity description ......................................................................................................................... 57
LIST OF SYMBOLS
No Symbol Description
P a g e vii | 82
1 Inheritance
3 Class
4 Object
5 Use case, attribute

6 Lifeline
7 Actor
8 Component
9 Device
10 Message
11 final state
12 Initial state
13 Decision
14 Message (return)
15 Note
16 Relation
17 Multivalued attribute
18 Entity
20 Association
1
Abstract
Exam scheduling time table is a complex problem which often has to be solved in
university departments .this is usually done by hand, taking several days or weeks of iterative
P a g e viii | 82
repair after feedback from students complaining that the time table is unfair to them in some
way. We describe an effective solution to these problems involving the use of web based exam
scheduling system.
P a g e ix | 82
CHAPTER ONE
1.1 Introduction
Scheduling problem is not still solved but we analyses this problem and deeply study this
problem and we investigate solutions about exam schedule in web based system in BIT and to
reach the conclusion as complete problem which means that there is no Perfect solution for it,
but there is a nearest solution to perfect solution; because there are many constraints that
should be satisfied.
Bahir Dar institute of technology is one of the campuses of Bahir Dar University. This
campus has its own exam schedule, but it works on manually.this manuall system has several
problems such as students and invigilators can’t access their exam schedule easily. Manual
exam schedule is boring because the number of staff members, students, departments etc.
becomes increasing, so proper management is important by developing web based exam
schedule.
ICT plays crucial role in order to solve such manual exam schedule become automated or
development of web based exam schedule by using ICT infrastructures.
Finally we trying to see the detail exam schedule problems of BiT and we can solve these
problems by developing web based exam scheduling system.
1.2 Background
Bahir Dar institute of technology is one of the campuses of Bahir Dar University. This campus
has its own exam schedule, but it works on manually. This manual schedule has problems such as
students can’t access their exam schedule easily, and proper management is difficult with
regarding to exam schedule.
1.2.1 Vision
The vision of this project is develop web based exam schedule for BiT
1.2.2 Mission
To provide fast, efficient, effective and accurate information to anyone who want exam schedule.
An Online exam schedule where the students and invigilators can view schedule by login to the
system and program manager can manage properly the exam schedule.
P a g e 1 | 82
1.3 Existing system study

The existing system of exam schedule is manual rather it is semi-automated system. There is free
time table (FET) software which support exam scheduling in our campus but they are not used
by all of our campus program manager, because it has problem to generate exam schedule.
1.3.1 Problem of existing system
The use of manual system cause several problems on the activities that are performed in Bahir
Dar Institute of technology for exam schedule. Some of the problems are
 More than one exam can be assigned to the same room at the same time.
 Students and invigilators can’t access their exam schedule easily and it is boring because
the number of invigilators, students, departments etc. becomes increasing.
 Exam scheduling for large modular courses is a complex problem which often has to be
solved in university departments.
 This is usually done` by hand', taking several days or weeks of iterative repair after
feedback from students and invigilators complaining that the exam schedule is unfair to
them in some way, so this project is intended to solve the above problems.
1.4 proposed system

This project is aimed to automate the currently existing system. The proposed system can give
effective and efficient service for those who use the system. Everything that would be executed
manually is changed into automated system. All the problems in the existing system will be get
solution in the proposed system. The proposed system will perform the following activities.
 The proposed system enables the program manager generate exam schedule by
developing web based system.
 The system enables students and invigilators to view exam schedule fast and accurate
through the internet.
 The system enables program manager to update and delete exam schedule fast and
accurate through the internet.
 The system enables program manager to view feedback through the internet.
 The proposed system displays exam schedule and allows students and invigilators to
download it.
 The system enables students and invigilators to send feedback fast and accurate through
the internet.
 The proposed system will have responsive user interface or it runs in different mobile
devices like tablets and smart phones.
P a g e 2 | 82
1.5 Objective of the project

1.5.1 General objective
The general objective of our project is to developing web based exam scheduling system for
Bahir Dar institute of technology.
1.5.2 Specific objective
In addition to the stated general objective of our project has included the following specific
objective
 Perform requirement analysis to identify functional and non-functional requirements of
the system.
 Designing the system using object oriented analysis and design methodology.
 Implement the web application by using Microsoft visual studio 2010 and SQL Server
2012
 Our system deploy in the web application in the internet.
 Test the performance and reliability of the new system
1.6 Scope of the project

The scope of our project is to develop web based exam scheduling system for Bahir Dar
institute of technology .implemented to exam schedule by online system design and
implementing, gathering requirement .Developing web based exam schedule systemfor
students and invigilators in online system by making it more reliable and efficient.
Our system performs the following basic activities.
 Enables program manager to generate the exam schedule.
 Enables student and invigilators send feedback.
 The system enables student and invigilators view the exam schedule.
 The program manager update and delete exam schedule information
P a g e 3 | 82
1.7 Methodology and tools

1.7.1 Data gathering methodology
We have used two types of data gathering methodologies introspection and interview. To
know about the existing exam scheduling system.
1.7.1.1 Introspection
This method has been the primary base for this project. Therefore using the current or
background knowledge of the group, the group is able to identify and list out the common
functionalities and requirements for the project. This helps the group to proceed to the next level.
Furthermore, it had been a bridge or cause for other methodology to conduct them in proper
method.
1.7.1.2 Interview
As we know there are two types of interviewing methodologies which are open and closed, our
group uses open interview methodologies to get information about the existing system.
1.7.2 Tools used for this project
Our system is designed for web based system. So an interactive web based system commonly
needs the following tools.
 Microsoft visual studio 2010
 Web server software:-international information service(IIS) server
 Client side programming language:-HTML5, CSS, JavaScript
 Database system:- SQL database
Other tools we will use for this project are:
 Microsoft Visio 2003:- this software tool is used for designing different architectural
figures, for example, use case diagram, activity diagram, sequence diagram, class
diagram, and the likes.
 Design using c# and screen shooting using sniping tool: - used for editing different
graphical pictures.
 Edrawmax:-this software tools used for designing ER diagram.
1.8 Significance of the Project

 To arrange time period for invigilators, students, to access their exam program on the
web.
 To build web based system that enables the invigilators and students to easily access.
 To minimize the conflict and the unfairness factors ,which are:
 The number of students having simultaneous exams.
P a g e 4 | 82
 The number of students having consecutive exams.

 The number of students having two or more exams on the same day.
1.9 Organization of the project

In these project documents we are discussing system details in each chapter. Before we
begin to write chapter one the document includes acknowledgment, abstract, table contents, list
of figure, and list of tables. The first chapter of this document includes the Introduction part of
the project which includes sub topics like background, existing system study, proposed system,
general objective, and specific objective, significant of the system, scope and methodologies and
tools. The second chapter of the document includes system feature like existing system, proposed
system, functional requirement like user requirement and system requirement and analysis model
like activity diagram, and sequence diagram. The third chapter of this document describes
system design detail such as deployment diagram, architecture diagram like system architecture
diagram and application architecture diagram, user interface design, data structure design such
entity relationship diagram and normalization and algorithm design.
1.10 Definitions and Abbreviations
Deployment diagram: - Deployment diagrams are used to visualize the topology of the physical
components of a system where the software components are deployed.
Use case diagram: - Use-cases are a scenario based technique in the unified modeling language
(UML) which identify the actors in an interaction and which describe the interaction itself. It
contains:
 A set of actors: roles users can play in interacting with the system.
 A set of use cases: each describes a possible kind of interaction between an actor and the
system.
 A number of relationships between Use Cases and Actors.
Class diagram: -visually represent classes and their inheritance relationships.
Sequence diagram: - which show interactions between actors and the system and between
system components.
Data structure design:-visual representation of arrangement of data in a computer memory.
Algorithm design: - description of a sequence of computational steps to solve a problem.
Attribute: - is a variable that is used to describe the class
Method: -That performs tasks and return information when the tasks are completed.
Foreign key: - are attributes contained within a database which uniquely identify another record,
but not the one within which they are contained.
Primary key: - fields that uniquely identify a record.
DB: Database.
FET: free timetable software.
IIS: international information services
P a g e 5 | 82
Sass: system admin social security number

Ssn: program manager social security number
BiT: Bahir dar institute of Technology
UML: Unified Modeling Language.
SFR: student functional requirement.
PFR: program manager functional requirement.
IFR: invigilator functional requirement.
ADFR: system administrator functional requirement.
PFR: program manager functional requirement.
ICT: information communication technology
UC: use case
UI-user interfaces
SD: Sequence diagram.
AD: Activity diagram.
ER: entity relation diagram
PK: primary key
FK: foreign key
CHAPTER TWO
SYSTEM FEATURES
2.1 Introduction
This chapter of the project document provides system features of the project. This chapter
contains and describes about User requirement, Functional requirement, and Non-Functional
requirement, Use case diagram, and use case description, Analysis Model (Activity diagram and
Sequence Diagram).
2.2 Existing System Description

As we have mention in the previous chapter, the existing system has many back side problems
over the proposed system in many ways. Also the existing system is not securely supported
system since it is not automated.
2.3 Proposed System Description

As we have tried to mention in the previous chapter, this project is aimed to automate the
currently existing system. The proposed system can give effective and efficient service for those
who use the system. Everything that would be executed manually is changed into automated
system. The proposed system will used to displays all information about the exam schedule. The
main target of the proposed system is also enables users to see the exam schedule easily. I.e. the
program manager and user can communicate or meet simply on the website. The proposed
P a g e 6 | 82
system has the new features from the existing system like automatic displaying schedule of exam
in online.
2.4 Functional Requirements

In this topic we focus on what the system is do after deployment. Functional requirements
describe the relations between the system and the user. Here the ‘relations’ means the direct or
indirect interactions between the user and the system. Hence the system has the following
stakeholders with different requirements. There are two main types of functional requirements
which are described in this project; they are user requirement and system requirements.
2.4.1 User requirements

User requirements are statements, of what services the system is expected to provide to
system users and the constraints under which it must operate. That describes user goals or tasks
that the users must be able to perform with the system. Therefore describe what the user will be
able to do with the system. We have categorized user requirements in to four parts:-
1. Student: - a person who want to visit exam schedule that are registered in our system.
Registered means a student which have its own account in the system and it have more
access of the system.
2. Invigilator: - a person who use the exam schedule system.
3. Program manager: -a person who use the system to display exam schedule.
4. System administrator: -Is the one which controls the overall activity of the system.
We are using our own requirement writing style to write user requirements of the system; which
have requirement ID (SFR, PFRS, IFR, and ADFR), Description (describes in detail about the
requirement), requirement Source (which describes the source of the requirement), and priority
(which describes priority of requirements as high, medium and low).
Student
Id: - SFR-1
Name: - The system shall allow student to view generated exam schedule.
Description: - when the Student opens the system, all the schedule that is
displayed by program manager.
Source: - real fact
Priority:-High.
P a g e 7 | 82
Id: - SFR-2
Name: - The system shall allow students to send feedback.
Description: -student’s sends any comment, suggestions, or questions to the
program manager by using the system.
Source:-real fact
Priority:-high.
Id: - SFR-3
Name: - The system shall allow students to download exam program templates.
Description:-the program manager posts exam schedule. So students easily
download the exams schedule and use it.
Source:-Introspection.
Priority:-High.
Id: - SFR-4
Name: - The system shall allow students to log in to the system.
Description:-The system checks user authentication.
Source:-real fact.
Priority:-High.
Id: - SFR-5
Name: - The system shall allow students to print exam schedule.
Description:-after the students looks information about a particular schedule,
the system allows the student to print all schedule description or information to
hard paper format.
Priority:-High.
Id: - SFR-6
Name: - The system shall allow student to log out from the system.
Description:-The system checks user authentication and any student is allowed to
logout form the system after login.
Source:-real fact.
Priority:-High.
.
Id: - SFR-7
P a g e 8 | 82
Name: - The system shall allow students to change his/her password.

Description:-if the students want to change his/her password, the system allows
the students to change it.
Source:-real fact.
Priority:-High.
Id: - SFR-8
Name: - The system shall allow students to change his/her username.
Description:-if the student wants to change his/her username, the system allows
the students to change it.
Source:-real fact.
Priority:-High.
Invigilators
Id: - IFR-1
Name: - The system shall allow invigilator to log in to the system.
Description:-invigilators have their own account in the system, for security
purpose the system must verify the user is authorized or not.
Source:-real fact.
Priority: - High.
Id: -IFR-2
Name: - The system shall allow invigilators to send feedback.
Description:-The system allows invigilators to sends any comment, suggestions,
and complains to the program manager by using the system.
Source: - Introspection.
Priority: - medium.
Id: - IFR-3
Name: - The system shall allow the invigilator to download Exam schedule post
by the program manager.
Description:-The system allows invigilators to download Exam schedule which
are post by program manager.
Source:-introspection.
Priority: - medium.
Id: - IFR-4
P a g e 9 | 82
Name: - The system shall allow invigilators to logout from the system.
Description:-The system shall allow all logged invigilator to log out from the
system which is for security purpose.
Source: - real fact.
Priority: - high.
Id: - IFR-5
Name: - The system shall allow Invigilators to change his/her password.
Description:-if the Invigilators want to change his/her password, the system
allows the Invigilator to change it.
Source:-real fact.
Priority:-High.
Id: - IFR-6
Name: - The system shall allow Invigilators to change his/her username.
Description:-if the Invigilators want to change his/her username, the system
allows the Invigilators to change it.
Source:-real fact.
Priority:-high.
Id: - IFR-7
Name: - The system shall allow Invigilators to print exam schedule.
Description:-after the Invigilators looks information about a particular
schedule, the system allows the Invigilators to print all schedule description or
information to hard paper format.
Priority:-High.
Id: - IFR-8
Name: - The system shall allow Invigilators to view generated exam schedule.
Description: - when the Invigilators open the system, all the schedule that is
displayed by program manager.
Source: - real fact
Priority:-High.
Program manager
P a g e 10 | 82
Id: - PFR-1
Name: - The system shall allow the program manager login to the system.
Description:-In order to know the user is authorized or not, the system verifies
program manager username and password.
Source:-real fact.
Priority: - High.
Id: - PFR-2
Name: - The system shall allow the program manager to delete exam schedule.
Description:-The system shall allow the program manager can delete any exam
schedule information that is posted on the system.
Priority: - High.
Id: - PFR-3
Name: - The system shall allow program manager to generate exam schedule.
Description:-program manager can generate exam schedule that is view by
students, and invigilators.
Priority: - High.
Id: - PFR-4
Name: - The system shall allow program manager to view given feedback.
Description:-the system shall allow the program manager to view feedbacks or
complains, suggestions, and comments that are sent from students and
invigilators.
Priority: - High.
Id: - PFR-5
Name: - The system shall allow program manager to log out from the system.
Description:-The system allows the manager to logout from the system when
he/she leaves the system.
Priority: - High.
P a g e 11 | 82
Id: - PFR-6
Name: - The system shall allow program manager to change his/her password.
Description:-if the manager wants to change his/her password, the system allows
the manager to change it.
Source:-real fact.
Priority:-High.
Id: - PFR-7
Name: - The system shall allow program manager to change his/her username.
Description:-if the program manager wants to change his/her username, the
system allows the program manager to change it.
Source:-real fact.
Priority:-High.
System Administrator
Id:-ADFR-1.
Name:-the system shall allow system administrator to create user account.
Description:-system administrator creates user name and password to students, program
managers, and invigilators’ to give authorization.
Priority: - high.
Id:-ADFR-2.
Name: - the system shall allow system administrator to reset user password.
Description: - when the user forget (fail to remember) their user name and password, the
system administrator reset (set again) user password.
Priority: - high.
Id: - ADFR-3.
P a g e 12 | 82
Name: - The system shall allow the system administrator to block students
account.
Description:-The system shall allow administrator to have full access to use the
system and he/she can manage user accounts. If students are not eligible to use the
system, the admin can block his/her account.
Priority: - High.
Id: - ADFR-4
Name: - The system shall allow the system administrator to block invigilators
account.
system and he/she can manage user accounts. If invigilators are not eligible to use
the system, the admin can block his/her account.
Priority: - High.
Id: - ADFR-6.
Name: - The system shall allow the system administrator to block program
manager account.
system and he/she can manage user accounts. If program manager are not eligible
to use the system, the admin can block his/her account.
Priority: - High.
2.4.2Interface requirements
 All the interaction with our system is will occur through web based interface.
 Our system support language English.
 All the navigations and linkage in the system are easy.
 The user interface must have attractive to use and have no complicated components
 The layout of the web interface will conform to a computer or any smart phone screen
size.
2.4.3 Software requirements

 International information service( IIS server)
P a g e 13 | 82
 Operating system: Windows, Linux, IOS, Android, and any smart phone operating
systems.
 Database management system (DBMS): SQL database.
 ASP.NET
2.4.4Hardware requirements
The hardware requirements for this project are described as follows.
The server computer should have RAM more than 4GB and the hard disk should more than or
equal to 100GB. The server must have network connection to access the system.
2.4. 5 System requirements

In order to describe system requirements in detail we use use case diagram. System requirements
are expanded versions of the user requirements that are used by software engineers as the starting
point for the system design. They add detail and explain how the user requirements should be
provided by the system.
2.5 Use case diagram

The system use case diagram shows the overall activities of these system users, it represents the
functions that the actor should perform and this diagram also shows the relationships of actors
that makes them common actors on specific use case. The diagram consists the system area in
order to hold all use cases, which shows the boundaries of the system.
P a g e 14 | 82
Use case diagram for exam schedule
deleteExamSchedule resetPassword
updateExamSchedule createAccount
generateExamSchedul Administrator
blockAccount
program manager
ViewFeedback
changePassword
Login
«extends»
logout
Students
Invigilator sendFeadback
viewExamSchedule
Figure 1use case diagram
P a g e 15 | 82
2.5.1 Use case documentation

This sub topic describes in detail about each use case and actors in the use case diagram, it
includes the name of all use case, description about the use case, the name of the actor who act
on the use case, what precondition before the actor acts on the use case, post condition after the
actor acts on the use case, basic course of action which describes the interaction between the
actor and the system when the actor acts on the use case, and finally alternative course of action.
Use case number UC 01

Use case name Login
Actor Program manager, students , invigilator and system
Administrator
Description Checking the intended user is authorized or not
Precondition The user must have username and password
Post condition The users successfully pass the login and do what they want
to do in the system.
Basic course of action User action System response
1. The user opens the
system 2 .The system displays
the login page.
3. The user enters user
name and password.
4. The system checks the
username and password.
5. The user clicks on
the login button.
6. The system opens the
7. End use case.
users’ home page.
Alternative course of action If the username and password is invalid, the system displays
an error message, then go back to step 3 of basic course of
action.
Table 1use case description for login.
P a g e 16 | 82
UC 02
Use case name Logout
Actor Program manager, students invigilators, and system
Administrator
Description After doing any private activity in the system the user log out
from the system.
Precondition The user should be in private page.
Post condition The user is in public page.
1. The user clicks the
logout button.
2. The system displays the
3. End use case. login page.
Alternative course of action
Table 2 use case description for logout.
P a g e 17 | 82
UC 03
Use case name Change password.
Actor Program manager, students invigilators, and system
Administrator
Description If the users want to change his/her password, the system
allows the user to change it.
Precondition The user must have login to the system
Post condition The user can change his/her password.
1. the users login to the
home page
3. The user clicks the users’ home page.
change password button. 4. The system displays the
change password form.
5. The user fills the form
and click on change button. 6. The system displays changed
successfully message.
7. End use case.
Alternative course of action If the password is invalid, the system displays an error
message, then go back to step 5 of basic course of action.
Table 3 Use case description for change username and password.
Use case No: UC 04

P a g e 18 | 82
Use case Name: Generate exam Schedule

Actor (s): Program manager
Description: System shall allow program manager to generate exam schedule.
Precondition The program manager login to the system.
Post condition The program manager generate exam schedule
Basic course of actionActor Action System Response
1. The program manager login to the
system 2. The system displays the
program manager home page
3. The program manager clicks on
Generate exam schedule link 4. The system displays generate
exam schedule form.
5. The program manager fills the
Form and click on generate button.
6. The system displays the exam
schedule
7. end of use case
Alternative course of If the program manager enters incorrect information or the form is not field
action successfully, the system displays error message and go back to step 5 of
basic course of action.
Table 4 use case description for generate exam schedule.
P a g e 19 | 82
Use case name Delete exam schedule

Actor Program manager
Description The program manager can delete schedule if there is any
inconvenience (difficult) with the students and invigilators.
Precondition The program manager must login to the system.
Post condition The program manager deletes inconvenience information with
users.
1. The program manager
login to the system.
2. The system displays program
manager home page.
clicks on delete schedule 4. The system displays search box
link. form
5.the program manager

search the required 6. The system displays the
information by writing on selected exam schedule, if it is
the search box found.

clicks on delete button. 8. The system displays deleted
successfully message.
9. end use case
If the program manager enters incorrect information to the
search box, the system displays not found message and the
Alternative course of action
system lets the program manager to try again.
Table 5 use case description for delete exam schedule.
P a g e 20 | 82
Use case name Update exam schedule

Actor Program manager
Description The program manager can update exam schedule that is previously
generated by him.
Post condition The program manager posts updated exam schedule to the system.
1. The program manager login
to the system.
program manager home page.
3. The program manager clicks
on update exam schedule link. 4. The system displays the search
box form.
search the required information 6. The system displays the
by writing on the search box selected exam schedule, if it is
found.
7. The program manager clicks
on update button.
8. The system displays updated
successfully message
9. End use case.
Alternative course of action If the program manager enters incorrect information to the search
box, the system displays not found message and the system lets the
program manager to try again.
Table 6 use case description for update exam schedule.
P a g e 21 | 82

Use case name View feedback.
Actor Program manager.
Description The program manager view feedback or suggestions,
complains and comments that are sent from students, and
invigilators.
Post condition The program manager view feedback.

login to the system.
program manager home page.
clicks on view feedback 4. The system displays
link. feedback that is sent from
students and invigilators.
view feedback.
6. End use case.
Table 7Use case description for view feedback.
P a g e 22 | 82

Use case name View exam schedule
Actor Students and invigilators.
Description The user looks all the information Generated by the program
manager in the system.
Precondition The user must have user name and password
Post condition The user access and know the exam schedule.
1. The user login to the

system.
home page.
3. The user click on view
exam schedule link. 4. The system displays available
exam schedule that are posted
5. the user view exam (generated) by the program
schedule manager.
6. End use case.
Table 8 Use case description for View exam schedule
P a g e 23 | 82
Use case name Send feedback

Actor Students and invigilators.
Description The user writes feedback or suggestion about the exam
schedule and sends to the program manager.
Precondition The user must login to users’ home page.
Post condition The user sends feedback to the program manager.
1. The user login to the
system
3. The user clicks on the user’s home page.
feedback link. 4. The system displays the
feedback form.
5. The user fills the
necessary information on
the form and writes
comments, suggestions,
and complains
6. The user clicks on send
feedback button.
7. If the feedback form is filled
successfully the system displays
sent and thanks message.
8. End use case.
Alternative course of action If the user enters incorrect information (formatting like email,
phone) or the form is not field successfully, the system
displays error message and go back to step 5 of basic course
of action.
Table 9 use case description for send feedback.
Use case No: UC 10.
P a g e 24 | 82
Use case Name: Create account.

Actor(s): System Administrator.
Description: The system administrator creates user name and password to
students, program managers, and invigilators’ to give
authorization.
Precondition Users registered to the system.
Post condition Create users account.
Actor System Response
1. The system Administrator login

to the system 2. The system display system
administrator home page.
3.The system administrator click
on create account link 4. The system display creates
account form.
5. System Administrator Fill
create account form.
6. click on submit button 7. The system displays create
successful message.
8. End of use case.
Alternative course of action If the system administrator fills incorrect information, the system
displays error message, and go back to step 5 of basic course of
action.
Table 10 Use case description for create account.
P a g e 25 | 82
Use case No: UC 11.

Use case Name: Reset password.
Actor(s): System Administrator.
Description: System Administrator to backup system for catastrophic failure
occurs within the system.
Precondition Users request to Reset password.

Post condition Reset users account.
Actor System Response
1. The Administrator login to

the system. 2. The system display
Administrator home page.
3. The Administrator click on
Reset account. 4. The system display Reset
account form.
5. The Administrator Fills Reset
account form. 6. The system display Reset
account successfully message.
7.click on submit button
8. End of use case.
Alternative course of action If the system administrator fills incorrect information, the
system displays error message, and go back to step 5 of basic
course of action.
Table 11Use case description for Reset user account.
P a g e 26 | 82

Use case name block account
Actor System administrator
Description The system administrator block accounts of the program manager,
students and invigilators if there is any inconvenience.
Precondition The administrator must login to the system.
Post condition
User action System response
Basic course of action 1. The admin login to the
system.
2. The system displays admins page.
3. The admin clicks manage
account link
4. The admin clicks on view
users link 5. The system displays search box
6. The admin enters

keywords on search box
and clicks on search button
7. The system displays the search

8. The admin check on result.
block account.
9. The system displays message.
10. End use case.
Alternative course of action If the search result is empty or if the user enters incorrect keyword
in the search box the systems lets the user to try again.
Table 12 Use case description for Reset user password.
2.6 Non-functional requirements

Non-functional requirements describes about the systems quality rather than the main
functionality of the system. Some of these are availability, speed, usability, availability,
performance, portability, and the likes. Non-functional requirement describes requirement that
P a g e 27 | 82
support the main part of the system that should have but they are not the part of the system
functionalities.
2.6.1 Robustness
Our system will face different interactions from different users. Therefore; each interaction
may bring an invalid input to the system. These invalid inputs may crash the system. Our system
will be implemented to capture any invalid data with Error Handling Mechanism. Therefore; any
invalid data will be thrown and notified to the user as soon as possible.
2.6.2 Availability
 The system availability is constrained by the availability of the web application server,
database server, and other supporting software servers.
 Our system is available in anywhere that has internet access.
 System availability is the time when the application must be available for use. Required
system availability is used in determining when maintenance may be performed.
Definitely we think about time zones, schedules, and user location.
 The system must available 24 hour a day and 7 day a week.
2.6.3 Flexibility
 The user interface for the software shall be compatible to any browser such as Internet
Explorer, Mozilla or chrome by which user can access to the system.
2.6.4 Performance
The system responds the user request within maximum of 5 seconds (This mainly depends on
the Internet connection speed provided by ETC). Using images and pictures to make the website
usable may affect the response/download time of each page.
2.6.5 Security
Our system will be built with security methods. The user has to enter a user name and
password so as to get in to one of the service. Therefore the system assures that any unauthorized
user is not allowed to access it.
 The external security should be provided by given the login authentication.

 There should be proper security regarding to the accessing of data by unauthorized user.
2.6.6 Usability
 The system shall provide a uniform look and feel between all the web pages.
P a g e 28 | 82
 The interface should contain prompts and help to avoid making mistakes
 The product should be used by people with no training
2.6.7 Portability
 To install the proposed system, no change need to be made on the current infrastructure,
the system will suit most infrastructures automatically. The system will run on a number
of major operating system and architectures, including Windows and Linux.
 The system supports mobile platforms like smart phones and tablets.
2.6.8 Efficiency
 The system gives appropriate output based on the expected lists of inputs.
 The system operates the shortest time rate within the least amount of resources.
2.8 ACTIVITY DIAGRAM

UML Activity diagrams are used to document the logic of a single operation or method, a single
use case (may be the basic course of action or the alternate course of action) or the flow of a
logic of a business process. They are the object oriented equivalent of flow charts and data flow
diagrams in the structured development approach. We have done the activity diagram for the
total business process of the web based exam scheduling system of BiT.
P a g e 29 | 82
login
AD 1
user open system
click on login link
enter user name and password
click on login button

[incorrect]
[correct]
Figure 2 activity diagram for login
.
P a g e 30 | 82
view exam schedule

AD 2
user open system
click on view exam schedule menu
display exam schedule
vew exam schedule
Figure 3 activity diagram for view exam schedule
P a g e 31 | 82
logout
AD 3
click on logout button
Display hompage
Figure 4 activity diagram for logout.
P a g e 32 | 82
send feedback
Ad 4
open the home page
click on feedback menu
write the feedback
[incomplete]
click submit button
[complete]
Figure 5 activity diagram for send feedback
P a g e 33 | 82
update exam schedule

AD 5
Login to the system
click on update exam schedule menu
Enter exam schedule id on search box
click on search button [not found]
[found]
click on update button
Figure 6 activity diagram for update exam schedule
P a g e 34 | 82
generate exam schedule

AD 6
login to the system
click on generate schedule menu
fill the form

*
[Incomplete]
click on generate button
* *
[Complete]
Figure 7activity diagram for generate exam schedule
P a g e 35 | 82
Delete exam schdule

AD 7
login to the system
Click on delete schedule menu
Enter schedule id on search box
Click on search button

[Not found]
[Found]
click on delet button
Figure 8 activity diagram for delete exam schedule.
P a g e 36 | 82
create users account

AD 8
login to the system
click on create account menu
fill account form
[incomplet]
click submit button
[complet]
Figure 9 activity diagram for create user account.
P a g e 37 | 82
Reset users password

AD 9
login to the system
click on Reset Password
fill account form
incomplete
click submit button
complete
Figure 10 activity diagram for Reset user password
P a g e 38 | 82
2.9 Sequence Diagram

Sequence diagrams are used to model the logic of usage scenarios. A usage
scenario is exactly what its name indicates – the description of a potential way that
your system is used. The logic of a usage scenario may be part of a use case,
perhaps an alternate course. It may also be one entire pass through a use case, such
as the logic described by the basic course of action or a portion of the basic course
of action plus one or more alternate scenarios.
login User<<actor>> Login page<<U>> Database needed page<<UI>>

SD 1
open login page()

{The user open login page}
{Enter username and password} Enter username and password
{The system checks

usernamend password}
{If username and password is correct check()

opns the needded page}
{If username and password is

incorrect lets the user if input is invalid
to enter again} If input is valid
Figure 11 sequence diagram for login.
P a g e 39 | 82
view exam schedule

SD 2 Hompage<<UI>>
User<<actor>> Object1
{Users open the home open()

page}
{ User view exam open()

schedule }
Desplay()
{ The system display the
exam schedule }
Figure 12 sequence diagram for view exam schedule
P a g e 40 | 82
SD 3
Update schedule. Login page<<UI>> update link <<UI>> search box<<UI>> home page <<UI>>
P.manager<<UI>>
{login to the system}
login ( )
{ program manager
Clicks on update
schedule}
{ the program manager

Write on the search
Box and click on search}
Click ()
{if the searched item is open ( )

found,the system
displayed on the home
write searched item on search box ( )
page}
{if the searched item is [ifvalid] display ( )

not found ,the system lets
the program manager [if not valid] try agian ( )
To search again}
Figure 13 sequence diagram for update exam schedule
P a g e 41 | 82
SD 4 feedback link Feedback form Database

user<<actor>> Home page<<UI>>
Send feedback
{The user opens the home page}
{click on feedback link} Open()

click()
{Fill the feedback form} Open()
{if the form is filled correctly

fill the form
the comment is saved to
the database} clickOn send button [if complate] save()
{If the form is not filled [if not complate] try again()
correctly the system lats
the user to write again}
Figure 14 sequence diagram for send feedback
P a g e 42 | 82
Actor<<UI>> Log out button<<UI>> Home page<<UI>>

SD 5
logout
click()
{The user clicks log
out button}
open()
{The home page is displayed}
Figure 15 sequence diagram for log out
P a g e 43 | 82
SD 6
generate exam
P.MANAGER<ui> Login page<<UI>> Post exam schdule link Form<<UI>> Home page<<UI>>
{The user login

To the system}
login()
{then click on update exam

schedule}
click()
{A form is which is used to

generet exam schedule
Is display}
{The program manager fill
[If valid]display()
the form fill the form()
and clicks on post
Button} [If invalid ]try again()
{if the form is correctly
filled the system displays
the exam schedule}
Figure 16 sequence diagram for generate exam schedule
P a g e 44 | 82
SD 7
delete exam schedule
P.manager Home page<<UI>> DEL-Schedule<<UI>> Database
Login()
Open()
{p. manager login to

the system}
Select to Delete the schedule()
{ then click on delete select Delete button()

schedule }
{ displayed search box Delete schedule()

and
Write you want to delte
{delete the searched

item
Figure 17 sequence diagram for delete exam schedule
P a g e 45 | 82
Creat user account User<<Actor>> Admin page<<UI>> craete account link Form<<UI>> Database
SD 8
{The user opens the home page} Open()
{The user clicks on

create account link}
{the system displays a Click()
form to create account}
fill the form()
{The user fills the form
[if valid] save()
and click on register button}
[is invalid] try again()
{If the form ic correctly
filled the data is saved
to the database}
{If the data filled by

the user is not valid the
system lets the user to enter again}
Figure 18 sequence diagram for create users account.
P a g e 46 | 82
Reset users password

SD 9
user <<Acctor>> Login page<<UI>> Database Admin page<<UI>>
open
{ open login page }
{ Enter user name and

enter username and passw
password }
checks
{ the system checks
Username and
if input is valid
password }
{ If user name and
password is correct , if input is invalid
opens Admin page }
{ if the username and
password is incorrect
lets the user enter
again } click reset password
{ click Reset password

} fill the reset form
{ fill reset form }

Reset
{ Reset user password
}
Figure 19 sequence diagram for reset password.
P a g e 47 | 82
CHAPTER THREE
SYSTEM DESIGN
3.1 Deployment Diagram

Deployment diagram is a static view of the run-time configuration of processing nodes and the
components that run on those nodes. Or it depicts how the deployable units of the system
applications, components, and data stores are assigned to various nodes, as well as how the nodes
communicate with each other and with devices. It’s useful both as a map of our system and as a
means for studying the load across our System.
Deployment Diagram
Browser web server

<<connection>>
Exam scheduling Database server
<<Http >> system
asp.net
response
response
Sql server 2012
users
Figure 20 deployment diagram
3.2 CLASS DIAGRAM

Our system has eight class, those are program manager, student, classroom, invigilators, system
admin, feedback, exam schedule and course. In Unified modeling language context, a class
P a g e 48 | 82
defines the methods and variables in an object, which is a specific entity in a program or the unit
of code representing that entity. This diagram describes the objects and classes of the system and
the relationship between them. It provides the model for domain-specific data structure to
detailed design of the system. It provides a wide variety of usages; from modeling the domain-
specific data structure to detailed design of the target system. The Form Diagram allows you to
generate diagram automatically with user-defined scope.
P a g e 49 | 82
person
+ First name : String
+ Scond name : String
+sex : String
#ID : string
+login()
+logout()
+viewFeedBack()
+sendFeedBack()
program manager student system admin

Invigilator
+ qualification : string +department : String -adminID : String
check
-ID : string +phoneNumber : String 1

+phoneNumber : string * -batch : string +address : string
* 1 +email : string +section : string +create() : void

+address : string verify +update() : void
+deleteExamSchedule() : void +sendFeedBack() : void +control() : void
-viewExamSchedule() : void * +updateExamSchedule() : void 1 +viewExamSchedule() : void
+register() : void +viewFeedBack() : void *send * 1
+sendFeedback() : void 1 + generate() : void view
*
* 1 1 * *
Register
Feeback
Assign to
send * +feedback_Id : string

+body : string
generate
assign
+email : string
1 1 +update() : void administer
Exam schedule
+examTime : Date *
+examDate : Date Assign to Class Room *
+courseCode : String 1 -roomName : String Course
+courseName : String * -roomNumber : String -courseode : String
+courseOwner : String +courseName : String
-buildingNumber : String +courseOwner : String
+section : char
+batch : String
+department : String
+semister : String
1 Assign to *
-faculty : string
+view() : void
+delete() : void 1 view
+update() : void
Figure 21 Class diagram

P a g e 50 | 82
3.3 User interface design

The design of the system interfaces that we are used in the development of web based exam
scheduling system. Those user interfaces show what the system interfaces look like. We try to
represent some basic user interface are mainly used in our system.
Figure 22 user interface for login
P a g e 51 | 82
Figure 23 user interface for program manager home page.
Figure 24 user interface for program manager generate exam schedule.
P a g e 52 | 82
Figure 25 user interface for program manager update exam schedule .
Figure 26 user interface for program manager delete exam schedule.
P a g e 53 | 82
Figure 27 user interfaces for system admin create account form.
Figure 28 user interface for invigilators view exam schedule.
P a g e 54 | 82
Figure 29 user interface for students view exam schedule.
Figure 30 user interface for student send feedback.
P a g e 55 | 82
3.4 Entity relationship diagram

An entity-relationship model is graphical representation of entities and their relationships to each
other, typically used in computing in regard to the organization of data within databases or
information systems. An entity is a piece of data-an objects or concept about which data is
stored. A relationship is how the data is shared between entities.
Figure 31 entity relationship.
P a g e 56 | 82
3.4.1Entity description
Attribute number 01
Attribute name Name
Attribute data type varchar(15)
Related entity  Program manager
 system administrator
 students
 invigilators
Category Composite
Table 13entity description
Attribute number 02
Attribute name DOB
Attribute data type Int
 students
 invigilators
Category Single
Attribute number 03
Attribute name Sex
Attribute data type char(6)
 students
 invigilators
Category Single
P a g e 57 | 82
Attribute number 04
Attribute name addresss
Attribute data type nvarchar(10)
 students
 invigilators
Category multivalued
Attribute number 06
Attribute name Id
Attribute data type Varchar(15)
Related entity  invigilators
Category Single
Attribute number 07
Attribute name Course_Name
Related entity  course
Category Single
Attribute number 08
Attribute name Course _owner
Related entity  exam schedule
 course
Category Single
Attribute number 09
Attribute name Course_code
 course
Category single
P a g e 58 | 82
Attribute number 10
Attribute name Batch

 student
Category single
Attribute number 11
Attribute name Department
Related entity  student
Category single
Attribute number 12
Attribute name Faculty
Category single
Attribute number 13
Attribute name Section
Attribute data type char(2)
Related entity  student
Category single
P a g e 59 | 82
Attribute number 14
Attribute name Building number
Related entity  classroom
Category single
Attribute number 15
Attribute name Room_Id
Related entity  classroom
Category single
Attribute number 17
Attribute name Sssn
Related entity  system admin
Category Single
Attribute number 18
Attribute name Ssn
Related entity  program manager
Category Single
P a g e 60 | 82
Attribute number 19
Attribute name Username
Related entity  create
Category association
Attribute number 20
Attribute name password
Related entity  create
Attribute number 21
Attribute name examDate
Attribute data type date
Related entity  generate
Attribute number 22
Attribute name examTime
Attribute data type Time
Related entity  generate
P a g e 61 | 82
3.5 Mapping ER diagram

Step 1: mapping of Regular entity type
 including simple attribute
 include primary key
Mapping’INVIGILLATOR’entity
Id kebele city fName mName lName DOB sssn faculty sex Username Password
Mapping ‘SYSTEM ADMIN’entity
SSN fName mName City Kebele sex DOB
Mapping’PROGRAM MANAGER’entity
SSN fName mName Lname DOB Kebele city sex faculty Exam Exam
date time
Mapping’STUDENT’entity
Stud fName mName lName Section sex batch department faculty sssn username password
Id
Mapping’EXAM SCHEDULE’entity
Faculty Course_Name Course_code Department batch Course owner section
P a g e 62 | 82
Mapping’COURSE‘entity
Coursecode Course Name Course owner
Mapping ‘FEEDBACK‘entity
feedback ID Email SSN
Mapping’CLASSROOM’ entity
room_Id roomName buildingNumber
Step 2.Mapping of binary 1:1 relation type and m: m relation type

Mapping ‘ASSIGNto’assocation
Faculty Room_Id examDate examTme
Mapping’Send’ association
Feedback_Id Invig_Id Stud_Id
Mapping’ASSIGN’assocation
SSN Course code examDate examTime
Mapping ‘Create’ association

Ssn sssn username paasWord
P a g e 63 | 82
Mapping’Generate’assocation
SSN Faculty Exam date Exam time
Mapping’check’assocation
SSN Course_code
3.6NORMALIZATION
Normalization is the process of organizing data into tables in such a way that the results of using
the database are always unambiguous and as intended.
3.6.1 First normal form
Requires that all column values in a table are atomic (e.g., a number is an atomic value, while a
list or a set is not). We have two ways achieving this:
1. Putting each repeating group into a separate table and connecting them with a primary
key-foreign key relationship
2. Moving these repeating groups to a new row by repeating the non-repeating attributes
known as ―flattening the table.
1. INVIGILATOR
Invigilator kebele city fName mName lName DOB sssn faculty sex Username password
Id
2. SYSTEM ADDMIN
SSN fName mName city kebele sex DOB
3. STUDEENT
Stud fName mName lName Section sex batch department faculty sssn username password
Id
P a g e 64 | 82
4. PROGRAM MANAGER
SSN fName mName Lname DOB kebele city sex Faculty Exam Exam
date time
5. EXAM SCHEDULE
Faculty Course_Name Course_code department batch Course owner section
6. COURSE
7. FEEDBACK
8. CLASS ROOM
9. ASSIGN TO
Faculty Room_Id examDate examTime
10. SEND
P a g e 65 | 82
11. ASSIGN
SSN Course code Date Time
12. CREATE
Ssn Sssn userName paasWord
13. GENERATE
SSN faculty examDate examTime
14. CHECK
SSN Course_code
3.6.2 Second normal form

Allthe tables are in first normal form and all non-key attributes are dependent on the entire primary key.
I.e. no partial dependency.
1. INVIGILATOR
Invigilator kebele city fName mName lName DOB sssn faculty sex Username password
Id
2. SYSTEMADDMIN
SSN fName mName City kebele sex DOB
P a g e 66 | 82
3. STUDENT
Stud fName mName lName Section sex batch Department faculty sssn username password
Id
4. PROGRAM MANAGER
SSN fName mName Lname DOB kebele city sex faculty examDate ExamTime
5. EXAM SCHEDULE
6. COURSE
7. FEEDBACK
8. CLASS ROOM
9. ASSIGN TO
10. SEND
P a g e 67 | 82
11. ASSIGN
12. CREATE
Ssn Sssn userName password
13. GENERATE
14. CHECK
SSN Course_code
3.6.3 Third Normal Form

1. EXAM SCHEDULE
2. COURSE
3. FEEDBACK
P a g e 68 | 82
4. CLASS ROOM
5. ASSIGN TO
6. SEND
Feedback_Id Id Stud_Id
7. ASSIGN
12. CREATE
Ssn Sssn username paasword
13. GENERATE
14. CHECK
SSN Course_code
3.7 Algorithm Design

In this part we describe the algorithm of the operations or methods which found in class diagram
using Pseoudocode. Pseoudocode is one type of algorithm representation.
P a g e 69 | 82
1. Pseoudocode for login

Steps/procedure
Method name=login
Begin
Variables:-username
-password
If (*inputs are valid*)
(*select the previous username and password from database and compare with entered*)
If username = entered username and
Password = entered password
(*go to login page*)
Otherwise
Display “login!”
Endif
Otherwise
Display “incorrect password or user name please try again!”
End
2. Pseoudocode for send feedback
sendFeedback(){
write the feedback in the form;
P a g e 70 | 82
check if the entered value is valid;

if(valid){
message says feedback sent;
}
else{
error message 'the feedback not sent' try again;
}
}
3. . Algorithm for update exam schedule

update exam schedule(){
login();
click on update exam schedule link;
enter the necessary information on the form;
check if the form values are valid;
if(valid){
message 'updated successfully';
}
else{
message 'please enter valid data on the form';
}
4. Algorithm for delete exam schedule

Delete exam schedule(){
login();
enter a key word to search theexam schedule;
check if the key word is valid;
if(valid){
click on delete button;
if(delete success){
message 'deleted';
}
else{
message 'not deleted' try again;
}
}else{
message 'please enter valid key word';
}
}
P a g e 71 | 82
5. algorithm for system admin creating an account.

Create Account (){
fill the form;
check if the form is correctly filled;
if(correct){
message 'successfully registered';
}
else{
message 'please fill the form correctly';
}
Bibliography
1. Barbara Paech, C. M. (2007). requirement analysis. In C. M. Barbara Paech, Innovations
for Requirement Analysis. monterey USA: Springer Science & Business Media.
2. Brett D. McLaughlin, G. P. (2006). Object-Oriented Analysis and Design. canada:

Library of Congress Cataloging-in-Publication .
3. Jabar, M. (2014, 11 27). Software requirement analysis template. Retrieved from IEE
website:
http://ieeexplore.ieee.org/xpl/abstractAuthors.jsp?arnumber=6205008&abstractAccess=n
o&userType=inst
4. Laplante, B. P. (2004). functional requirement specification. In B. P. Laplante, Real-Time

Systems Design and Analysis (pp. 350-598). chicago: By Phillip A. Laplante.
5. Ramez Elmasri, S. B. (2004). Fundamentals of Database Systems. In S. B. Ramez

Elmasri, Fundamentals of Database Systems (pp. 49-121). Boston San Francisco New
York: Pearson Education, Inc.
6. School template
P a g e 72 | 82

ExamScheduling System Documentation

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Read this document in other languages

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ExamScheduling System Documentation

Uploaded by

Copyright:

Available Formats

BAHIR DAR UNIVERSITY

BAHIR DAR INSTITUTE OF TECHNOLOGY

A Project Submitted to faculty of Computing in Bahir Dar University in

Name and signature of project group members.

Faculty: faculty of Computing

Examining committee members signature Date

Table Contents page

Abstract ...................................................................................................................................................... viii

2.6 Non-functional requirements ......................................................................................................... 27

LIST OF FIGURES page

Figure 1use case diagram............................................................................................................................ 15

Figure 3 activity diagram for view exam schedule...................................................................................... 31

LIST OF TABLES page

Table 4 use case description for generate exam schedule. ........................................................................ 19

5 Use case, attribute

1.3 Existing system study

1.4 proposed system

1.5 Objective of the project

1.6 Scope of the project

1.7 Methodology and tools

1.8 Significance of the Project

 The number of students having consecutive exams.

1.9 Organization of the project

1.10 Definitions and Abbreviations

Sass: system admin social security number

2.2 Existing System Description

2.3 Proposed System Description

2.4 Functional Requirements

2.4.1 User requirements

Name: - The system shall allow students to change his/her password.

2.4.3 Software requirements

2.4. 5 System requirements

2.5 Use case diagram

Use case diagram for exam schedule

Figure 1use case diagram

2.5.1 Use case documentation

Use case number UC 01

Table 1use case description for login.

Alternative course of action

Table 2 use case description for logout.

Table 3 Use case description for change username and password.

Use case No: UC 04

Use case Name: Generate exam Schedule

Table 4 use case description for generate exam schedule.

Use case number UC 05

Use case name Delete exam schedule

5.the program manager

7. The program manager

Table 5 use case description for delete exam schedule.

Use case number UC 06

Use case name Update exam schedule

Table 6 use case description for update exam schedule.

Use case number UC 07

1. The program manager

6. End use case.

Table 7Use case description for view feedback.

Use case number UC 08

1. The user login to the

6. End use case.

Table 8 Use case description for View exam schedule

Use case number UC 09

Use case name Send feedback