University of Bahrain

College of Information Technology

Department of Computer Engineering

LAUNDRY MANAGEMENT
SYSTEM
MOHAMMAD SHEHROZ 20175114
TALHA IFTIKHAR 20175237
DAWOOD RIAZ 20174221
MOHAMMAD TALHA 201776113

ITSE 220 Software Requirements Academic Year 2018-2019-

Engineering Semester 2.
Table of Contents
I. Introduction.............................................................................................................2
Aim
Why do we need a Laundry Management
System?
Scope
Product Perspective
II. Requirements...........................................................................................................3
Functional Requirements
Non-Functional Requirements
User Characteristics
Principle Stakeholder
General Constraints
Use Case Summary
III. Components...........................................................................................................11
Account Management
Services Management
Finance and Maintenance
Order Handling
IV. Interface.................................................................................................................28
Login Page
Admin UI
Customer UI
Future Extension
Introduction
Aim
The main purpose of this project is to present the design and implementation of a laundry
management system (LMS) that helps in managing and organizing the working structure of a
Laundry firm.

Why do we need a Laundry Management System?

Most Laundry firms use a traditional approach (i.e. paper-based) in managing their everyday
tasks such as keeping detailed records of customers; their clothing and other valuables. Using
this manual approach, records can be lost or have duplicates. This leads to issues such as mix-ups
and/or untimely retrieval of clothes and other valuable items.

In this paper, we propose a solution that aims to solve these technical problems and also provides
a service that monitors the resources available at the firm and make efficient use of it.

In general, the proposed system will greatly optimize the performance and efficiency of the
overall firm.

Scope
We describe what features are in the scope of the software and what are not in the scope of the
software to be developed.

In Scope:
 Allows the users to place and then keep track of their orders.
 Managing a customer, order and product database.
 Billing and transactions.
 User authentication.
 Admin can keep track of the services and products the system has to offer.
Out of Scope:
 Features for actual giving and receiving of items and goods done outside LMS.
 Tax computations for water, electricity and machines.
 Any market related promotions and sales.

MAY 2019 2
Product Perspective
The Laundry Management System is aimed towards fairly large firms that still rely on
manual methods of keeping records of different entities. The LMS should be user-friendly and
capable of handling a large number of users at a given time. This system is intended to be a
standalone project. LMS is a web-based system.

Requirements
Functional Requirements

Requirement ID Core-1
Title User Registration

Priority High
Description The system will be able to create and then manage user accounts.

Version 1.0

Requirement ID Database-1
Title User Data

Priority High
Description The system will store data of the user accounts in a database and assign
unique ids to each user.
Version 1.0

Requirement ID Core-2
Title Place Orders

Priority High
The system shall allow users to place orders. While placing orders, users
Description
can select the type of clothing, the quantity and the service from the
services database.

MAY 2019 3
Version 1.0

Requirement ID Core-3
Title Receive orders

Priority High
Description The system will be able to receive laundry orders from the users.

Version 1.0

Requirement ID Database-2
Title Store and organize orders

Priority High
Description The system will store laundry orders in a database with their customer
id’s.
Version 1.0

Requirement ID Core-4
Title Track Progress

Priority Medium
Description The system will allow users to track the progress of their orders.

Version 1.0

Requirement ID Database-3
Title Services Database

MAY 2019 4
Priority
Medium
Description The system will have a database dedicated to the services it provides along with
their costs.
Version 1.0

Requirement ID Core-5
Title Cancel Orders

Priority Low
Description The system will allow users to cancel their orders if they haven’t
deposited their laundry yet.
Version 1.0

Requirement ID Report-1
Title Generate Bill Reports

Priority Low
Description The system shall be able to generate reports of all the transactions.

Version 1.0

Requirement ID Report-2
Title Generate Order Reports

Priority Medium
Description The system shall be able to generate reports of the orders
received/delivered in a day/week/month.
Version 1.0

MAY 2019 5
Non-Functional Requirements

Requirement ID NONFUNC-Database-1
Title
Large Order Database
Priority
Medium
Description The system should be expected to handle at least 20 orders at a given time.

Version 1.0

Requirement ID NONFUNC-Database-2
Title
Large Customer Database
Priority
High
Description The system’s customer database should be able to store at least 100 entries.

Version 1.0

Requirement ID NONFUNC-Security-1
Title
Customer Privacy
Priority
High
Description The system shall not disclose customer details to any other person except
the administrators.
Version 1.0

MAY 2019 6
Requirement ID NONFUNC-Security-2
Title
System Security
Priority
High
Description The system shall only be accessed by authorized users. Customers will not
be able to have admin privileges.
Version 1.0

Requirement ID NONFUNC-Product-1
Title
Usability
Priority
Medium
Description The system’s UI should be easy to understand. Users should be able to
interact with the system with minimum effort.
Version 1.0

Requirement ID NONFUNC-Product-2
Title
Supportability
Priority
Low
Description The admin must be able to add/modify services without effecting the whole
system
Version 1.0

Requirement ID NONFUNC-Product-3
Title
Availability

MAY 2019 7
Priority
High
Description The system should be available 24/7.

Version 1.0

Requirement ID NONFUNC-Deployment-1
Title
Build Target
Priority
High
Description The system shall be web-based and can be accessed via a PC or a
smartphone.
Version 1.0

Requirement ID NONFUNC-Deployment-2
Title
SQL Server
Priority
Low
Description The system’s databases will be hosted on Microsoft SQL Server.

Version 1.0

Requirement ID NONFUNC-Deployment-3
Title
Hardware Specifications
Priority
High
Description The system should be able to run on any device with 2GB RAM and i3
processor equivalent (minimum).
Version 1.0

MAY 2019 8
User Characteristics
 User must be at least 17 years of age
 User must be familiar with using web based applications
 User must be familiar with the details of the payment methods

Principle Stakeholder
User
Some of the main tasks of the User are:
 Register to the system.
 Place orders
 Make Transactions

Admin
Some of the main tasks of the Admin are:
 View/ Manage/ Process user orders
 View/ Manage system products
 View/ Manage user accounts
 View/ Manage reports
General Constraints
 Laundry Management System requires internet connection
 User must be registered to the system for any operation
 The system must be developed using Microsoft .NET

Components
 Account Management (Talha Iftikhar)
 Order Handling (Talha Asif)
 Services Management (Muhammad Shehroz)
 Finance & Maintenance (Muhammad Dawood Riaz)

MAY 2019 9
 Use Case Summary
Class of use cases Use cases Description of use cases
Account Management Create account Creates an account
Login Login to account
Manage account Edit account
Manage User account Admin manages user account
Login As Admin Login for admin
Enter Details Enter detail to create an account
Order Handling Place Order Creates a new order
View Order and Edit View existing order and edit it
order Place an order
Place Order Remove an order
Cancel Order Enter details to place order
Enter details
Services Management Add product Add a new LMS service
Enter Details Enter details
Deliver Laundry System notifies admin the state of
Remove Services the laundry
validate Remove an existing service
Validate the details
Finance & Maintenance Check Transaction/Bills Summary of Bills
Make Report Display reports of all financial
transaction within LMS
Process Transaction Process the customer payment
View Complains/Errors Display customer complaints and
Resolve Complains system errors
View Transaction Solve the issues
History Display transactions
View Previous solutions Display previous solutions

MAY 2019 10
Components

Account Management
The Account Management component of the Laundry Management System
(LMS) is concerned with the creation, validation and authentication of user
accounts. This component also provides login functionality.

Use Case Diagram & scenarios

Use Case 1: Create a new user

MAY 2019 11
Primary Actor: User
Pre-Condition: nil
Main Scenario:
1. User opens the website or application.
2. User initiates create new user command.
3. The user will be sent to the new user register page
4. User enters his personal details.
5. The user will insert his user name and Password.
6. The user will confirm his creation of the account.

Alternate Scenario:
3(a): Enters invalid data
3(a) i: Invalid attribute value has been entered. The user might enter alphabets where the
phone number is required
3(a) ii: The user does not fill a required field.
3(a) iii: prompt a message to user to fill the full and valid requirements.

Use Case 2: Login

Primary Actor: User
Pre-Condition: Nil

Main Scenario:
1. Start the application. User prompted for login and password.
2. User gives the login and password.
Extension point: EX.Manage
3. System does authentication.
4. Display main screen.
Alternate Scenario:
3(a). Authorization fails
3(a) 1. Prompt the user that he typed the wrong password
3(a) 2. Allow him to re-enter the password. Give him three chances.

Use Case 3: Manage account

Primary Actor: User
Pre-Condition: user must be logged in
Main Scenario:

MAY 2019 12
At Extension Point: EX.Manage
1. The user is on the main screen.
2. The main screen gives the user the following options.
i. Change password
ii. Change personal details.
iii. Delete account
3. The user selects one of the options.
4. The user fails to change the information.
5. The user logs out.

Use Case 4: Login as Admin

Primary Actor: Admin
Pre-Condition: nil
Main Scenario:
1. Start the application. User prompted for login and password.
2. User gives the login and password.
3. System does authentication.
4. Main screen is displayed.
Extension Point: EX.AManage
Alternate Scenario:
4(a). Authorization fails
4(a) 1. Prompt the user that he typed the wrong password
4(a) 2. Allow him to re-enter the password. Give him 3 chances.

Use Case 5: Manage user accounts

Primary Actor: Admin
Pre-Condition: user must be logged in
Main Scenario:
At Extension Point: EX.AManage
1. The Admin is on the main screen.
2. The main screen gives the user the following options.
a. Find customer account.
b. Change customer account details.
c. Delete customers account.
3. The user fails to find the required account
MAY 2019 13
4. The user selects one of the options.
5. The user fails to change the information.
6. The user logs out.
Alternate Scenario:
3 (a) the admins writes the invalid username
3(a) 1: The admin will search again for the required customer account.
4(a): Enters invalid data
4(a) 1: Invalid attribute value is entered. The user might enter alphabets where the phone
number is required
4(a) 2: The Admin doesn’t fill a required field.
4(a) 3: prompt a message to user to fill the full and valid requirements.
UML Class Diagram

MAY 2019 14
Sequence Diagram

State Chart Diagram

MAY 2019 15
 Services Management
The Services Management component is only used by the Admin. Through this
component, the Admin can add new services/clothing types/wash-methods to the system.
This component also keeps the admin informed of the current state of the laundry.

Use Case Diagram & scenarios

Use Case 1: Add Services

Primary Actor: Admin
Pre-Condition: Must be logged in to the system

MAY 2019 16
Main Scenario:
1. The Admin logs into the system.
2. The Admin opens the Add Services window.
3. The Admin selects the category of the service.
4. The Admin enters the details of the new service.
5. The system verifies and validates the entry.
6. The Admin creates a new service.
Alternate Scenario:
3(a). The Admin enters invalid details for the new service.
3(b). The system prompts the Admin to re-enter the details.

Use Case 2: Remove Services

Primary Actor: Admin
Pre-Condition: Service must already exist in the system.

Main Scenario:
1. The Admin logs into the system.
2. The Admin opens the Remove Services window.
3. The Admin looks for the service and removes it.

Alternate Scenario:
3(a). The Admin doesn’t find the service to remove.

Use Case 3: Deliver Laundry

Primary Actor: Employee, Admin
Pre-Condition: Laundry must be ready.

Main Scenario:
1. The Admin logs into the system.
2. The system shows the Admin the list of all the laundry orders with their current
states.
3. The Admin looks for the orders with their state as ‘completed’ and sends it for
delivery.
Alternate Scenario:

MAY 2019 17
3(a). The Admin doesn’t find any order with the state as ‘completed’.

UML Class Diagram

Sequence Diagram

MAY 2019 18
State Chart Diagram

MAY 2019 19
 Finance and Maintenance
The Finance & Maintenance component covers the financial aspect of the LMS.
This includes generating bills, making transactions, viewing the current
expenses/budget of the system. The Maintenance part of this component handles
customer complaints to improve the system and generate customer reports.

Use Case Diagram & scenarios

Use Case 1: Transaction & Bills

Primary Actor: Admin

Pre-condition: Already logged into the system and have access.

Main Scenario:
1. Admin opens the website or application.
2. He goes to transactions and bills section.
3. He goes through every transactions and bills record.
Alternate Scenario:
1. Admin lost the network.
2. The Admin fails to get access.
3. The whole system shuts down.
MAY 2019 20
Use Case 2: Process Transaction.
Primary Actor: Admin
Pre-condition: Have gone through transaction and bill section.
Main Scenario:
1. Admin check amount of transaction and bills.
2. He pays bills and go through transaction records.
[Extension Point: TR: 00]
3. Admin fails to process transaction or bills.
4. He checks history and look for alternative method.

Use Case 3: Maintenance

Primary Actor: Admin

Pre-Condition: Already logged into system have access to maintenance section.

Main Scenario:
1. Admin go through complain and error record.
2. He finds out solution of problems.
3. He may go through history to find solution of error.
4. He makes report of problem and solution.
[Extension Point: MN: 00]
5. Admin cannot find the solution.
6. He checks previous records and look for solution.
Alternate Scenario:
1. Fails to access maintenance record.
2. Admin access wrong component
3. Fails to create solution.
Use Case: Make report

Primary Actor: Admin

Pre-Condition: Admin must have gone through transaction detail or Maintenance section.

Main Scenario:
1. Admin check report and bills record history
2. Admin create transaction and bill record separately.
3. Admin goes through Maintenance and System errors.

MAY 2019 21
4. He create record of maintenance and system’s solution separately.

Alternate Scenario:
1. Admin having trouble getting transaction details
2. Invalid Transaction.
3. Invalid report
4. Cannot process report.

UML Class Diagram

MAY 2019 22
Sequence Diagram

State Chart Diagram

MAY 2019 23
 Order Handling
The Order Handling component oversees all of the order related requests made on the
system. Operations like placing an order, reviewing an order, editing and cancelling
orders are covered in this component of the LMS.

Use Case Diagram & scenarios

Use Case 1: Place Order

Primary Actor: User
Pre-Condition: Must be logged into the system
Main Scenario:
1. Customer opens the website or application.
2. Customer login to the application
3. Customer places a new order
4. Customer enters the details of how the order should be washed.
Alternate Scenario:
4(a). Customer enters the wrong details which doesn’t match to the order type.

MAY 2019 24
Use Case 2: View Order & Edit Order
Primary Actor: User
Pre-Condition: The Customer should have placed the order
The Customer can edit their order if it is not in the process stage.
Main Scenario:
1. The Customer clicks to view his order
2. The Customer checks if his order is ready or not
3. The Customer can make changes to the order.

Use Case 4: Process order

Primary Actor: Admin
Pre-Condition: The admin should be locked in and the Customer should have placed an
order.

Main Scenario:
1. The Admin checks if there is any new order
2. If there is a new order the admin verifies it.
3. The admin checks if there is any order to be canceled
Extension point CO:01
Alternate Scenario:
2(a). If the order is not verified by the admin the admin informs the Customer to edit
his order

Use Case 5: Cancel Order

Primary Actor: Admin
Pre-Condition: The Customer should have placed the order
The order should be in the process
Main Scenario:
At extension point CO:01
1. The Customer informs the admin that he wants to cancel his order due to some
reason.
2. The admin checks if the order is not already processed
Alternate Scenario:
2(a). If the order is already processed the admin informs the Customer that the order is
processed and cannot be canceled.

MAY 2019 25
UML Class Diagram

Sequence Diagram

MAY 2019 26
State Chart Diagram

MAY 2019 27
Interface
Login Page

Admin UI

MAY 2019 28
MAY 2019 29
 Customer UI

MAY 2019 30
MAY 2019 31
Future Extension
The system is capable to deal with larger dataset. It will be compatible with any
smart device.

MAY 2019 32
MAY 2019 33