DEBRETABOR UNIVERSITY

FACULITY OF TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE
DORMITORY MANAGEMENT SYSTEM FOR DEBRE TABOR UNIVERSITY
(DTUDMS)
SINNER PROJECT Report
Prepared by:
Name Id

1 Abiyot Mulualm ………………………....006/11

2 Esubalew Limen …………………………073/11
3 Anduamlak Tayachew …………………………024/11
4 Andualem Yesgat ……………….................022/11
5 Abaynew Belay ………………………....001/11

Main Advisor: Mr. Yonatan M

SUBMISSION DATE: -

1
Abstract
The students' dormitory is the main place to University students' daily life, so the students' dormitory
management is an important part of management in the university. The purpose of this project which is
entitled Dormitory Management System (Web Based) for Debre Tabor University is to develop a new
Web Based Dormitory Management System that is highly reliable, easy, fast and consistent and will play
a crucial role for reliable service for students, proctors, and for the management. The existing system of
the organization is facing different problems such as Data duplication ,Time consuming, lack of data
security, Management inflexibility, lots of paper work and require more human power to assign the
students. The scope of this project is to develop and implement a new web based Dormitory
Management system which will solves the above mentioned problems with the existing system. In order
to achieve the objective of this project, the project team selected the Iterative model because iterative
process starts with a simple implementation of a small set of the software requirements and
iteratively enhances the evolving versions until the complete system is implemented and ready
to be deployed. And the project team used different data collection methods such as Interview,
Document analysis, Questionnaires, and Practical observation. In order to analyze and design the system
we are going to use Object oriented approach for both analyzing and designing the new system. Since
the current system was manual, to change this system to web based, we need different software and
hardware tools like for Script languages PHP, HTML, CSS and JAVASCRIPT, For Web server WAMP
SERVER. And For Data base Server MySQL database.

CHAPTER ONE

1 Introduction
Technology is spreading its wing in almost every walks of human life activities. Now a day it is

better if every activity is done using new technology in order to fulfill the need of human being,

1
Organization, Enterprise etc. As today’s world there are many organizations and each

organizations needs to be preferable, computable and work on fastest way in order to satisfy

users interest etc. i.e. they should have facilitate their activities in computerized way.

Many developing countries are in a good position to exploit the opportunity of

technology revolution and advance human development. The information and communication

technology provide new resource materials for expanding communication.

In fact the second half of 20th century has wittiness the global phenomena of an

information explosion. The development in communication technology has made it possible for

millions of people to have fast access to vast information presented in several forms. Today

computer and other electronic device increasingly communicate and interact directly with other

devices over a variety of network such as internet. The internet provides individuals and small

business centers for the ability to communicate inexpensively.

Hence, developing the system using technology has a tremendous effect for organizations

and offices; which is in our case the Debre Tabor University dormitory management system

(DTUDMS). Currently, the system is manual based; due to this the students and proctors faces

some problems Because of this, we are initiating to develop our project on dormitory system in

order to minimize the problem by using computerized system.

1.1 Organizational background

Debre Tabor University is one of the major Universities in the country which was established in

the year 2001EC by the Ethiopian government (MOE), Their Excellences Addisu Legesse and

Demeke Mekonen laid the foundation stone on the eastern part of the Debre Tabor town about 4

Kms away from its center on 126 hectares of land. On July, (23/11/2003 E.c), The Board of the

University was organized and started to give direction based on Proclamation No 650/2001.

2
Then, the assigned presidents started to employ teachers and admin workers as per the

responsibilities and obligations of the Ministry of Civil Service. This helped the university to

employ 114 M, 10 F Total 124 teachers, and 51, M 20 F Total 71 administration workers. With

enrollment of 628 Student from four different faculties. After three consecutive year’s i.e. 2006

E.C DTU inaugurated its first graduation ceremony with 348 under graduates from four different

faculties in 2006/2014 academic year.

Currently the University runs over 28 departments in first degree and 5 postgraduate studies by

the total of 10,000 students. In addition to the academic service the university provides, health

care, dormitory, community service and other services for the students and Debre Tabor town

communities.

In the University there are different management activities were performed. Among those the

main service which provides the university to the student is Students’ Dormitory Management

can be taken as an example. In this process there is a problem associated with the Dormitory

Management. So we the project team members were initiated for this project to identify and

analyze those problems and to put possible solutions.

1.2 Motivation
Manual processing of management activities like: - arranging buildings for the allocation,

assigning proctors for buildings, rearranging students and dorms and take attendance. Since the

total no of students and dormitories available in the university is very large, managing this huge

number manually is very tedious and is prone to many problems, such and like problems are

motivated to do this project.

3
 1.3 Statement of the problem
Currently, DTU dormitory management system uses manual approach. To process the operation

first the ministry of education sends all the information to the registrar bureau and gives to the

student affairs (dormitory) and to the dinning office. After taking the list, they assigned students

to each block and room. At that time they face different problems during operating their tasks.

Working by paper based i.e. manual system is not only affecting the management members,

rather it also for student during viewing of their dormitory information and Attendance process.

Manual process of management Activities like:-

 Arranging building for allocation.

 Assigning Proctor for building.

 Rearranging students and dorm.

 Take student Attendance.

Since the total number of students and dormitory available in the university is very large,

managing this huge number is very tedious and is prone to many problem.

Some of those problems are:-

 Data duplication and Time consuming.

 Require more human power to assign the students and to control student attendance.

 Management inflexibility

 Tedious to allocate block and dorms manually.

 Tedious to take attendance manually.

 It’s difficult to communicate with the dormitory when there is no assigned dorm for an

individual student, because the existing system is not accessible automatically.

 The existing system is mostly costly.

4
 1.4 Objective of the project

1.4.1General Objectives
The main objective of this project is to develop a new Web Based Dormitory Management

System for Debre Tabor University.

1.4.2 Specific Objectives

In order to achieve the main objective, we have the following specific objectives:

 To study all relevant document from the existing system.

 To identify the potential problem of the existing system.

 To gathering user requirements from different stakeholders.

 To analyzing user requirements.

 To designing the system architecture of the system based on user requirements.

 To develop flexible and easily accessible system.

 To developing user friendly interface.

 To develop responsive system.

 To verify and test new system.

 To deploy the system after the system is tested.

1.5 Scope and limitations of the project

1.5.1 Scope of the project

The scope of a project shows the boundary of the project it will cover. It may be geographical

boundary or functional boundary.

Geographical boundary: -Geographically the system is limited to Debre Tabor university.

Functional boundary: - the proposed project had functionally limited to the following activities:
 Allowing the proctor to assign the dorm accordingly.
 Enable students view their dormitory information easily and quickly
 Enable Procter and proctor manager to Generate report.

5
  The system supports to take the student attendance absent or present.
 The system supports announcement related to students.
 The system supports dormitory material record.
 The system allows to proctor manager to create user account, update and delete.
 The system supports manage dormitory related information.

1.5.2 Limitations of the project

 It works for the one who understand English language (we have not used other

language).

 Our system does not serve the students who are not able to see (blind people).

 It’s difficult to know students information and give clearance while they are

living the university.

1.6 Significance of the project

The new dormitory management and allocation system (web based) is highly reliable, easy, fast

and consistent and will play a crucial role for reliable service for students, proctors, and for the

management. The significance of the system includes:

 Avoid wastage of student time as well as management time.

 Avoid data lose because of improper data storage.

 Avoid improper dormitory allocation.

 Avoid improper resource consumption.

 Highly secured management system.

 Make tasks simple and efficient in every aspects.

 Manage the students and building information properly.

 Providing a well-organized and guaranteed record keeping system with minimum space.

 Take students attendance and generate attendance report easily.

 Enable the university to get acceptance in the outside community.

 Avoid the loss of information caused by natural or human factors.

6
  Developing students’ effective communication with the university.

1.7 Feasibility Study of the new System

A feasibility study is a test of system proposal according to its workability, impact on the

organization, ability to meet user needs and effective use of resources. A feasibility study looks

at the viability of an idea with an emphasis on identifying potential problems. Project managers

use feasibility studies to determine potential positive and negative outcomes of a project before

investing a considerable amount of time and money into it.

1.7.1 Operational Feasibility

The system to be developed will provide accurate, active, secured service and decreases labor of

workers and also it is not limited to particular groups or body. And also it is plat form

independent i.e. it run’s in all operating system.

1.7.2 Technical Feasibility

The system to be developed by using technologically system development techniques such as

PHP, Java script, css and Mysql database without any problems and the group members have

enough capability to develop the project. So the system will be technically feasible.

1.7.3 Economic Feasibility

Our proposed system is economically feasible to the organization because when we compare the

cost that we need to develop and implement the proposed system less expense than the existing

manual system or not require much more cost and material to implement the system. Here we

have stated the costs related to the project and the benefits that are going to be gained after the

completion of the project by performing a cost-benefit analysis.

Generally the system that we developed, DTUDMS brought a number of tangible and intangible

benefits.

Tangible benefits

7
Tangible benefits are something that has a physical existence. Cost reduction and avoidance,
increase the income of the organization, improving response time, producing error free out put
such as report generating, and no redundancy, increased management planning and control.
The team member calculated the corresponding the tangible benefits with sample monetary:
1. Increase Speed of activity: - Increased speed calculated as follows

Especially in allocation:-

Average Days required for allocation= 15 days

Average proctor salary per day=67.61birr

Average Days required for allocation in terms of money=56*67.61*15= 56,794.4Birr

Average days required for allocation by the system= 2 day

Average Days required for allocation in terms of money=56*67.61*2= 7572.32Birr

Difference = 56,794.4Birr -7572.32Birr =49,222.08 Birr

Intangible benefits
The system we are developing has many intangible benefits that revolve around mental
satisfaction of users. These where:
 Having information about the organization at any time.
 Satisfies the students in the way that they trust the system is secure and accurate on
giving service.
 Increasing the competitiveness of the individual.
 Improved Information flow.
 Improving the morale of our team.
 Facilitating information processing of our team.
 Faster decision making on the team member.
 Increase Management flexibility

1.7.4 Political feasibility

The system to be developed is not conflict with any government directives, because it gives

services for the people effectively and efficiently, all the stakeholders also agreed before the

system developed. So the government is profitable and the system will be politically feasible.

1.8 Methodology
Methodology is the theoretical and systematic analysis of strategies related to a field of study.

8
In order to achieve our aim, we use different methods to bring the system from imagination to

realization. These methods include different models, techniques and tools for our work.

1.8.1 Data collection method

Data collection is the most important part of our project to find the main required information
to system and to understand how the system works. We used the following methods to collect
relevant data required to our project.
Primary data collection techniques

 Interview: - to get the basic information and background information about the existing

management system, the team members has interviewed the proctors and some students

about the services that are given to them, and the problems associated with that

environment.

 Direct observation: even though interview is very important to gather information,

direct observation is simple and we project team members physically observe information

that cannot maintain from the interview or others and also it is important if they are

unable to communicate with others because of the difficulties they have to the language.

 Questionnaires: since proctors as well as higher officials of proctors have work load

they cannot able to answer/give information what we ask. So we prepare some sample

questions to get précised information.

Secondary data collection techniques

 Existing document: To get more information about the project we use earlier documents

that help us to develop the project. During the analysis of documents, we give a special

consideration to those documents which can bring more features to the project.

1.8.2 Software Process Model

Software Processes is a coherent set of activities for specifying, designing, implementing, and
testing software systems. A software process model is an abstract representation of a process
that presents a description of a process from some particular perspective.

9
There are various software development life cycle models defined and designed which are
followed during the software development process. So, the proposed system follows iterative
model. Because iterative process starts with a simple implementation of a small set of the
software requirements and iteratively enhances the evolving versions until the complete
system is implemented and ready to be deployed.

Iterative process starts with a simple implementation of a subset of the software requirements
and iteratively enhances the evolving versions until the full system is implemented. At each
iteration, design modifications are made and new functional capabilities are added. The basic
idea behind this method is to develop a system through repeated cycles (iterative) and in
smaller portions at a time (incremental).

Figure 1:1 Software Process Model

1.8.3 System analysis and design techniques

Here for the analysis of our project we have selected object oriented system analysis and design
techniques specifically UML (Unified Modeling Language) model. We have selected this because of the
following advantages:-

 To simplify the design and implementation of complex program.

 To make it easier for teams of designers and programmers to work in a single software project.

 To enable a high degree of re usability of designs and of software codes.

10
  To decrease the cost of software maintenance.

 Increase re-usability.

 Reduce maintenance burden.

 Increased consistency among analysis, design and programming activities.

 Improved communication among users, analysis, design and programming.

1.8.4 Tools used in the project

While developing the project starts from the documentation to the implementation we use the

following case tools:

Activities Tools

Documentation MS word 2013,2010

Design Rational Rose, Microsoft Visio 2007,Visual

paradigm for UML standard design

Editing Paint, Macro media flash 8,Adobe.Photo

shop.CS4

Script languages PHP, JavaScript, CSS, HTML

Web server Apache Wamp server

Data base Server MySQL database

Table 1.1 Tools used in the project

1.8.5 Roles and Responsibilities

Debre Tabor University Dormitory Management System (web based)

S.No Name ID NO. Email Address Responsibilities

-group Coordinator

1. Abiyot COM(R)006/11 abiyotmulualem7@gmail.com -Testing

Mulualem Documentation

11
 -Implementation

COM(R)073/11 esubie073dtu@gmail.com -Data gathering

2. Esubalew -Designer

Limen -Implementation

Abaynew Abaynewbely12@gmail.co -Data gathering

3. Belay COM(R)001/11 m -Designer

4. Anduamlak COM(R)024/11 andutayachew@gmail.com -Designer

Tayachew

5. Andualem COM(R)022/11 andualemyes@gmail.com -Data gathering

yesgat -Designer

Project Advisor: Instructor Yonatan M ()

Table 1.4 Project Team Organization

1.10 Work breakdown Structure

Our project has four main stages. These are: -

A. Proposal- In this stage the project contains the facts that shows how the existing system

works and other information’s such as the background of the organization and the

problem of existing system. This stage also shows the needs that the new system wants

to solve the problem. The proposal stage is the main stage that contains the plane to

complete the project effectively.

B. Analysis-In the analysis stage requirements will be determined. This means the new

system should do from as many sources as possible (user of the existing system, forms

and procedures). In the analysis stage requirements that we determined will be

12
 represented diagrammatically in order to make them easier to translate into technical

system specification.

C. Design-In this stage that we will make the layout that shows how the new system will do

at its implementation stage. These are user interface, sequence diagram, etc.

D. Implementation and testing -It is the last stage that we will run and test the new

system.

1.11 schedule

1.11.1 Time schedule

Time

Feb 20- Feb 29- Mar 03- Apr 02- May 6- Jun 21-

Activities 28 Mar 02 Apr 01 May 5 Jun 20 Jun ---

Nov 16

Project

Proposal

Requirement Analysis

Design

Implementation & Coding

13
Testing

project Defense

Table 1.1 Time schedule

1.11.2 Cost schedule

1.11.2.1 Hardware cost

No Material Amount Price per unit Total price

1 A4 size paper 2 Destin 100 Birr 200Birr

2 Pen 7 4 Birr 28Birr

3 Flash disk 2 240 Birr 480Birr

4. For Print 100 sheet 1 Birr 100Birr

5 CD 6 8 Birr 48 Birr

6 desktop computer 2 Free(lab 00.00 Birr

computer)

Total 856.00 birr

Table 1.3 Hardware cost in the project desktop

1.11.2.2 Software cost

No Material Price per unit

1 Microsoft office 2010 Free

2 Microsoft office 2013 Free

3 Rational rose Free

4 Apache Wamp server Free

5 Notepad++,sublime Text3 Free

Total 00.00 Birr

14
 Table 1.4 Software cost in the project

CHAPTER TWO

Study of Existing System

2.1 Introduction
Description of the existing system is the detailed study of the various operations performed by

the system and their relationships within and outside the system.

Object Oriented Analysis (OOA): During this phase the team will look at the problem domain

and with the aim of producing a conceptual model of the information that exists in the area

which will be analyzed.

2.2 Over View of existing system

The current system of DTU dormitory management system is manual (partial). In order to

arrange and allocate students to dorms, they have to follow the record as it is arranged by DTU

Registrar office and allocate Students depending on department and the lists of the students’

arrangement. After getting the list from the registrar office, the proctor allocates the students to

each block and dorm. Since there are so many students, the allocation method causes problems

like assigning female students to males’ dorm and vice versa and also assigning students more

than the capacity of the dorm. In addition to these problems, during assignation there is no

consideration of disable students.

2.2. Organization Structure

Ongoing…
2.3 Services provided of existing system
Even if the existing system is performs its activities manually (partial), it has different major functions.
 Arranging buildings for the allocation: here the total number of building is determined with its
holding capacity

15
  Arranging students for allocation: here total number of students and their academic
information such as department, sex, faculty, and class year is received from registrar. Students
are then arranged based on their sex, class year, and their department and faculty for dormitory
allocation.
 Dormitory allocation: based on the arrangement of students dorms are allocated for students
along with associated dormitory resources, like lockers, tables, chairs, beds and the like.
 Generating allocation report: based the dormitory allocation the allocation report is prepared
and posted for student when they arrive at the campus after annual break.
 Managing and controlling dormitory materials: at the beginning and end of each year,
dormitory materials are recorded and controlled whether they are functioning properly or not,
then appropriate measure is taken.
 Controlling student’s discipline: In addition to the above functionalities student’s discipline
measures are controlled and recorded, whether they use the dormitory materials properly or
not, and whether they act and perform things as per the dormitory rules and regulations.
 Taking student attendance by manual system: for each day student go to proctor office and tell
their name, id_no, and room number to proctor and he take attendance.
2.4. Users of the existing system
An existing system compromises different players to carry out its job. Among those different

actors (players), the most common are Proctor manager, this body provides the list of all

students who fulfilled every requirement for allocation to proctors, Students, they will be placed

in their dorm by proctors and assigned for the property they get from the proctor, Proctors, They

involved strongly in the existing system. Proctors collect students list from registrar. After they

get all these information’s from this body they will place those students according to their sex,

class year, department and faculty.

The major actors in the existing system are:

 Students  Proctor manager

 Proctors and  Student Dean (administrator )

2.5 Business Rules in the existing system

A business rule is effectively an operating principle or polices that must be fulfilled and
obligated in order the system will function properly and effectively. It often pertain to access

16
control issues, business calculations, or operating polices and principles of the organization
(Ambler, 2001).
BR1: Only one dorm is assigned for four students, and those students should live in the dorm
which belongs to him/her.
BR2: Students should not change their dorm without the permission of the proctor with
sufficient reason.
BR3: Students are allocated in such a way that male students are not allocated with female
students.
BR4: Proctors should not assign one student in more than one dorm.
BR5: Proctors should not use student’s personal information for other purposes.
BR6: Buildings should be arranged before the allocation.
BR7: After the allocation reports should be prepared by proctors for students’ i.e. for posting.
BR8: Students never smoke cigarettes and chewing chat in the dorm.
BR9: If the students don’t agree with their dorm members the dormitory gives advices.
BR4: Proctors should take student attendance for each day when the students are live inside
the university.
2.6 Work flows in the existing system (Existing infrastructure)
Currently, DTU dormitory management system uses manual approach. To process the operation first the
ministry of education sends all the information to the registrar bureau and gives to the student affairs
(dormitory) and to the dinning office. After taking the list, they assigned students to each block and
room. At that time they face different problems during operating their tasks working by paper based. To
overcome or improve this manual (partial) operation the team comes up with a new Dormitory
Management System entitled DTUDMS. This new system is a Web based application that enables the
users to access the services given by the system through the internet. The proposed system operates in
the following manner. Normally the student information is taken from the registrar bureau. The registrar
bureau have centralized database. Then the student dormitory officers can access that database. After
getting all the required information the system will feed into our back end database based on their year
(batch), department, faculty and sex. After doing this the system will generate the allocation report
which contains dormitory information like student’s name, id number, dorm number, and block number.
This report will be released online for the student so that they can access this information by entering
his/her identification number or registration number on the webpage provided by the system just by
sitting where ever they are.

17
2.7 Report generating in the existing system
In an existing system there are different reports generated for different purposes. Those reports include
Student Dormitory allocation report, Student status report; Resource received report, and clearance
report in addition to conditional report such as discipline case report, damaged resource report, and etc.

The dormitory allocation report contains the report related to student’s block number and dorm
number. Resource received report includes reports of materials that a student has taken from a Proctor
when he/she first assigned in to that dorm. The student status report is any report that contains any up-
to-date information about a student. Discipline measurement report embraces reports such as does a
student contains any discipline record in this campus and what type of discipline measure were taken
will be generated in the report. Clearance report is a report which is generated when any student wants
to leave a campus because of different reasons. When he/she leave a campus the above reports will be
checked by the proctor collectively.

Those all reports were checked to clarify a student whether he/she returned all resources that he/she
used, is he/she free of discipline measures? After checking those reports a proctor will clear the student
that ensures that the student is free of any resources while he/she was in dorm.

2.8 The proposed system

Proposed System Description:
Even though an existing system provides different functions that are stated above, it is not to
mean that the functions are satisfactory. This is because all the processes (actions) are
performed manually. To overcome or improve this manual operation we come up with a new
Dormitory Management System entitled DTU Dormitory Management System (web Based).
This new system is a Web based application that enables the users to access the services given
by the system through the Internet. The proposed new system operates in the following
manner. First it accepts all inputs from a body which it concerns. For example in case of new
student (first year) it takes input from dean of students that is students list, in case of other
students it take from dean of students and will be feed to the system by proctors. This feeding
of data will be performed based on their year, department, faculty and gender. After all data
were collected and given to the system, it will rearrange students for the allocation. After doing
this the system will generate the allocation report which contains dormitory in formation like
student’s name, id number, dorm number, and block number. This report will be released
online for the student so that they can access this information by entering his name and
registration number on the webpage provided by the system just by sitting where ever they are.

18
Once students get their dormitory information they will be expected to fill their personal
information on the form provided, to feed this data to the system. As they arrived, students will
be expected to fill the property form which specifies list of dormitory materials that the
students will use. All the corresponding records of the above activities other are recorded and
stored in the database. So now everything is recorded and performed. The next thing to be
performed is the management of the property. Here a proctor will perform periodic checking
for the dormitory materials. If a proctor found any property crashed/damaged he will
immediately record that material, a person who did so by his name, id, dorm number, and block
number. So the system
Having this information will generate a report about a person’s status. In case a student wants
any clearance and contact the proctor, a proctor will recall the report that is generated above
and forces a student to charge what he crashed. The same but different approach will be
performed in case of discipline case report.

CHAPTER THREE

SOFTWARE REQUEIRMENT SPECIFICATION

3.1 Introduction
A project requirement is an objective that must be meet. Project requirements provide an obvious tool
for evaluating the quality of a project, because a final review should examine whether each requirement

19
has been met. This project is concerned in the functional requirements and non-functional
requirements.

Object Oriented System Analysis and Design (OOSAD): - to use the development of system among
different methodologies because it is better way to construct, manage, and assemble objects that are
implemented in the system.

Typically, OOSAD uses Unified Modeling Language (UML) to represent and visualize the
interacting objects and models in the system. This may include the following:

 Use case diagram

 Activity diagram

 Sequence diagram

 Class diagram

3.2. General constraints

The proposed project is supposed to have the following constraints: -

 Time constraint: -The time allotted for the project was more than enough.

 Time is one of the most important stakeholder considerations, project time (how

long it will take to deliver), is a vital measure of project success.

 Budget constraint (Inadequate budget.): - Starting from gathering information to do this

project and writing proposal we didn’t have enough money and other resources to

complete our project.

 Cost is equally important to stakeholders is how much a project will cost. As

with time constraints, your budget estimates need to be presented in a range.

3.3. Specific Requirements

A well-designed, well-written SRS (Software Requirement Specification) accomplishes four major goals:

 It provides feedback to the customer.

 It decomposes the problem into component parts.

20
  It serves as an input to the design specification.

 It serves as a product validation check.

3.3.1. External Interface Requirements

3.3.1.1. User Interfaces

All the users will see the same page when they enter in this website. This page asks username

and password. After being authenticated by correct username and password, user will be redirect

to their corresponding profile where they can do various activities. The user interface will be

simple and consistence, using terminology commonly understood by intended users of the

system. And it is looks like this.

Fig 3.3.1.1.User Interfaces for DTUDMS

3.3.1.2. Hardware Interfaces

No extra hardware interfaces are needed. The system will use the standard hardware and data

communication resources. This includes, but not limited to, general network connection at the

server/hosting site, network server and network management tools.

3.3.1.3. Software Interfaces

OS: Windows 10 used to manage resources.

21
Web Browser: The system is a web-based application; clients need a modern web browser such

as Mozilla Firebox, Internet Explorer, Opera, and Chrome. The computer must have an Internet

connection in order to be able to access the system.

3.3.1.4. Communications Interfaces

This system uses communication resources which includes but not limited to, HTTP protocol for

communication with the web browser and web server and TCP/IP network protocol with HTTP

protocol. This application will communicate with the database that holds all the booking

information. Users can contact with server side through HTTP protocol by means of a function

that is called HTTP Service. This function allows the application to use the data retrieved by

server to fulfill the request fired by the user.

3.4 Functional requirement

The following are the functional requirements of the new system.

3.4.1 Functional requirements of the new system for the student dean
 FREQ-1: The system shall allow the student dean to register information.

 FREQ-2: The system shall allow the student dean to update information.

 FREQ-4: The system shall allow the student dean to assign proctor.

 FREQ-5: The system shall allow the proctor to view student information.

 FREQ-6: The system shall allow the student dean to view comment.

3.4.2 Functional requirements of the new system for the proctor manager
 FREQ-6: The system shall allow the proctor manager to register information.

 FREQ-7: The system shall allow the proctor manager to update information.

 FREQ-8: The system shall allow the proctor manager to view information.

 FREQ-9: The system shall allow the proctor manager to allocate proctor to the building.

 FREQ-10: The system shall allow the proctor manager to generate report.

22
  FREQ-11: The system shall allow the proctor to view student information.

 FREQ-12: The system shall allow the proctor manager to view comment.

3.4.3 Functional requirements of the new system for the proctor

 FREQ-12: The system shall allow the proctor to register information.

 FREQ-13: The system shall allow the proctor to update information.

 FREQ-14: The system shall allow the proctor to assign student.

 FREQ-15: The system shall allow the proctor to allocate rooms/dormitory.

 FREQ-16: The system shall allow the proctor to view student information.

 FREQ-17: The system shall allow the proctor to take student attendance.

 FREQ-18: The system shall allow the proctor to generate report.

 FREQ-19: The system shall allow the proctor to generate attendance report.

 FREQ-21: The system shall allow the proctor to view comment.

3.4.4 Functional requirements of the new system for the student

 FREQ-22: The system shall allow the student to view dormitory information.

 FREQ-23: The system shall allow the student to view comment.

 FREQ-24: The system shall allow the student to write comment.

 FREQ-23: The system shall allow the student to view post info.

3.4.5. Functional requirements of the new system in general

 FREQ-25: The system shall be able to store all the data in database.

 FREQ-26: The system shall be able to count the total number of proctor.

 FREQ-26: The system shall be able to count the total number of block.

 FREQ-28: The system shall be able to count the total number of room.

 FREQ-28: The system shall be able to count the total number of student.

 FREQ-28: The system shall be able to calculate attendance percentage of student.

23
3.5 Use Case Design
As we mentioned in the above section, in this project, the team members used an object

oriented system development methodology which incorporates two principal phases. In this

chapter, what the team will do is the object oriented analysis (OOA).

3.5.1 Use case diagram

Use case diagrams are diagrams used to capture functional requirements of DMS. The notation
of use case diagram is developed to build an external view of DMS. Each use case diagrams
describes a behaviorally related sequence of transaction in a dialogue between the system
Administrator, Procter (dormitory) and Student.
Usage of use case diagram:
 Represent the goal of the system and the users.
 Specify the context a system should be viewed in.
 Specify the requirements.
 Provide an outside view of a system.
 Shows internal and external influences on the system.
 Use Case represents interaction between a user (human or machine) and the
system.
3.5.2 Actor identification
In the use cases an actor interact with the system to perform a piece of meaningful work

that helps them to achieve a goal and has access to define their overall role in the system and the

scope of their action. Depending on the above explanation actors in this system are the

following:

 Student: The students view his/ her dormitory information online and submit comment.

 Proctor: The proctor can assign student and generate report and also take student

attendance.

 Proctor manager: search, generate report and change password.

 Administrator: The administrator manages the overall system.

24
 3.5.3 Use case identification
Each Use Case describes the functionality to be built in the proposed system, which can

include another Use Case's functionality or extend another Use Case with its own behavior. The

most important and basic use cases of this system are the following:-

 Login.  View post.

 Create account.

 Update account.

 Delete account.

 Post note.

 Submit student list.

 Activate or deactivate users.

 View student info.

 Register block (Allocate Proctor)

 Allocate proctor.

 Generate report.

 View room.

 View report.

 View comment

 View dorm information

 Submit comment

 Register room.

 Write comment.

 Assign Student (allocate or deal

locate).

 Manage attendance.

25
 3.5.4 Use case diagram for DTUDMS

Figure 3. 1 Use case diagram for DTUDMS

26
3.6.3 Use case Description

Table 3.1 Use case Description for login

Name Login
Use case Id UC01
Description To authenticate the user
Actors Administrator, Proctor manager and Proctor
Pre-condition The user must have an account of registered
Flow of action Actor action System response
Step1: User wants to login Step3: The system displays the login
Step2: Select the login link form
Step4: Fill username and Step5: Validate user name and
password password.
Step6: The system displays the
appropriate page.
Step7: Use case ends.

Alternative course of the username and password is incorrect

action The system redirects to go step 4 i.e.to enter the username and
password.
Post condition The authenticated person gets the appropriate page.

27
Table 3. 2 use case description for create account
Name Create account
Use case Id UC02
Description To create additional user of the system
Actor Administrator
Pre-condition The Administrator must be log in to the system
Basic course of action Actor Action: System response
Step1: The administrator Step3: The system displays the option as create
log to his/her page. account and remove account.
Step2: The administrator Step5: The system displays the registration form.
click create account link. Step7: The system displays succeed information
Step6: The administrator as the account is created.
fills the form and submits it. Step8: Use case ends.

Alternative course of -The system display error message that user is already exist.
action -The system redirects to go to step 6.
-Use case ends.
Post condition The account will be created.

28
Table 3. 3 Use case description for generate report

Use case name Generate report

Use case Id UC03
Actor Proctor manager, Proctor
Description Generate report of students ,proctors , assignation and attendance report
Pre-condition The actor must have full privilege.
Flow of events Actor action System response
1.The user must log to his/her page 3.The system displays the
2.The user selects generate report link report option
4.The user select the report type wants 5.The system display the
to generate information
6.use case ends
Alternative course The system verify the information, displays the error message
of action
Post-condition The report will be generated

Table 3. 4 Use case description for view dorm info

Use case name View dorm info

Use case Id UC04
Actor Student
Description A student views the dorm in which block they are assigned.
Pre-condition The Student must have valid Identification number.
Flow of events Actor action System response
1. The students want to get 3.The system display the form
dorm. 5.Validate the entered ID data
2. The actor click my dorm 6.Displays the dormitory information
link. 7. Use case ends.
4.The student fills ID no

29
 Alternative The system displays error message that the entered ID is not correct
course of action
Post-condition The system displays dormitory information to the user.

Table 3. 5 Use case description for submit comment

Use case name Submit comment

Use case Id UC05
Actors Student proctor ,proctor manager and admin
Description The users can write comment
Pre-condition The student The proctor ,proctor manager and
The student must inter the admin
valid ID and full name and The proctor, PM and admin must login
email address. to his page and inter the valid full
name and email address.
Flow of events Actor action System response
1. The user wants to write
The system displays the form
comment.
5. validate the entered information
2. The user click on write
6. The system says your comment has
comment link.
been successfully sent.
4. The user fills the all fields
7. Use case ends.

Alternative course of If the user fills incorrect format the system display error message
action
Post-condition The user sends his/her comment to the system successfully

30
Table 3. 6 Use case description for view comment

Use case name View comment

Use case Id UC06
Actor Proctor Manager , administrator ,proctor and student
Description All actor can see the comment that are submitted from the all actor
Pre-condition The admin, PM proctor and student must click the view comment link.
Flow of events Actor action System response
1. all actor must open the
The system display the
system
feedback
2. Click on view comment link
End of use cases
4. The user start to see comment

Alternative course The system displays, there is no new comment here.

of action
Post-condition The proctor manager views the submitted comment

Table 3. 7 use case description for register block

Use case name Register block
Use case Id UC07
Actor Proctor Manager
Pre-condition Proctor Manager must have full privilege to register blocks
Flow of events Actor action System response
1. Proctor Manager login to 3.System displays register block form
his/her page 5. The system validate the inserted data
2. Click register block link 6. The system display successfully
4. Fill the required fields registered notification
7. Use case ends.

Alternative course of If the inserted data format is not correct, the system displays incorrect
action entered data message and also the proctor ID is not exist in the
database the system displays incorrect proctor ID.

31
 Post-condition Block successfully registered

Table 3. 8 Use case description for register room

Use case name Register rooms

Use case Id UC08
Actor Proctor
Description The user can register room information into the database
Pre-condition Proctor must have full privilege to do this task.
Block is registered
Flow of events Actor action System response
1. Proctor login to his/her 3. The system display registration
page form.
2. Select register room link 5. The system validate entered data
4. proctor fills required fields 6. Display successfully notification
7. Use case ends.
Alternative course of If the entered data is incorrect, The system displays incorrect entered
action data message and the requirement is not correct (No registered
block).
Post-condition The room is registered successfully

Table 3. 9 Use case description for view student info

Use case name View student information

Use case Id UC09
Actor Proctor manager, proctor and Administrator
Description The user can view the detail information about the dorm as well as the
student.
Pre-condition The user must have a full privilege to access the information.

Flow of events Actor action System response

1.The user must login to the page 3. The system displays the form
2. User click on view student Info 5. The system displays student
link information

32
 4. Enter the student Id 6. Use case ends.

Alternative course If the input student id is incorrect, The system displays error message
of action Use case ends.
Post-condition The user gets the detailed information about students.

Table 3. 10 Use case description for allocate student

Use case name Assign Student

Use case Id UC010
Actor Proctor
Description Assign students in their room.
Pre-condition The proctor must have full privilege to assign the students.
Flow of events Actor action System response
1. The proctor must log to 3. The system displays the form
page 5. System validate the entered room data
2. Select assign student link 6. Use case ends.
4. Enter beds per room and
click assign button.
Alternative If the entered room data is incorrect, the system displays invalid input.
course of action
Post-condition The Student will be successfully assigned.
Table 3. 11 Use case scenario for post notes
Use case name Submit student list
Use case Id UC011
Actor Administrator
Description The system administrator submit student list to the proctor
Pre-condition Administrator must log to his/her page
Flow of events Actor action System response
1. Admin must log to the system 3. The system displays all student
2. Select submit student list link within the required batch.

33
 4. Fill the required fields 5. The system validate the input data
6. End of use cases.
Alternative (The system verify information is not correctly) The system displays error
course of action message as invalid value and back to step 4.

Post-condition The student list is successfully sent.

Table 3. 17 Use case description for forgot password

Use case name Forgot password

Use case Id UC016
Actor Administrator, proctor manager, proctor
Description Reset the password is useful when the user lost or forget his/her own
password to get the new password.
Pre-condition The user must have an account
Flow of events Actor action System response
1. The user open the system 3. The system displays reset form
2. Select forgot password link 4. The system check the validation of
4. Fill the correct form the input password
5. End of use case.

Alternative If the input data is incorrect, the system send a response to the user Invalid
course of action input value.( error message will popup).
Post-condition The password is successfully display

Table 3. 18 Use case scenario for manage account

Use case name Manage account

Use case Id UC 016
Actor Administrator
Description The Administrator can manage records.
Pre-condition Administrator must log to the his/her page

34
Flow of events Actor action System response
1. Admin log into system 3. The system will give the
2. Select the edit manage account link options like delete, update
4. The administrator selects one at a 5. The system displays the
time from the given options. available form
6. Fill the necessary fields and click 7. The system performs the task
button and validate the input data.
8. End of use case.
Alternative If the input data is Incorrect when it validate, The system displays error
course of action message or incorrect input.
Post-condition The administrator manages the record.

Table 3. 18 Use case description for manage attendance

Use case name Manage attendance

Use case Id UC013
Actor Proctor
Description The proctor can take attendance.
Pre-condition proctor must log to the his/her page
Flow of events Actor action System response
1.proctor log into system 3. The system will give the
2. Select the manage Attendance link options like take
4. The proctor selects one at a time attendance ,generate attendance
from the given options. report
6. Fill the necessary fields and click 5. The system displays the
button available form
7. The system performs the task
and validate the input data.
8. End of use case.
Alternative If the input data is Incorrect when it validate, The system displays error
course of action message or incorrect input.
Post-condition The proctor manages the attendance.

35
Table 3. 14 Use case scenario for post notes

Use case name Post notes

Use case Id UC013
Actor Administrator
Description The system administrator post news to the student, just like entrance day or
other forms of news related to student.
Pre-condition Administrator must log to his/her page
Flow of events Actor action System response
1. Admin must log to the system 3. The system displays write news
2. Select post news link form
4. Fill the required fields 5. The system validate the input data
6. End of use cases.
Alternative (The system verify information is not correctly) The system displays error
course of action message as invalid value and back to step 4.

Post-condition The post is successfully sent.

Table 3. 15 Use case scenario for view notes

Use case name View posts

Use case Id UC014
Actor Student
Description Students view the relevant information that ware posted from the system
administrator.
Pre-condition The post must be sent by the system administrator
Flow of events Actor action System response
1. The student must open 3. The system displays posted news.

36
 the system by typing the
url
2. The student select view
posts link.

Alternative If there is no posts, the system says there is no posts here.

course of action
Post-condition The post is displayed.

3.11.2. Sequence Diagrams

Sequence diagrams show the interaction between participating objects in a given use case. They
are helpful to identify the missing objects that are not identified in the analysis object model.

The main purpose of a sequence diagram is to define event sequences that result in some desired
outcome. The focus is less on messages themselves and more on the order in which messages
occur; nevertheless, most sequence diagrams will communicate what messages are sent between
a system's objects as well as the order in which they occur.

To see the interaction between objects, the following describe the sequence diagram of each
Identified use cases. The figure depicts the high level interaction of the actors with the system
that specifies the work flow the system.

37
38
Fig 3.1 Sequence diagram for login

Fig 3.2 Sequence diagram for View Dorm Info

39
Fig 3.3 Sequence diagram for Register block

40
Fig 3.4 Sequence diagram for Create account

41
42
Fig 3.7 Sequence diagram for Remove account

Fig 3.6 Sequence diagram for Search Record

43
Fig 3.7 Sequence diagram for Update Record

44
Fig 3.8 Sequence diagram for view student info

45
Fig 3.9 Sequence diagram for Generate Report

46
Fig 3.10 Sequence diagram for take attendance

3 .7 Activity diagram
Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. In activity diagrams can be used to
describe the business and operational step-by-step workflows of components in a system. An
activity diagram shows the overall flow of control.

The purposes of activity diagram can be described as:

 Draw the activity flow of a system.

 Describe the sequence from one activity to another.
 Describes the parallel, branched and concurrent flow of the system.

47
 Figure 3. 14 Login activity diagram

Figure 3. 15 Create account activity diagram

48
Figure 3. 16 Submit student list activity diagram

Figure 3. 18 Generate report activity diagram

49
Figure 3. 20 Post notes activity diagram

50
Figure 3. 22 Register block activity diagram

51
Figure 3. 23 Update account activity diagram

52
Figure 3. 24 Delete account activity diagram

53
Figure 3. 25 View dorm activity diagram

54
Figure 3. 26 View notes activity diagram

Figure 3. 27 View room activity diagram

55
Figure 3. 27 Take attendance activity diagram

56
3.8.1. Class Diagram

Fig 3.2 Class Diagram

57
3.9. Data Structural Model

3.9.1. Entity-Relationship (ER) Model

Figure 3.9.1. Entity-Relationship (ER) Model

58
 3.10 Non-functional requirement
Non-functional requirements, as the name suggests, are requirements that are not directly
concerned with the specific services delivered by the system to its users. They may relate to
emergent system properties such as reliability, response time, and store occupancy.
Alternatively, they may define constraints on the system implementation such as the capabilities
of I/O devices or the data representations used in interfaces with other systems. Non-functional
requirements, such as performance, security, or availability, usually specify or constrain
characteristics of the system as a whole. Non-functional requirements are often called qualities of
a system. Non-functional requirements describe the aspects of the system that do not relate to its
execution, but rather to its evolution over time. A non-functional requirement is a requirement
that specifies criteria that can be used to judge the operation of a system, rather than specific
behaviors.
Some of the non-functional requirements of the system are:

3.10.1 Performance characteristic

The system should respond fast with high throughput, i.e. it should perform the task quickly possible as
possible such as allocating students and proctors, viewing student and dormitory information etc.

Performance requirements are concerned with quantifiable attributes of the system such as System
should quickly respond for user request that is system must immediately display the needed service
along with their allocation details after he/she insert needed information to view.

3.10.2 Reliable.
The system should be used smoothly without being corrupted and frequent failures. When failures
occur, the system should be tolerated failure, troubleshoot in a short period, and return a related error
message.

3.10.3 Availability

The system should always be available at any time in the presence of the internet
connection or presence in a networked environment and electric power for access at 24 hours a
day, 7 days a week.

3.10.4 Security

This system provides an access to an authorized user by giving account for each and every
special function. Students can view their dorm information by using their identification card
number and/or registration number, and give comment without any validation.

59
3.10.5. Maintainability

3.10.6 Error Handling

Our system handles the errors in a very efficient manner. It can tolerate to wrong inputs and
prompts the users to correct the inputs. It gives notifications as and when required, guiding the
users to properly utilize it.

3.10.7 Portability

CHAPTER FOUR

SYSTEM DESIGN

60