FACULTY OF COMPUTING AND INFORMATION

MANAGEMENT

BACHELOR OF SCIENCE IN INFORMATION AND

TECHNOLOGY

SYSTEM REQUIREMNT SPECIFICATION

By:

16/05985

ROTICH TIMOTHY KIPNGENO

Supervised by:

Sir. Ernest Madara

Date:

25/10/2023
 Table of Contents

1.0. Introduction..........................................................................................................................................3
1.1. Purpose.............................................................................................................................................3
1.2. Scope................................................................................................................................................4
1.3. Acronyms and Abbreviations............................................................................................................5
1.4. Overview...........................................................................................................................................5
2.0. General description..............................................................................................................................5
2.1. System perspective...........................................................................................................................6
2.2. System functionality.........................................................................................................................7
2.3. User Characteristics..........................................................................................................................8
2.4. General constraints...........................................................................................................................9
2.5. Assumptions and dependencies.......................................................................................................9
3.0. Specific requirements.........................................................................................................................10
3.1. Functional requirements.................................................................................................................11
3.2. User Interface requirements...........................................................................................................11
3.2.1. Minimum Hardware Specifications..........................................................................................11
3.3. Software interfaces.........................................................................................................................12
3.4. Communication interface...............................................................................................................13
APPENDICES...............................................................................................................................................14
Glossary of terms...................................................................................................................................14
Use-case diagram...................................................................................................................................14
1.0. Introduction

1.1. Purpose
The purpose of this SRS document is to cover the overall description of the software system of Kamala
restaurant inventory management system, specifically the system’s product perspective, hardware,
software and communication interfaces, memory constraints, operations, site adaptation requirements,
functions, characteristics, some constraints, assumptions and dependencies. This SRS also detail the
system’s specific requirements, specifically requirements on performance, logical database, design
constraints, software system attributes such as reliability, availability, security, maintainability and
portability, system mode, user class, objects, features. Lastly, this SRS is intended for the stakeholders
and management of the Kamala dishes in general, and the systems engineers, analysts, designers,
implementers, testers, maintenance, and the users themselves.
This SRS will document further changes, revisions and additions to any requirement and functionality of
the software system.
A case study at „Kamala‟ (an on-site corporate restaurant and catering business) cited issues regarding a
basic resources requirement list that must be maintained manually by the staff. To keep track of their
inventory levels they have to calculate a list of the groceries utilized during a course of time, calculate
and analyze the requirements for the future, and place their next order to the vendors if needed. This
process takes up a lot of time and human effort and is also prone to human error. This poses a problem
of a situation that the staff at „Kamala, ‟ as well as many other restaurants faces. It takes a lot of time to
manually keep track of sales and place correct orders to vendors, wasting useful labor in trivial works. A
product which would assist in tackling the above-mentioned problems would prove to be fruitful to
clients such as “Kamala” and similar enterprises as this product would help convert the unproductive
time to something more useful, by removing the unnecessary error prone complications and efforts.
1.2. Scope
The restaurant inventory management system aims at providing an efficient interface to the restaurants
for managing their grocery inventory based on each item sold. The basic idea involved here is that each
item is linked to its atomic ingredients which are stored in a database. At the end of each day, the
system analyzes the total sale of menu items and proportionately deducts appropriate amount from the
resource database. Then it compares the current available resources with the minimum level of each
ingredient. If it finds that certain ingredients are below the minimum, it will generate a purchase order
for those item(s) and send it to the manager (admin) for approval. We also propose to include a special
feature “Prediction”. This feature keeps track of any upcoming occasions, climatic changes and special
events that may influence inventory needs for the upcoming week. The system will then predict the
required resources for these events based on previously accumulated information/knowledge. It will
now generate an updated purchase order in accordance with the predictions. The product also aims to
keep track of the shelf life of resources. If any resource nears the end of its shelf life, it would intimate to
the manager (admin) the details of the quantity that is near its expiration date. The restaurant must
function efficiently, the groceries must be tracked correctly, timely orders must be sent out to the
vendors, and the inventory must be maintained and updated at all times.

1.3. Acronyms and Abbreviations

SRS – Software Requirements Specification
DBMS – Database management system
RIMS – Restaurant Inventory Management System.
LAN – Local Area Network
HTTP – Hypertext Transfer Protocol
SQL – Structured Query Language
OS – Operating System
API – Application Programming Interface
JSON – JavaScript Object Notation
XML – Extensible markup language
1.4. Overview
The structure of this SRS is as follows. Section 2 presents an overall description of the software system
RIMS. Attention is given to putting the resultant software product into perspective and further outlining
end-user characteristics. Section 3 is devoted to the specification of software requirements the
functional requirements and user-interface requirements.

2.0. General description

The following section presents an overall description of the subject RIMS. In particular, the product has
been put into perspective through a detailed assessment of the system, user, hardware, software and
communication interfaces, memory considerations, operational modes and site adaptation
requirements. Further, characteristics of the system’s end-users are discussed along with the identified
system constraints and assumptions. To conclude the section, an apportioning of requirements has been
outlined.

2.1. System perspective

The software described in this SRS is the software for a complete RIMS system. The system merges
various hardware and software elements and further interfaces with external systems. Thus, while the
software covers the majority of the system's functionality, it relies on several external interfaces for
persistence and unhandled tasks, as well as physically interfacing with humans.
The RIMS interfaces with an existing payment system, including a cash register and software-accessible
credit system, to quickly and easily handle inventory.
 Fig. 1

2.2. System functionality

The restaurant inventory management system is a comprehensive software solution designed to
optimize and simplify inventory control and management for foodservice establishments. The system
provides the following key functionality:
  Inventory Management:
Efficiently manage and track inventory items, including food, beverages, and supplies.
Categorize items for easy organization and management.
Set reorder points to prevent stockouts and automate reordering.
 User Authentication and Authorization:
Secure user authentication with role-based access control.
Define different user roles (e.g., employees, managers) with specific permissions.
 Transaction Tracking:
Record all inventory-related transactions, including receiving orders, item usage, and sales.
Maintain a comprehensive transaction history for auditing and reporting.
 Real-Time Alerts:
Receive real-time alerts for low-stock items, enabling proactive restocking.
Customizable alert thresholds and notifications for key staff members.
 Reporting and Analytics:
Generate customizable inventory reports, such as low-stock reports and transaction history.
Visualize inventory data using charts and graphs for data-driven decision-making.
 Supplier Management:
Manage supplier information, including contact details and pricing agreements.
Easily associate inventory items with their respective suppliers.

We propose to develop software that keeps track of inventory in the “back of house”, or kitchen, and
updates it according to daily sales, changes in inventory are kept track of through utilizing a database.

2.3. User Characteristics

Restaurant Managers:

Restaurant managers are responsible for overseeing the restaurant's entire operation, including
inventory management. They have a holistic view of the restaurant's financial health and need access to
detailed inventory data.
Managers use the RIMS to access comprehensive reports, monitor inventory levels, analyze trends, set
budgetary constraints, and make informed decisions about purchasing and menu planning.

Managers have broad system privileges, allowing them to perform administrative tasks, generate
financial reports, and manage user accounts.

Kitchen Staff:

Kitchen staff members are responsible for preparing meals and ensuring that the restaurant has the
necessary ingredients. They need to access real-time inventory information to ensure menu items can
be prepared without running out of key ingredients.

Kitchen staff may use the RIMS to check inventory levels, request restocking of items, and record item
usage for each meal prepared.

Kitchen staff often have limited system privileges, focusing primarily on inventory usage and restocking
requests.

Waitstaff and Servers:

Waitstaff and servers are responsible for taking customer orders and delivering food and beverages.
They need accurate information on menu item availability and potential substitutions.

Waitstaff use the RIMS to check item availability in real-time, make recommendations to customers
based on inventory levels, and relay customer orders to the kitchen.

Waitstaff typically have read-only access to inventory information and may not perform actions that
affect inventory directly.

Purchasing and Procurement Teams:

The purchasing and procurement teams are responsible for managing supplier relationships, placing
orders, and ensuring that the restaurant has a steady supply of ingredients and supplies.

These teams use the RIMS to create purchase orders, track deliveries, and manage supplier information.

They have access to supplier databases and may have elevated privileges for managing supplier
relationships and financial transactions.
2.4. General constraints
 The system must be compatible with modern operating systems, including Windows, macOS,
and various Linux distributions.
 The web-based user interface must be compatible with common web browsers, such as Google
Chrome, Mozilla Firefox, and Microsoft Edge.
 The end-user devices should meet minimum hardware specifications for optimal performance,
including processor speed, memory, and screen resolution.
 The system relies on a stable and high-speed internet connection for real-time data access and
synchronization.
 Ensure that the software complies with licensing agreements for third-party components and
libraries.
 The project budget is limited and must be managed effectively, potentially affecting the
selection of tools, technologies, and external services.
 The project has predefined deadlines for development, testing, and deployment, which must be
adhered to.

The system must provide a capacity for parallel operation and system design should not introduce
scalability issues with regard to the number of surface computers, tablets or displays connected at any
one time. The end system should also allow for recovery, without data loss, from individual device
failure. There must be a strong audit chain with all system actions logged. With that in mind, the most
adaptable and portable technologies should be used for the implementation. The system has criticality
insofar as it is a live system. The system must be reliable enough to run crash and glitch free more or less
indefinitely, or facilitate error recovery strong enough such that glitches are never occurring.

2.5. Assumptions and dependencies

Users are assumed to have a basic understanding of computer operation and internet usage. Training
resources will be made available to assist users in learning to use the system effectively. Existing supplier
relationships and agreements will be maintained during the system's implementation. Suppliers will
provide the necessary data and access for integration with the system. Historical inventory data,
including items, transactions, and supplier details, will be accessible for system data migration. Data
accuracy and completeness are assumed, and data cleansing will be performed if necessary. The
availability and reliability of third-party services and APIs (e.g., supplier databases, payment gateways)
are essential for the system's performance. The system depends on the continued support and
maintenance of the underlying operating system and database management system. Availability of
hardware and hosting resources, as well as adherence to hosting provider service level agreements
(SLAs), are critical dependencies. The system is dependent on compliance with relevant data protection
regulations and industry-specific standards. Compliance with licensing agreements for third-party
components and libraries is necessary.

The SRS assumes that none of the constituent system components will be implemented as embedded
applications. The implication is that the target hardware will provide a capacity for standalone
program/application deployment and not require customized embedded firmware to be written. It is
further assumed that tablet PCs of sufficient processing capability and battery life will be utilized. The
surface computers employed by the system should facilitate being utilized/left on for extended periods
(sufficient for daily use) and that they are programmable in the same fashion as x86 architecture
computers.

Finally, it is further assumed that the deployment environment can support an IEEE 802.11 wireless
network for system communication.

3.0. Specific requirements

3.1. Functional requirements
The System aims at providing an efficient interface to the user for managing inventory, it shall also
provide the user varied options for managing the inventory through various functions at hand. The
ingredient levels are continuously monitored based on their usage and are checked for the minimum
levels in the inventory and accordingly the user is alerted about low levels of certain ingredients. The
design is such that the user does not have to manually update the inventory every time, the System
does if for the user. The System calculates and predicts the amount of usage for specific set days that
are pre-set by the user(admin), it also alerts the user of an impending action to order ingredients before
the specific day set by the user. Therefore, the user never has to worry about manually calculating the
estimated usage of the ingredients as the System does for the user. The simple interface of the System
has functions like adding a recipe, removing or updating the recipe. It also extends to functions such as
adding a vendor for an ingredient, removing the vendor, checking threshold levels, processing orders,
altering processed orders etc.

3.2. User Interface requirements

The user interface will be implemented using a computer and a browser. The interface will be user
friendly to make it easier for computer illiterate users.

3.2.1. Minimum Hardware Specifications

Minimum hardware requirements for end-user devices.
 For optimal performance, users are recommended to have devices with a modern processor,
Intel core i3-2350M CPU @2.30 GHz, at least 4GB of RAM, a screen resolution of 1024x768 or
higher, a hard disk of 160 GB or higher, and a power redundant suitable secondary Power
source (Minimum up time 99%).

Internet Connection

 The network connection required for the system to function.

 A stable and high-speed internet connection to ensure real-time data access and
synchronization.
 Redundancy and failover capabilities to mitigate network interruptions.

Local Area Network (LAN)

Local network requirements for intranet access, if applicable.

 Compatibility with LAN configurations for secure internal communication.

Label Printers

 Hardware for printing barcode labels and receipts.

  Compatibility with the system's label printing functionality.
 Support for label formats and templates used by the system.

3.3. Software interfaces

3.3.1. Database Management System Interface
 Connectivity to the underlying database management system.
 The system shall interact with the MySQL database using standard SQL queries.
 It should perform CRUD (Create, Read, Update, Delete) operations on the database tables for
inventory, user accounts, and transactions.

3.3.2. Supplier Database Interface

 Integration with external supplier databases to fetch supplier information.
 The system shall provide an interface to connect to supplier databases through standard APIs or
data exchange formats (e.g., XML, JSON).
 The interface should allow the system to retrieve supplier details, such as contact information
and pricing.

3.3.3. Reporting and Exporting Interface

 Interfaces for generating and exporting reports.
 The system shall provide an interface for users to select, generate, and customize reports.
 Reports can be exported in common formats, such as PDF, CSV, or Excel, for further analysis.

3.3.4. Authorization Interface

 Interfaces for role-based access control.
 The system shall support role-based authorization, specifying what actions each role can
perform.
 It should integrate with user management systems for role assignment.
3.4. Communication interface
3.4.1. Web-Based User Interface
The web-based user interface is used by employees and managers to interact with the system.

 Communication Protocol: HTTPS (Hypertext Transfer Protocol Secure) for secure web
communication.
 Data Format: Data is transferred as JSON (JavaScript Object Notation) for requests and
responses.
 Channel: Users access the web-based UI via standard web browsers (e.g., Google Chrome,
Mozilla Firefox, Microsoft Edge).

3.4.2. Database Interface

Database Management System (DBMS)

The system interfaces with a MySQL database to store and retrieve data.

 Communication Protocol: MySQL client-server communication protocol.

 Data Format: Structured Query Language (SQL) for database queries.
 Channel: The system communicates with the MySQL database server on the designated port.

3.4.3. External Services

Supplier Databases

The system interfaces with external supplier databases to retrieve supplier information and place
orders.

 Communication Protocol: RESTful APIs (Representational State Transfer) or XML-based data

exchange.
 Data Format: JSON or XML for data exchange.
 Channel: Supplier databases are accessed via standard HTTP or HTTPS protocols.

3.4.4. Email Notifications

Email Service
The system sends email notifications for user registration, alerts, and system updates.

 Communication Protocol: SMTP (Simple Mail Transfer Protocol) for sending email messages.
 Data Format: Email messages are structured according to email standards.
 Channel: Email is sent over the internet using standard SMTP servers.
APPENDICES
Glossary of terms
Term - Description
Manager: The manager implies the manager of the restaurant/company who handles all the
administrative work.
Recipe: This is the menu item that the restaurant/company provides to its customers.
Ingredient: This is the entity that the recipe is composed of.
Vendor/Supplier: This is the company that provides the restaurant/company with the required
ingredients.
Order: Order is the list of ingredients and the quantities that is or is to be requested from the vendor.
Use-case diagram

Fig. 2