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: -
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 system is minimize
time and efforts needed to perform tasks, 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 and effort need and it enables to Take and generate students attendance
properly. 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 waterfall
model. Waterfall model is a sequential model that divides software development into predefined
phases. 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,

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.

2
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. 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.

3
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.

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.

4
  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.

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 propose the new solution.

 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.

5
  To deploy the system after the system is tested.

1.5 Scope and limitations of the project

1.5.1 Scope of the project

Scope defines the boundary of our system.

 The system supports manage dormitory related information.

 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.

 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 admin and proctor manager to create user account, update

and delete.

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 online dormitory management and allocation system 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:

6
  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.

 Developing students’ effective communication with the university.

1.7 Feasibility Study of the new System

Feasibility study is essential to evaluate the cost and benefits of the new system. On the basis of

the feasibility study decision is taken on whether to proceed or to cancel the project.

Need of the feasibility study:

 It determines the potential of the existing system.

 It used to determine/finds out the problem of the existing system.

 To determine all goals of the new system.

 It finds all possible solutions of the problems of the existing system.

7
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

The system to be developed is economically feasible and the benefit is outweighing the cost. Since

this project already computerizes the existing system, by now the reduction of cost for materials

used in manual operation becomes beneficiary to the organization.

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

benefits.

Tangible benefits:

 Cost Reduction.

 Error Reduction.

 Increase Speed of activity.

The team member calculated the corresponding the tangible benefits with sample monetary:

2. Increase Speed of activity: - Increased speed calculated as follows

Especially in allocation:-

Average Days required for allocation= 15 days

8
 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 Debre Tabor University at any time.

 Satisfies the Debre Tabor University students in the way that they trust the system is

secure and accurate on giving service.

 Knowledge gain by project developer.

 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

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

1.8 Methodology
In order to accomplish this project in time and within intended cost, we will follow different

method which are described below.

1.8.1 Data collection method

The data collection instruments used to gather accurate information about the existing system and

the requirements for the new system. Interviews and questionnaires were administered to

Stakeholders like Students, Proctors and Dormitory management officer to collect user

requirements. Observation of the current existing system was done at the Dormitory management

office in order to find out how the existing system functions, the problems encountered and how

they can be solved by the new computerized system.

To get a precise data, the team member has used the following data collection techniques. Those

are: -

 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.

10
  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

In order to achieve the objective of this project, the project team selected the iterative model. The
selected iterative model is very useful as SDLC model because In this Model, we can start with
some of the software specifications and develop the first version of the software. After
the first version if there is a need to change the software, then a new version of the
software is created with a new iteration. Every release of the Iterative Model finishes in an
exact and fixed period that is called iteration. The Iterative Model allows the accessing
earlier phases, in which the variations made respectively. The final output of the project
renewed at the end of the Software Development Life Cycle (SDLC) process.

1.8.3 System analysis and design techniques

Here for the analysis of our project we have selected object oriented system analysis and design

method specifically UML (Unified Modeling Language) model. We have selected this because of

the following advantages:-

11
  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.

 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

12
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. COM(R)006/11 abiyotmulualem7@gmail.com -Testing
Abiyot
Mulualem Documentation
-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

Ongoing…

13
 1.11 schedule

1.11.1 Time schedule

Time
Feb 20-28 Feb 29- Mar 03- Apr 02- May 6- Jun 21-
Activities Nov 16 Mar 02 Apr 01 May 5 Jun 20 Jun ---

Project
Proposal
Requirement Analysis
Design
Implementation & Coding

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 HP computer 1 12,500 Birr 12,500 Birr
Total 13,356.00 birr

Table 1.3 Hardware cost in the project

14
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

Table 1.4 Software cost in the project

CHAPTER TWO

DESCRIPTION OF THE EXISTING SYSTEM

2.1 Introduction
This chapter describes the existing system, players in the existing system general work flow of

DTU dormitory management. In addition to this the business rule is identified, report generated in

the existing system, alternative solutions suggested to overcome existing system, finally the

proposed system (functional and non-functional requirement).

2.2 Description 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

15
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
 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

16
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
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.
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

17
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.

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
18
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. 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
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.2. General constraints
3.3. Specific Requirements
3.3.1. External Interface Requirements

19
3.3.1.1. User Interfaces

Fig 3.3.1.1.User Interfaces for DTUDMS

3.3.1.2. Hardware Interfaces
3.3.1.3. Software Interfaces
3.3.1.4. Communications Interfaces

20
3.4 Functional requirement
The following are the functional requirements of the new system.

3.12.1.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.

2.12.1.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.

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

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

2.12.1.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.
21
  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.

2.12.1.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 view write comment.

2.12.1.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.

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.

22
  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.
Use case components:
Actor: is a person, or external system that plays a role in one or more interaction with the
system. And represented with:

Use case: describes a sequence of actions that provides something of measurable value to an
actor and is drawn as a horizontal ellipse.

System boundary: indicates the scope of the system project. Anything within the box represent
functionalities in side in scope.

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.

23
 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.  Manage attendance.

 Create account.  View post.

 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).

24
 3.5.4 Use case diagram for DTUDMS

Figure 3. 1 Use case diagram for DTUDMS

25
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 user name 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.

26
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 log Step3: The system displays the option as create
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 as
Step6: The administrator 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.

27
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

28
 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
email address. login 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

29
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 system
The system display the
2. Click on view comment link
feedback
4. The user start to see comment
End of use cases

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

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.
Post-condition Block successfully registered

30
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 page 3. The system display registration
2. Select register room link form.
4. proctor fills required fields 5. The system validate entered data
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 link 5. The system displays student
4. Enter the student Id information
6. Use case ends.

31
 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 page 3. The system displays the form
2. Select assign student link 5. System validate the entered room data
4. Enter beds per room and 6. Use case ends.
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.
4. Fill the required fields 5. The system validate the input data
6. End of use cases.

32
 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
Flow of events Actor action System response
1. Admin log into system

33
 2. Select the edit manage account link 3. The system will give the
4. The administrator selects one at a options like delete, update
time from the given options. 5. The system displays the
6. Fill the necessary fields and click available form
button 7. The system performs the task
and validate the input data.
8. End of use case.
Alternative course If the input data is Incorrect when it validate, The system displays error
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 options
2. Select the manage Attendance link like take attendance ,generate
4. The proctor selects one at a time attendance report
from the given options. 5. The system displays the
6. Fill the necessary fields and click available form
button 7. The system performs the task
and validate the input data.
8. End of use case.
Alternative course If the input data is Incorrect when it validate, The system displays error
of action message or incorrect input.
Post-condition The proctor manages the attendance.

34
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 the 3. The system displays posted news.
system by typing the url

35
 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.

36
Fig 3.1 Sequence diagram for login
Fig 3.2 Sequence diagram for View Dorm Info manage

Fig 3.3 Sequence diagram for Register block

Fig 3.4 Sequence diagram for Create account

Fig 3.7 Sequence diagram for Remove account
Fig 3.6 Sequence diagram for Search Record

37
Fig 3.7 Sequence diagram for Update Record

38
 Fig 3.8 Sequence diagram for view student info
Fig 3.9 Sequence diagram for Generate Report

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.

39
 Describes the parallel, branched and concurrent flow of the system.

Figure 3. 14 Login activity diagram

Figure 3. 15 Create account activity diagram

40
Figure 3. 16 Submit student list activity diagram

Figure 3. 18 Generate report activity diagram

41
Figure 3. 20 Post notes activity diagram

42
Figure 3. 22 Register block activity diagram

43
Figure 3. 23 Update account activity diagram

44
Figure 3. 24 Delete account activity diagram

45
Figure 3. 25 View dorm activity diagram

46
Figure 3. 26 View notes activity diagram

Figure 3. 27 View room activity diagram

47
Figure 3. 27 Take attendance activity diagram

48
3.8.1. Class Diagram

Fig 3.2 Class Diagram

49
3.9. Data Structural Model

3.9.1. Entity-Relationship (ER) Model

Figure 3.9.1. Entity-Relationship (ER) Model

3.10 Non-functional requirement

NFREQ1: User Interface

This works as an interface between the user and the system by properly guiding the user how
to use it and perform operations. Proctors can change the data in the DBUODMS based on their
privilege, whereas, students can only view their dorm information and they can give comment.
Any sort of training is not required for using the system. It is important that the system is easy
to learn. The input device is given to keyboard and the output is viewed on the monitor.

50
NFREQ2: Quality Issue
Information in database should be as much as possible correct and updated in each semester.
NFREQ3: Security Issue
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.
NFREQ4: 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.
NFREQ5: 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.
NFREQ6: Reliability
DTUDMS system should be reliable.
NFREQ7: Modifiability
DTUODMS system should be modifiable for further modification and enhancement of the
application.

CHAPTER FOUR: SYSTEM DESIGN

51