Hostel Management System Proposal

IT- UOG - Project Coordination Office Version: 1.
0
Final Project Deliverable Guide Date: September 25, 2017
Department of Information Technology
University of Gujrat
Nawaz Sharif College Hostel Management System
Submitted By:
M. Hamza Nasir 16451556-080
Karam Bakhsh 16451556-027
Raas Ul Farooq 16821556-002
Supervised By:
Dr.Hannan Bin Liaqat
© Department of Information Technology.

1
IT- UOG - Project Coordination Office Version: 1.0
TABLE OF CONTENTS
SECOND DELIVERABLE FOR OBJECT ORIENTED APPROACH......................4
CHAPTER 2: SYSTEM REQUIREMENT SPECIFICATION....................................4
2.1 INTRODUCTION:..........................................................................................................5
2.1.1 Systems Specifications........................................................................................6
2.1.2. Identifying External Entities..............................................................................6
2.1.3. Context Level Data Flow Diagram:..................................................................7
2.1.4. Capture "shall" Statements:..............................................................................7
2.1.5. Allocate Requirements:......................................................................................7
2.1.6. Prioritize Requirements:...................................................................................7
2.1.7. Requirements Trace-ability Matrix:..................................................................7
2.2. EXAMPLE:..................................................................................................................7
2.2.1. Introduction.......................................................................................................7
2.2.2. Existing System..................................................................................................7
2.2.3. Scope of the System...........................................................................................8
2.2.4. Summary of Requirements:(Initial Requirements)............................................9
2.2.5. Identifying External Entities:..........................................................................10
2.2.6. Capture "shall" Statements:............................................................................11
2.2.7. Allocate Requirements:....................................................................................12
2.2.11. Analysis Level Usecase Diagram:.................................................................11
2.2.12. Usecase Description......................................................................................11
CHAPTER 3: DESIGN DOCUMENT..........................................................................13
3.1. INTRODUCTION:.......................................................................................................14
3.2. DOMAIN MODEL......................................................................................................14
3.3. SYSTEM SEQUENCE DIAGRAM................................................................................15
3.4. SEQUENCE DIAGRAM..............................................................................................15
3.4.1. Defining a Sequence diagram.........................................................................16
3.4.2. Basic Sequence Diagram Symbols and Notations...........................................16
3.4.3. Example...........................................................................................................19
3.4.4. Distributing Control Flow in Sequence Diagrams..........................................19
3.5. COLLABORATION DIAGRAM....................................................................................22
3.5.1. Contents of Collaboration Diagrams..............................................................23
3.5.2. Constructs of Collaboration Diagram:...........................................................24
3.6. OPERATION CONTRACTS.........................................................................................25
3.7. DESIGN CLASS DIAGRAM........................................................................................25
3.8. STATE CHART DIAGRAM...........................................................................................26
3.9. Data Model.............................................................................................................27

2
Second Deliverable For Object Oriented Approach
Chapter 2: System Requirement Specification

3
2.1 Introduction:
The Nawaz Sharif College Hostel Management System is web based software to provide
university students accommodation to the public sector hostel more efficiently. Hostel
Management system is designed in favor of the hostel management which helps them to
save the records of the students about their rooms and other things. It helps the students
by providing online facility to register their hostel and hostel’s managers from the
manual work from which it is very difficult to find the record of the students and the
information of about the those ones who had left the hostel years before.
Requirements specification is to be discussed. Requirements specification would lead to

the following steps:
 Identify external interfaces
 Development of context diagram
 Capture “shall statements
 Allocate requirements
 Prioritize requirements
 Development of requirements traceability matrix
2.1.1 Systems Specifications
The following are the clauses that must be included while describing the system
specifications.
Introduction
One of the greatest draws of hostels are their convenience, which is why hostels tend to
be located in/near the biggest hotspots of whatever city you're travelling to. Hostels are
more than just somewhere to stay, you can meet new people, save some dough and lessen
your impact on the planet. Hosteling enriches your travel experience and it does so
without breaking your bank. Hostels are ran as businesses all over the world and serve the
needs of many including travelers on a budget, backpackers and people who love to visit
them whilst on a holiday as they love to meet other people that way.
Existing System
There is some changes required in existing system. We are going to provide the solutions
to overcome these problems. Existing system is not efficient.
Organizational Chart
Organizational chart will be very much supportive to get a better overview of the
organization’s business areas and their decomposition into different departments.
Scope of the System
The Scope may include the boundaries of the system under study.
Summary of Requirements: (Initial Requirements)
An abstract is necessary at this stage to give an understanding of the initial requirements
of the system. This will show what high level requirements the proposed system must
address. This abstract will act as a foundation for the future analysis of the system.
2.1.2. Identifying External Entities
The identification of the external entities will be based on the information contained in
your Abstract. This identification is done after two phases. We will map the “Nawaz
Sharif College Hostel Management System” case study to make things more
comprehensible.
The Identification of External Entities is done in two phases.
a. Over Specify Entities from Abstract:

On the basis of the Abstract, one might identify the entities from the problem.
b. Perform Refinement:
After over specifying the entities, you have to refine them on the basis of your business
logic. For example, in this example we found the following entities more related to our
business logic;
2.1.3. Context Level Data Flow Diagram:
Context level data flow diagram contains only one process, representing the entire
system. The process is given the number zero and all external entities are shown on the

4
context diagram as well as major data flow to and from them. The diagram does not
contain any data stores.
2.1.4. Capture "shall" Statements:

Identify “shall” statements, as they would be all functional requirements.
2.1.5. Allocate Requirements:

Allocate the requirements in the use cases.
2.1.6. Prioritize Requirements:

Requirements must be prioritized as this will help achieve tasks easily. Rank them as
“highest, medium, and lowest”.
2.1.7. Requirements Trace-ability Matrix:

The requirements trace-ability matrix is a table used to trace project life cycle activities
and work products to the project requirements. The matrix establishes a thread that traces
requirements from identification through implementation.
2.2. Example:
Here is an example to explain all the above. We are taking the system Nawaz Sharif
College Hostel Management System.
2.2.1. Introduction
Nawaz Sharif College Hostel Management System is going to be a web-based project. It
will be built using C# (ASP.NET). It is possible to build in 8-9 months. There is as such
no technical constraint in it. We are going to deal with the real data and our team is expert
in this. Home Loan Indicator has no such operational constraints. The borrower’s data
will be entered by the Lender (end user) and the status will be calculated upon the data
entered. And the Lender can see if the person is capable of repaying loan or not.
2.2.2. Existing System

Business Organization
Hostel Management system deals in following main areas:
1. Hostel Registration
2. Hostel Management
3. Hostel Searching
4. Student Booking
Following sectors of Hostel Management System facilitates end users as follows:
Hostel Registration:
Hostel Registration registered new Hostels by filling a given Registration Form.
Hostel Management:
Registered Hostel will be able to manage his Hostel. Such as, Invoices, Room Allotments
& Cancellation, Reports Generation.
Hostel Searching:
When customer will visit this platform, he will be able to check the availability of
Hostels. Student can search the block of hostels like A or B block.
Student Booking:
After registration, student will select any desired room of selected Hostel and will book it
by filling student registration form.
Supplier Offices
After order confirmation by any Hostel, they will provide booked room to student.

5
Business Organizational Chart:
2.2.3. Scope of the System

Nawaz Sharif College Hostel Management system is designed in favor of the online
registration and management of hostel which helps them to save the records of the
students about their rooms and Invoices, Room Allotments & Cancellation, Reports
Generation etc. It helps the students by providing online facility to book their hostel from
the manual work from which it is very difficult to find the record of the customers and the
information of about the those ones who had left the hostel years before.
2.2.4. Summary of Requirements :( Initial Requirements)

The proposed system will fulfill the following requirements as follows:
(1) Register of hostel
(2) Inform about hostel room availability
(3) Inform about rent
(4) Online booking
(5) Allotment confirmation

6
2.2.6. Capture "shall" Statements:

Sr. Initial Requirements
No
1 Hostel User “shall” register his/her Hostel.
2 Admin User “shall” login to the system.
3 Admin User “shall” confirm/reject the Hostel Registration.
4 Hostel User “shall” get notifications of registration.
5 Student User “shall” search the Hostel.
6 Student User “shall” select any Hostel.
7 Student User “shall” check his/her registration.
8 Student User “shall” register herself/himself.
9 Hostel User “shall” login to the system.
10 Hostel User “shall” confirm/reject the hostel booking.

11 Hostel User “shall” confirm/reject the registration of Student User.
12 Student User “shall” get notifications of order and registration.
13 Student User “shall” give feedback.
14 Hostel User “shall” manage the Hostel details and rooms bookings.
15 Hostel User “shall” request for Advertisements.
16 Admin User “shall” manage the Advertisements.
17 Student User “shall” request for termination of registration.
18 Hostel User “shall” confirm the termination.
19 Hostel User “shall” change the account password.
20 Hostel User “shall” request for termination of Hostel registration.
21 Admin User “shall” cancel Hostel Registration.
22 Hostel User “shall” get notification of termination of Hostel registration.
23 Admin User “shall” change the account password.

7
2.2.7. Allocate Requirements:
Sr. Initial Requirements Use Case Name

No
1 Hostel User “shall” register his/her Hostel. UC H Registration
2 Admin User “shall” login to the system. UC Admin Login
3 Admin User “shall” confirm/reject the Hostel UC H Reg. Request

Registration.
4 Hostel User “shall” get notifications of UC H get Notification
registration.
5 Student User “shall” search the Hostel. UC search Hostel
6 Student User “shall” select any Hostel. UC select Hostel
7 Student User “shall” place order of booking. UC Booking Order
8 Student User “shall” register herself/himself. UC S Registration
9 Hostel User “shall” login to the system. UC H Login
10 Hostel User “shall” confirm/reject the booking UC S Booking Request

order.
11 Hostel User “shall” confirm/reject the registration UC S Reg. Request
of Student User.
12 Student User “shall” get notifications of order and UC S get Notification
registration.
13 Student User “shall” give feedback. UC Feedback
14 Hostel User “shall” manage the Hostel details and UC update H
rooms bookings.
15 Hostel User “shall” request for Advertisements. UC Ads
16 Admin User “shall” manage the Advertisements. UC process Ads
17 Student User “shall” request for termination of UC req. S Termination
registration.
18 Hostel User “shall” confirm the termination. UC process S Termination
19 Hostel User “shall” change the account password. UC H password
20 Hostel User “shall” request for termination of UC req. H Termination
Hostel registration.
21 Admin User “shall” cancel Hostel Registration. UC process H Termination
22 Hostel User “shall” get notification of termination UC H get Notification
of Hostel registration.
23 Admin User “shall” change the account password. UC A password

8
2.2.8. Priorities Requirements:
Sr. Rank Initial Requirements Use Case Use Case Name

No ID
1 Highest Hostel User “shall” register UC_1 UC H Registration
his/her Hostel.
2 Lowest Admin User “shall” login to the UC_2 UC Admin Login
system.
3 Highest Admin User “shall” confirm/reject UC_3 UC H Reg. Request
the Hostel Registration.
4 Medium Hostel User “shall” get UC_4 UC H get
notifications of registration. Notification
5 Lowest Student User “shall” search the UC_5 UC search Hostel
Hostel.
6 Medium Student User “shall” select any UC_6 UC select Hostel
Hostel.
7 Highest Student User “shall” place order UC_7 UC Booking Order
of booking.
8 Highest Student User “shall” register UC_8 UC S Registration
herself/himself.
9 Lowest Hostel User “shall” login to the UC_9 UC H Login
system.
10 Highest Hostel User “shall” confirm/reject UC_10 UC S Booking
the booking order. Request
11 Medium Hostel User “shall” confirm/reject UC_11 UC S Reg. Request
the registration of Student User.
12 Lowest Student User “shall” get UC_12 UC S get
notifications of order and Notification
registration.
13 Lowest Student User “shall” give UC_13 UC Feedback
feedback.
14 Lowest Hostel User “shall” manage the UC_14 UC update H
Hostel details and rooms
bookings.
15 Lowest Hostel User “shall” request for UC_15 UC Ads
Advertisements.
16 Lowest Admin User “shall” manage the UC_16 UC process Ads
Advertisements.
17 Medium Student User “shall” request for UC_17 UC req. S
termination of registration. Termination
18 Medium Hostel User “shall” confirm the UC_18 UC process S
termination. Termination
19 Lowest Hostel User “shall” change the UC_19 UC H password
account password.
20 Medium Hostel User “shall” request for UC_20 UC req. H
termination of Hostel registration. Termination
21 Medium Admin User “shall” cancel Hostel UC_21 UC process H
Registration. Termination
22 Lowest Hostel User “shall” get UC_4 UC H get

9
notification of termination of Notification

23 Lowest Admin User “shall” change the UC_22 UC A password
account password.
2.2.9. Requirements Traceability Matrix:
Sr. Build Initial Requirements Category Use Case Name

No
1 B1 Hostel User “shall” register Business UC H Registration
his/her Hostel.
2 B1 Admin User “shall” login to the Business UC Admin Login
system.
3 B1 Admin User “shall” confirm/reject Business UC H Reg. Request
the Hostel Registration.
4 B1 Hostel User “shall” get Business UC H get
notifications of registration. Notification
5 B1 Student User “shall” search the Business UC search Hostel
Hostel.
6 B1 Student User “shall” select any Business UC select Hostel
Hostel.
7 B1 Student User “shall” place order Business UC Booking Order
of booking.
8 B1 Student User “shall” register Business UC S Registration
herself/himself.
9 B1 Hostel User “shall” login to the Business UC H Login
system.
10 B1 Hostel User “shall” confirm/reject Business UC S Booking
the booking order. Request
11 B1 Hostel User “shall” confirm/reject Business UC S Reg. Request
the registration of Student User.
12 B1 Student User “shall” get Business UC S get
notifications of order and Notification
registration.
13 B1 Student User “shall” give Business UC Feedback
feedback.
14 B1 Hostel User “shall” manage the Business UC update H
Hostel details and rooms
bookings.
15 B1 Hostel User “shall” request for Business UC Ads
Advertisements.
16 B1 Admin User “shall” manage the Business UC process Ads
Advertisements.
10
17 B1 Student User “shall” request for Business UC req. S

termination of registration. Termination
18 B1 Hostel User “shall” confirm the Business UC process S
termination. Termination
19 B1 Hostel User “shall” change the Business UC H password
account password.
20 B1 Hostel User “shall” request for Business UC req. H
termination of Hostel registration. Termination
21 B1 Admin User “shall” cancel Hostel Business UC process H
Registration. Termination
22 B1 Hostel User “shall” get Business UC H get
notification of termination of Notification
23 B1 Admin User “shall” change the Business UC A password
account password.
2.2.10. High Level Use case Diagram:

11
2.11. Analysis Level Use Case Diagram

Analysis level use case diagram is actually the explanation of high level use case
diagram. In this diagram high level use case are expanded in a way that exhibit how high
level use case will reach to their functionality. Two types of relationships are used in this
diagram. Which are:
 Extend
 Include

12
2.2.12. Use case Description
Admin Login Case
Use Case ID: UC_1
Use Case Name: UC Admin Login
Goal/Purpose: To Login as Admin User
Actors: Admin User
Pre-Condition: Admin User must have an Account
Post-Condition: Login Successful
Basic Flow: Login (Main Screen)
Exception Flow(s): Display errors for invalid account or password
Hostel Registration Request Case
Use Case ID: UC_2
Use Case Name: UC H Reg. Request
Goal/Purpose: Confirm/reject Hostel Registration
Actors: Admin User
Pre-Condition: User must submit Hostel registration form
Post-Condition: Notification will be send to Hostel User
Basic Flow: Request (Admin Login)
Hostel Selection Case
Use Case ID: UC_3
Use Case Name: UC select Hostel
Goal/Purpose: To see Hostel and place order
Actors: Student User
Pre-Condition: Hostel must be registered on system
Post-Condition: Selected Hostel details will be shown and order will be sent
Basic Flow: Main Screen
Exception Flow(s): Display errors if Hostel is not registered

13
Room Booking
Use Case ID: UC_4
Use Case Name: UC Booking Room
Goal/Purpose: To place order for booking
Pre-Condition: Student User must select Hostel and room
Post-Condition: Request will send to Hostel User
Basic Flow: Room Booking
Exception Flow(s): Display errors if room is not available
Student Registration Case
Use Case ID: UC_5
Use Case Name: UC S Registration
Goal/Purpose: To register student as allotted
Pre-Condition: Student User must fill student registration form
Post-Condition: Request will be send to Hostel User
Basic Flow: Main Screen (Booking)
Exception Flow(s): Display errors for invalid info. In registration form.
Hostel Login Case
Use Case ID: UC_6
Use Case Name: UC H Login
Goal/Purpose: To Login Hostel
Actors: Hostel User
Pre-Condition: Hostel must be registered
Post-Condition: Hostel User will be login
Basic Flow: Login (Main Screen)
Exception Flow(s): Display errors for invalid user or password
Student Registration Request Case

14
Use Case ID: UC_7
Use Case Name: UC S Reg. Request
Goal/Purpose: To register student
Actors: Hostel User
Pre-Condition: Student User must fill student registration form
Post-Condition: Notification will be sent to Student user
Basic Flow: Request (Hostel Login)
Exception Flow(s): Display no request
Feedback Case
Use Case ID: UC_8
Use Case Name: UC Feedback
Goal/Purpose: To make Hostel rating
Pre-Condition: Student User must be allotted
Post-Condition: Feedback will be added on system
Basic Flow: Main Screen
Exception Flow(s): Display errors for invalid user
Update Hostel Details Case
Use Case ID: UC_9
Use Case Name: UC update H
Goal/Purpose: To update Hostel Details
Actors: Hostel User
Pre-Condition: Hostel User must Login
Post-Condition: Hostel Details Updated
Basic Flow: Hostel Login
Exception Flow(s): Display errors invalid user or password if not login
Process Student Reg. Termination Case
Use Case ID: UC_10

15
Use Case Name: UC process S Termination
Goal/Purpose: To terminate Student registration
Actors: Hostel User
Pre-Condition: User must request for termination of registration
Post-Condition: Notification will be send to Student User
Basic Flow: Hostel Login
Exception Flow(s): Display no request
Hostel Change Password Case
Use Case ID: UC_11
Use Case Name: UC H password
Goal/Purpose: To change Hostel User Password
Actors: Hostel User
Pre-Condition: User must put previous password
Post-Condition: Password will be changed
Basic Flow: Hostel Login (Security)
Exception Flow(s): Display errors invalid previous password
Admin Change Password Case
Use Case ID: UC_12
Use Case Name: UC A Password
Goal/Purpose: To Change Admin User Password
Actors: Admin User
Pre-Condition: Admin User must put old password
Post-Condition: Password will be changed
Basic Flow: Admin Login (Settings)
Exception Flow(s): Display error wrong old password
Chapter 3: Design Document
3.1. Introduction
Third deliverable is all about the software design of “Hostel Tracking”. In the previous
deliverable, analysis of the system is completed. So, we understand the current situation
of the problem domain. Now we are ready to strive for a solution for the problem domain
16
by using object-oriented approach. Following artifacts must be included in the 3 rd

deliverable.
1. Domain Model
2. System Sequence Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. Operation Contracts
6. Design Class Diagram
7. State Transition Diagram
8. Data Model
3.2. Domain Model

Domain models represent the set of requirements that are common to systems within a
product line. There may be many domains, or areas of expertise, represented in a single
product line and a single domain may span multiple product lines. A domain model is an
"incomplete" business model, in that it omits individual worker responsibilities. The point
of domain modeling is to provide "the big picture" of the interrelationships among
business entities in a complex organization.
Domain Model diagram is the UML diagram which is used to depict behaviors and
entities of a system with respect to particular domain.
In Domain Model analysis of “Nawaz Sharif College Hostel Management System”, we
found the following entities and behaviors.
Admin user
a) Login
b) Edit Profile
c) H reg. Request
d) Process H Termination
e) Select Hostel
f) View Hostel details
g) Process Ads
Student user
a) Search Hostel
b) View Hostel details
c) Booking hostel
d) S Registration
e) S get Notification
f) Feedback
g) Req. S Termination
Hostel user
a) H Registration
b) Login
c) Edit Profile

17
d) Update Hostel
e) H get Notification
f) Ads
g) S Booking Request
h) S Reg. Request
i) View Hostel details
j) Process S Termination
k) req. H Termination
Figure 3.1: Domain Model Diagram
3.3 System Sequence Diagram

The UML system sequence diagram (SSD) illustrates events sequentially input from an
external source to the system. The SSD will define the system events and operations
System sequence diagrams are a timeline drawing of an expanded use case. Events are
related by time with the top events occurring first. System events are the important items.
These are events that cause a system response. Use case text may be placed on the left
side of the system sequence diagram if desired. If this is done it is best if the use case
information lines up with the events in the system sequence diagram.
System Sequence Diagram of “Hostel Tracking” has following main actors named:
1. Admin User
2. Student User
3. Hostel User
These actors will interact with the system as:

18
Figure 3.2: System Sequence Diagram
3.4. Sequence Diagram
Sequence Diagram used to show the interaction of actors with the different behaviors or
objects of the system in relevance to the time.
There will be following objects in our system:

a) Admin User
b) Login
c) Profile
d) Request

19
e) Student User
f) Hostel User
g) Sin Up
System Sequence Diagram for Admin User
Figure 3.3: System Diagram (Admin User)
System Sequence Diagram for Student User

20
Figure 3.4: System Diagram (Student user)
System Sequence Diagram for Hostel User

21
Figure 3.4b: System Diagram (Hostel user)
3.5. Collaboration Diagram

A collaboration diagram describes a pattern of interaction among objects; it shows the
objects participating in the interaction by their links to each other and the messages that
they send to each other.

22
Sr # Entity 1 Relationship Entity 2

1 Admin user Login Login
2 Admin user Request Process request
3 Admin user Profile Update profile
4 Student user Search hostel searching
5 Student user Select hostel See and book hostel
Submit registration
6 Student user request
form
7 Student user Feedback Give feedback
8 Hostel user Signup Fill registration form
Process booking
9 Hostel user Booking request
request
Send rejection to
10 Hostel user Rejection
student
Change hostel
11 Hostel user Update profile details, change
password
Table 3.5: Collaboration Diagram Table
Collaboration Diagram:
Figure 3.6: Collaboration Diagram
3.6. Operation Contracts

A UML Operation contract identifies system state changes when an operation happens.
Effectively, it will define what each system operation does. An operation is taken from a

23
system sequence diagram. It is a single event from that diagram. A domain model can be
used to help generate an operation contract.
Operation Contract Syntax
Name: student registration
Responsibilities: To register a student
Cross References: System functions and Use Cases
Exceptions: online payment
Preconditions: Student registration requests
Post conditions: Students have registered
3.7. Design Class Diagram
Figure 3.7: Class Diagram
3.8. State chart diagram

For some operations, the behavior of the operation depends upon the state the receiver
object is in. A state diagram is a tool for describing the states of objects that can assume
and the events that cause the object to move from one state to another. State diagrams are
most useful for describing active classes. The use of state diagrams is particularly

24
important for defining the behavior. An example of a simple state diagram of

management system is shown below:
Figure 3.8: State Chart Diagram
3.9. Data Model

A hostel management system was designed to provide a computerized process that is
stress free, reliable and quick through the use of different computer programming
language and MySQL database application to both the students and the staff in charge of
the registration and hostel management processes.
Entitles in our system:

25
a) Admin User
b) Student User
c) Hostel User
d) login
e) Beds
f) Allotting
g) Room

26

Hostel Management System Proposal

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hostel Management System Proposal

Uploaded by

Copyright:

Available Formats

IT- UOG - Project Coordination Office Version: 1.

Department of Information Technology

Nawaz Sharif College Hostel Management System

M. Hamza Nasir 16451556-080

Karam Bakhsh 16451556-027

Raas Ul Farooq 16821556-002

© Department of Information Technology.

© Department of Information Technology.

Second Deliverable For Object Oriented Approach

Chapter 2: System Requirement Specification

© Department of Information Technology.

Requirements specification is to be discussed. Requirements specification would lead to

The Identification of External Entities is done in two phases.

a. Over Specify Entities from Abstract:

© Department of Information Technology.

2.1.4. Capture "shall" Statements:

2.1.5. Allocate Requirements:

2.1.6. Prioritize Requirements:

2.1.7. Requirements Trace-ability Matrix:

2.2.2. Existing System

© Department of Information Technology.

Business Organizational Chart:

2.2.3. Scope of the System

2.2.4. Summary of Requirements :( Initial Requirements)

© Department of Information Technology.

2.2.6. Capture "shall" Statements:

2 Admin User “shall” login to the system.

3 Admin User “shall” confirm/reject the Hostel Registration.

4 Hostel User “shall” get notifications of registration.

5 Student User “shall” search the Hostel.

6 Student User “shall” select any Hostel.

7 Student User “shall” check his/her registration.

8 Student User “shall” register herself/himself.

9 Hostel User “shall” login to the system.

10 Hostel User “shall” confirm/reject the hostel booking.

© Department of Information Technology.

2.2.7. Allocate Requirements:

Sr. Initial Requirements Use Case Name

2 Admin User “shall” login to the system. UC Admin Login

3 Admin User “shall” confirm/reject the Hostel UC H Reg. Request

6 Student User “shall” select any Hostel. UC select Hostel

7 Student User “shall” place order of booking. UC Booking Order

8 Student User “shall” register herself/himself. UC S Registration

9 Hostel User “shall” login to the system. UC H Login

10 Hostel User “shall” confirm/reject the booking UC S Booking Request

© Department of Information Technology.

2.2.8. Priorities Requirements:

Sr. Rank Initial Requirements Use Case Use Case Name

© Department of Information Technology.

notification of termination of Notification

2.2.9. Requirements Traceability Matrix:

Sr. Build Initial Requirements Category Use Case Name

17 B1 Student User “shall” request for Business UC req. S

2.2.10. High Level Use case Diagram:

© Department of Information Technology.

2.11. Analysis Level Use Case Diagram

© Department of Information Technology.

2.2.12. Use case Description

Admin Login Case

Use Case ID: UC_1

Use Case Name: UC Admin Login

Goal/Purpose: To Login as Admin User

Actors: Admin User