Group 4 – Hotel Management System – HE186090 - Use Case Specification v.2.

<LOGO>

<Hotel Management System>

Use Case Specification

<Nghê An,01/07/2024>
Group 4 – Hotel Management System – HE186090 - Use Case Specification v.2.0

RECORD OF CHANGE

*A - Added M - Modified D - Deleted

Effecti Changed Items A* Change Description New

ve M, D Version
Date

FU- I2SE 2/43

Group 4 – Hotel Management System – HE186090 - Use Case Specification v.2.0

SIGNATURE PAGE

ORIGINATOR: <Name> <Date>

<Position>

REVIEWERS: <Name> <Date>

<Position>

<Name, if it’s needed> <Date>

<Position>

APPROVAL: <Name> <Date>

<Position>

FU- I2SE 3/43

Group 4 – Hotel Management System – HE186090 - Use Case Specification v.2.0

TABLE OF CONTENTS

1 INTRODUCTION..........................................................................5

1.1 Purpose....................................................................................................... 5

1.2 Scope.......................................................................................................... 5

1.3 Definitions, Acronyms, and Abbreviations...................................................5

1.4 Assumptions And Constraints......................................................................6

1.5 References.................................................................................................. 6

1.6 Overview..................................................................................................... 6

2 FUNCTION SPECIFICATION..........................................................7

2.1 Overview..................................................................................................... 7

2.2 Entity Description........................................................................................ 7

2.3 Business Process.........................................................................................7

2.4 Use Case Diagram.......................................................................................7

2.5 Use Case Details......................................................................................... 7

3 SUPPORTING INFORMATION.....................................................11

FU- I2SE 4/43

<Project code> - Use Case Specification v.xx

1 INTRODUCTION

1.1 Purpose

The purpose of this Software Requirements Specification (SRS) document is to provide a

detailed description of the functionalities and requirements for the room booking system.
This system is designed to facilitate the management of room bookings by allowing
users to perform various operations such as logging in, logging out, managing
passwords, viewing room details, booking rooms, and updating or canceling bookings.
The primary stakeholders for this system include end-users who will book rooms, system
administrators, and maintenance personnel.

1.2 Scope

This SRS document applies to the room booking system that will be implemented as a
web-based application. The system aims to streamline the process of room booking by
providing an intuitive interface and robust functionalities to handle all aspects of booking
management. The scope of this document includes the definition of the system
functionalities, user interactions, performance requirements, and any constraints that
must be adhered to during the development and deployment of the system.

1.3 Definitions, Acronyms, and Abbreviations

 SRS: Software Requirements Specification

 User: An individual who interacts with the room booking system to perform
operations like booking a room, viewing room details, etc.
 Admin: A user with additional privileges to manage system settings and user
accounts.
 Booking: The act of reserving a room for a specified time period.
 System: Refers to the room booking application.
 Login: The process by which a user gains access to the system by providing
credentials.
 Logout: The process by which a user exits the system.

1.4 Assumptions And Constraints

 The system will be accessed via standard web browsers.

 Users must have an internet connection to use the system.
 User authentication will be required for accessing booking-related functionalities.

FU- I2SE 5/43

<Project code> - Use Case Specification v.xx

 The system will handle a maximum of 1000 concurrent users.

 The database will be capable of storing up to 10,000 room bookings.

1.5 References

1.6 Overview

This SRS document is organized into several sections, each addressing different aspects
of the system requirements. The following sections will detail the functionalities of the
system, including user login/logout, password management, room listing, booking and
cancellation of rooms, and viewing and updating booking information. Each section will
specify the functional requirements, user interactions, and any constraints or
assumptions specific to that functionality. This comprehensive approach ensures that all
stakeholders have a clear understanding of the system's capabilities and requirements.
customer’s organization will be responsible for maintaining the delivered software).>

FU- I2SE 6/43

<Project code> - Use Case Specification v.xx

2 FUNCTION SPECIFICATION

2.1 Overview

1. Check room avalability

- Purpose: Allow receptionist to view room status to support guest for

booking rooms

- Functionality : receptionist can view list of room and their status

2. Confirm check-in

- Purpose: Confirm guest booking information and giving room key

- Functionality : receptionist receive confirmation from guest about their

information to finish check-in progress.

3. Process Payment

- Purpose: present bill, confirm payment and finish check-out process for
guess

- Functionality: receptionist present and explain bill for guest, support

payment method and confirm to create invoice

4. View guest

- Purpose : view detail information of selected guest

- Functionality: receptionist can check detail of guest and report back to

guest if there is any issue to update.

5. Update guest

- Purpose: update data for selected guest

- Functionality: receptionist update new information or correct wrong data

for guest

6. Input guest

- Purpose: Add information for new guest

- Functionality: receptionist input data for guest who has been on system.

7. Update booking information

- Purpose : update new or correct information

- Functionality: receptionist update booking data if there is change in guest

information.

8. Add room services and food items

FU- I2SE 7/43

<Project code> - Use Case Specification v.xx

- Purpose: guest can pick up food or select services for themselves.

- Functionality: guest can choose from services list and see services or food
items price and description.

9. Process maintenance request

- Purpose: manager receive maintenance request and handle request

- Functionality: manager can see request detail and choose employee to

solve the problem.

10. Reset password

- Purpose: Admin can reset password for hotel staff

- Functionality: admin receive request and process .

2.2 Entity Description

1. User

 Attributes:

 UserID: Unique identifier for each user.

 Username: The login name of the user.

 Password: The password for the user account.

 Role: The role of the user (Receptionist, Housekeeper, Admin, Guest).

 Email: The email address of the user.

 Description: Represents any individual who interacts with the room booking
system. Users can be categorized into different roles such as Receptionist,
Housekeeper, Admin, and Guest, each with specific permissions and
functionalities.

2. Room

 Attributes:

 RoomID: Unique identifier for each room.

 RoomNumber: The number assigned to the room.

 Capacity: The maximum number of occupants the room can

accommodate.

 Features: A list of features available in the room (e.g., Wi-Fi, TV, Air
Conditioning).

 Availability: The availability status of the room (Available/Booked).

FU- I2SE 8/43

<Project code> - Use Case Specification v.xx

 Description: Represents a physical room that can be booked by users. Each

room has unique attributes and may have different features and capacity.

3. Booking

 Attributes:

 BookingID: Unique identifier for each booking.

 UserID: The ID of the user who made the booking.

 RoomID: The ID of the room that has been booked.

 BookingDate: The date when the booking was made.

 StartDate: The start date of the booking.

 EndDate: The end date of the booking.

 Status: The status of the booking (Confirmed/Cancelled).

 Description: Represents the reservation of a room by a user. It includes details

about the booking period and the status of the booking.

4. Password Reset Request

 Attributes:

 RequestID: Unique identifier for each password reset request.

 UserID: The ID of the user who requested the password reset.

 RequestDate: The date when the password reset request was made.

 ResetToken: A unique token used to verify the password reset request.

 ExpiryDate: The expiry date of the reset token.

 Description: Represents a request made by a user to reset their password. It

includes the details of the request and the token used to verify the request.

5. Role

 Attributes:

 RoleID: Unique identifier for each role.

 RoleName: The name of the role (Receptionist, Housekeeper, Admin,

Guest).

 Permissions: A list of permissions associated with the role.

 Description: Represents the different roles available in the system, each with
specific permissions that define what actions the users with that role can perform.

2.3 Business Process

 Check room avalability

FU- I2SE 9/43

<Project code> - Use Case Specification v.xx

o Business process : if guest have not booked room and want to directly
book in the reception desk , receptionist can check room availability to
inform guest to start booking and check – in .

 Confirm check-in

o Business process : guest need to come to reception for complete check-in

procedure with , reception show the information about their information
and booking information to verify , after the guest confirm, reception also
confirm to system to update room status and get customer entry key.

 Process Payment

o Business process : after verify check – out process , bill will display to
reception to confirm for guest

 View guest information

o Business process : guest ask reception for information checking ->

receptionist view information-> reconfirm with guest

 Update guest information

o Business process : guest ask reception for information updating->

receptionist view information-> update data -> save to system

 Input guest information

o Business process : guest finish checks in ->add information for guest

accompanies -> receptionist input data -> save to system

 Update booking information

o Business process : booking information need update -> guest/receptionist

log in to system to update -> save to system

 Add room services and food items

o Business process : guest need to use services-> open app and choose
services/food items -> services deliver -> payment.

 Process maintenance request

o Business process : issue happen - > maintenance request created ->

manager receive request-> assign and send task - > employee fix issue

 Reset password

o Business process : user forgot password - > send reset request -> admin
process and reset-> send back new password.

FU- I2SE 10/43

<Project code> - Use Case Specification v.xx

2.4 Use Case Diagram

2.5

Use Case Details

2.5.1.1 Check room availability

2.5.1.1.1 Screen Definition

FU- I2SE 11/43

<Project code> - Use Case Specification v.xx

# Field Name Type Mandatory Max Length Description

1 Floor select Dropdow Yes Display floor to

n choose

2 5.8 Button Represent a room ,

click to display to
“Room infomation”
section

3 Room information Read-only Display room

informati infomation
on box

4 Book Button If the selected

room is”Available”
it will display
“Book” and go to
“Book Room” page
. If the selected
room is”Booked” it
will display “Check
in” and go to
“Check in” page

5 Back Button Go to home page

FU- I2SE 12/43

<Project code> - Use Case Specification v.xx

2.5.1.1.2 Use-case specification

FU- I2SE 13/43

<Project code> - Use Case Specification v.xx

Use-Case Description/Scenarios
Use-case ID UC0011 Author Nguyễn Đức Thắng

Use-case Name Check room availability Created Date 01/07/2024

Actor Reception Secondary Actor

Check available room of each floor in the hotel

Description

Precondition Reception successfully logs in to system

Trigger condition Reception clicks on Button “Room list” in main home page

Receptionist can see status of each room to place reservation or

Post-condition check-in for guest
 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other -

Business rules -

Main flows (normal flows)

Step Actor Action Description

Receptioni
1 st Click on Button “Room list” in homepage

Display Room list page with following flied:

- Floor select drop down
- a figure of that floor and room in that floor with its status
demonstated by colour
- a box of room infomation
2 Software - Book button

Receptioni
3 st Choose Floor from floor list and click to each room to see its detail

Display room detail in “Room infomation” box and “Check in”

4 Software button if it is booked if it is availaible then it will display “Booked”

Exception/(What went wrong)

# Description

FU- I2SE 14/43

<Project code> - Use Case Specification v.xx

2.5.1.2 Confirm check-in

2.5.1.2.1 Screen Definition

# Field Name Type Mandatory Max Length Description

1 Back to Room list Button Go back to Room

list page

2 Room detail Only Display detail of

read booked room
Display
box

3 Booking detail Only Display information

read of booking
Display infomation
box

4 Name Text Adjust Name

infomation if need

5 Phone Text Adjust Phone

infomation if need

6 Gender Radio Adjust Gender

FU- I2SE 15/43

<Project code> - Use Case Specification v.xx

box infomation if need

7 Social number Text Adjust Social

number infomation
if need

8 Book code Text Adjust Book code

infomation if need

9 Number of Aldult Number Adjust Number of

Aldult infomation if
need

10 Number of Number Adjust Number of

Children Children
infomation if need

11 Stay time Date Adjust Stay time

infomation if need

12 Adjust Booking Button Go to Booking

Detail infomation page

13 Check in Button Check in and go to

home page

2.5.1.2.2 Use-case Specification

FU- I2SE 16/43

<Project code> - Use Case Specification v.xx

Use-Case Description/Scenarios
Use-case ID UC0012 Author Nguyễn Đức Thắng

Use-case Name Confirm check-in Created Date 01/07/2024

Actor Reception Secondary Actor

Description Confirm check-in to guest

Precondition Guest has booked a room and want to check in

Trigger condition Reception clicks on Button “Check in” in “Room list” page

Post-condition Get to the “Payment page”

 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other

Reception can only check in for guests if guests can confirm their
Business rules infomation and confirm the booking details is correct

Main flows (normal flows)

Step Actor Action Description

FU- I2SE 17/43

<Project code> - Use Case Specification v.xx

Receptioni
1 st Go to “Check in” page

Display ”Check in“ page with following flied:

- Image of the room
- Room infomation box
- Booking infomation box
2 Software - Check in button

Receptioni Able to adjust Booking infomation and then click to “Check in”
3 st button

4 Software Confirm check in and go to home page

Exception/(What went wrong)

# Description

2.5.1.3 Process payment

2.5.1.3.1 Sceen Definition

FU- I2SE 18/43

<Project code> - Use Case Specification v.xx

# Field Name Type Mandatory Max Length Description

1 Back to check out Button Go back to check

out page

2 Bill Read Display detail of

only bill
Display
box

3 Pay method Radio Choose how to pay

box

4 Export bill Button Export bill

5 Fax bill Button Fax bill

6 Payment confirm Button Confirm payment

success

2.5.1.3.2 Use-case Specification

Use-Case Description/Scenarios
Use-case ID UC0013 Author

Use-case Name Process payment Created Date

Actor Receptionist Secondary Actor

Description Confirm guest has pay their bill

FU- I2SE 19/43

<Project code> - Use Case Specification v.xx

Receptionist successfully logs in system, guest confirmation of

Precondition check out

Trigger condition Click “Bill” in Check out page

Post-condition Confirm bill payment and complete check out for guest

Assumptions

Other

-Bill includes the room fee and all services that has been claim to
be (include in total bill) in Services menu , not includes direct
Business rules payment services like food items or souvenirs.

Main flows (normal flows)

Step Actor Action Description

Receptioni
1 st Click on “Bill” button in “Check out” page

Display ”Bill “ page with following flied:

- Bill information
- Pay method
- other services buttons
2 Software - Confirm button

Receptioni
3 st Use other services button (if need) , click on Payment confirm

4 Software Confirm payment and complete check out procedure for guest

Exception/(What went wrong)

# Description

2.5.1.4 View guest information

2.5.1.4.1 Screen Definition

FU- I2SE 20/43

<Project code> - Use Case Specification v.xx

# Field Name Type Mandatory Max Length Description

1 Back to Guest list Button Go back to guest

list page

2 Update Button Go to update page

to update
information

2.5.1.4.2 Use-case Specification

FU- I2SE 21/43

<Project code> - Use Case Specification v.xx

Use-Case Description/Scenarios
Use-case ID UC0014 Author

Use-case Name View guest information Created Date

Actor Receptionist Secondary Actor

Description View information of a guest

Precondition Receptionist successfully logs in to system

Trigger condition Click on “Detail” in selected guest in guest list

Post-condition Show out information of selected guest

 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other -

Business rules -

Main flows (normal flows)

FU- I2SE 22/43

<Project code> - Use Case Specification v.xx

Step Actor Action Description

Receptioni
1 st Go to “guest list”

Display ”Bill “ page with following flied:

- guest image
- guest information
- guest services
2 Software - Update button

Exception/(What went wrong)

# Description

2.5.1.5 Update guest information

2.5.1.5.1 Screen Definition

# Field Name Type Mandatory Max Length Description

FU- I2SE 23/43

<Project code> - Use Case Specification v.xx

1 Choose image Button Yes Choose avatar for

guest

2 name Text Yes 255 Input field

3 Phone Text Yes 255 Input field

4 Social Code Text Yes 255 Input field

5 Room Text Yes 255 Input field

6 Gender Radio Yes Input field

box

7 Type Dropdow Yes Input field

n

8 From Date yes Input field

9 To Date Yes Input field

10 Birthday Date Yes Input field

11 Save Button Save information

13 Cancel Button Erase information

return to “Guest
detail”

2.5.1.5.2 Use-case Specification

FU- I2SE 24/43

<Project code> - Use Case Specification v.xx

Use-Case Description/Scenarios
Use-case ID UC0015 Author

Use-case Name Update guest information Created Date

Actor Receptionist Secondary Actor

Description Update information of a guest

Precondition Receptionist successfully logs in to system

Trigger condition Click on “Update” in guest lnfomation

Post-condition Update data to database

 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other -

Business rules Guest infomation update of receptionnist role is only allowed under

FU- I2SE 25/43

<Project code> - Use Case Specification v.xx

request and permission of guest

Main flows (normal flows)

Step Actor Action Description

Receptioni
1 st In “guest information” page Click on “Update” button

Display ”Update Guest Infomation“ page with input fields with

guest old data
2 Software

Receptioni
3 st Update all required field and save

4 System System saves guest information into database

Exception/ (What went wrong)

# Description

2.5.1.6 Input Guest infomation

2.5.1.6.1 Screen Definition

FU- I2SE 26/43

<Project code> - Use Case Specification v.xx

# Field Name Type Mandatory Max Length Description

1 Back to Guest list Button Go back to guest

list page

2 Choose image Button Yes Choose avatar for

guest

3 name Text Yes 255 Input field

4 Phone Text Yes 255 Input field

5 Social Code Text Yes 255 Input field

6 Room Text Yes 255 Input field

7 Gender Radio Yes Input field

box

8 Type Dropdow Yes Input field

n

FU- I2SE 27/43

<Project code> - Use Case Specification v.xx

9 From Date yes Input field

10 To Date Yes Input field

11 Birthday Date Yes Input field

12 Save Button Save information

13 Cancel Button Erase information

2.5.1.6.2 Use-case Specification

Use-Case Description/Scenarios
Use-case ID UC0016 Author

Use-case Name Input guest information Created Date

FU- I2SE 28/43

<Project code> - Use Case Specification v.xx

Actor Receptionist Secondary Actor

Description Input information of a guest

Precondition Receptionist successfully logs in to system

Trigger condition Click on “Add” in guest list

Post-condition Create new Guest into guest list

 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other -

- Infomation of guest who places booking(room master) is

automaticaly saved after check in , just input other guest
Business rules who accompany with room master

Main flows (normal flows)

Step Actor Action Description

Receptioni
1 st Go to “guest list” click on “Add” Button

Display ”Bill “ page with input fields

2 Software

Receptioni
3 st Input all required field and save

4 System System save guest information into database

Exception/ (What went wrong)

# Description

FU- I2SE 29/43

<Project code> - Use Case Specification v.xx

2.5.1.7 Adjust or cancel reservations

2.5.1.7.1 Screen Definition

# Field Name Type Mandatory Max Length Description

1 Booking List Button Go to “Booking

List”

2 Choose image Button Yes Choose avatar for

guest

3 name Text Yes 255 Input field

4 Phone Text Yes 255 Input field

5 Social Code Text Yes 255 Input field

6 Room Text Yes 255 Input field

7 Gender Radio Yes Input field

box

FU- I2SE 30/43

<Project code> - Use Case Specification v.xx

8 Type Dropdow Yes Input field

n

9 From Date yes Input field

10 To Date Yes Input field

11 Birthday Date Yes Input field

12 Number of Aldult Number Yes 10 Input field

13 Number of Number Yes 10 Input field

Children

14 Check in Button Go to “Check in”

page

15 Cancel Reservation Button Cancel the

reservation and
delete booking
infomation

16 Save Button Save change to the

booking detail

2.5.1.7.2 Use-case Specification

Use-Case Description/Scenarios

FU- I2SE 31/43

<Project code> - Use Case Specification v.xx

Use-case ID UC0017 Author

Adjust or cancel
Use-case Name reservation Created Date

Actor Receptionist, guest Secondary Actor

Description Modify booking infomation or cancel reservaion

Precondition Receptionist successfully logs in to system, exit booking request

Guest ask reception to Modify booking infomation or cancel

Trigger condition reservaion

Post-condition Get to “booking detail” for modification or canceling

 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other

Adjust or cancel of reception role only happens under guest

Business rules request and permission

Main flows (normal flows)

Step Actor Action Description

click on button “Adjust booking detail” in “Confirm Check-in” page

1 User or “Booking list” page

Display ”Booking detail “ page with input fields

2 Software

3 User Adjust fields or cancel reservation

4 System System saves information into database

Exception/ (What went wrong)

# Description

FU- I2SE 32/43

<Project code> - Use Case Specification v.xx

2.5.1.8 Add room service and food items

2.5.1.8.1 Screen Definition

# Field Name Type Mandatory Max Length Description

1 Food Button Choose Service

2 Spa Button Choose Service

3 Travel Button Choose Service

4 Landry Button Choose Service

5 Babysitter Button Choose Service

FU- I2SE 33/43

<Project code> - Use Case Specification v.xx

6 Club Button Choose Service

7 Other Button Choose Service

8 Thịt chó Dropdow Service

n

9 Send service Button Send service

request request for
reception to
request

2.5.1.8.2 Use-case Specification

Use-Case Description/Scenarios
Use-case ID UC0018 Author
Add room service and food
items
Use-case Name Created Date

Actor Guest Secondary Actor

FU- I2SE 34/43

<Project code> - Use Case Specification v.xx

Description Guest add room service and food items

Precondition Guest check-in and has access to system

Trigger condition Guest click on “Service and Foods” button

Redirect to “Service and Foods” page and allow guest to Add room
service and food items
Post-condition
 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other

- Foods items and souvernir is not include in toltal bill but is

Business rules directly pay

Main flows (normal flows)

Step Actor Action Description

1 Guest click Guest click on “Service and Foods” button in home page

Display Services menu for selection

2 Software

3 Guest Select service and food

4 System Send service request to reception

Exception/ (What went wrong)

# Description

FU- I2SE 35/43

<Project code> - Use Case Specification v.xx

2.5.1.9 Process maintenance request

2.5.1.9.1 Screen Definition

# Field Name Type Mandatory Max Length Description

1 Homepage Button Go back to

homepage

2 Infomation Read_onl Display detaul

y infomation
informati
on
display
box

3 Room-issue : Item in clink on to select

room-5.1 request
list

4 Employee List Item list Display employee

with scoll
bar

5 Created by read-only Show created

informati employee
on

FU- I2SE 36/43

<Project code> - Use Case Specification v.xx

6 Request time read-only Show time that

informati request was
on created

7 Room read-only Show area that

informati have problem
on

8 Assign to : Read-only Show employee

HK0002-DatNp informati that is assigned to
on handle issue

9 Note Text area Message to

assigned employee

10 Send Button Send to

11 Cancel Button Cancel button

2.5.1.9.2 Use-case Specification

Use-Case Description/Scenarios

FU- I2SE 37/43

<Project code> - Use Case Specification v.xx

Use-case ID UC0019 Author

Process maintenance
Use-case Name request Created Date

Actor Manager Secondary Actor

Description Process Maintenance request by employee

Precondition Request is created by the employee base on real issue in the hotel

Trigger condition Manage click on “Maintenance Request list” in home page

Post-condition Display request list for manage to process

 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other

Business rules

Main flows (normal flows)

Step Actor Action Description

1 Manager Managers click on “Maintenance Request list” in home page

Display request list , detail box, employee list , note area , send
and cancel button
2 Software

3 Manager Process request , assign task

4 System Send task to selected employee

Exception/ (What went wrong)

# Description

FU- I2SE 38/43

<Project code> - Use Case Specification v.xx

2.5.1.10 Reset password

2.5.1.10.1 Screen Definition

# Field Name Type Mandatory Max Length Description

1 Reset Password Read-only Go back homepage

informati
on box

2 Request list List of Display request

request

3 Account:HK0006- List item Represent account

DatNP that need to reset

4 Request id Only read Account Id

field

5 User id Only read user`s id

field

FU- I2SE 39/43

<Project code> - Use Case Specification v.xx

6 Role Only read User`s role

field

7 User Name Only read User`s name

field

8 User phone Only read User`s phone

field

9 User email Only read User `s email

field

8 Set new Password Password Character auto

change to ‘*” when
in put

9 Reset password Button Change account`s

password to new
password

2.5.1.10.2 Use-case Specification

Use-Case Description/Scenarios

FU- I2SE 40/43

<Project code> - Use Case Specification v.xx

Use-case ID UC0020 Author

Use-case Name Reset password Created Date

Actor Admin Secondary Actor

Description Reset password for account

Precondition Admin successful log in to the system

Trigger condition Admins receive reset request

Post-condition account password is reset and set to new password

 User has a stable internet connection
 The system is assumed to be compatible with standard web
browsers.
Assumptions

Other

New password only valid in 24 h and user need to change

Business rules password at their first time log in back to system

Main flows (normal flows)

Step Actor Action Description

1 Admin click on “Account List ” button in home page

Display Account list, and information box of account

2 Software

3 Admin Input new password then click on ‘Reset password’ button

4 System Save change to database

Exception/ (What went wrong)

# Description

FU- I2SE 41/43

<Project code> - Use Case Specification v.xx

FU- I2SE 42/43

<Project code> - Use Case Specification v.xx

3 SUPPORTING INFORMATION

[The supporting information makes the SRS easier to use. It includes:

 Table of contents
 Index
 Appendices
These may include use-case storyboards or user-interface prototypes. When
appendices are included, the SRS should explicitly state whether or not the
appendices are to be considered part of the requirements.]

FU- I2SE 43/43