Project Documentation

EGERTON UNIVERSITY
PROPOSAL DOCUMENT
FOR:
SAHANI WEB APP
PREPARED BY: BRENTONE ALISTAR
REG NO: S13/15358/16
PROJECT SUPERVISOR: DR. PHOEBE

ONGALO
PROJECT COORDINATOR: DR. W. GIKARU
DATES: April 2021
VERSIONS: 2
Table of Contents
Acknowledgment.........................................................................................................................................5
Abstract/executive summary.......................................................................................................................5
Introduction.............................................................................................................................................6
Overview and Literature review..............................................................................................................6
A. Existing systems.................................................................................................6
B. Some Limitations of current systems..................................................................7
Problem Statement...................................................................................................7
Justification..............................................................................................................7
Objectives................................................................................................................7
Proposed solution....................................................................................................................................8
Methodology...........................................................................................................................................8
Project Scope...........................................................................................................................................9
Resources................................................................................................................................................9
Preliminary Results and Evaluation.......................................................................................................10
Challenges, obstacles and risks..............................................................................................................11
Schedule and budget..............................................................................................................................11
Schedule.................................................................................................................11
Budget....................................................................................................................12
Conclusions and Future work................................................................................................................12

Overview...................................................................................................................................................15
Introduction...............................................................................................................................................16
Purpose..................................................................................................................................................16
Document Conventions.........................................................................................................................17
Intended Audience and Reading Suggestions........................................................................................17
Project Scope.........................................................................................................................................18
Overall Description...................................................................................................................................18
Product Perspective...............................................................................................................................18
Product Features....................................................................................................................................19
User Problem statement.........................................................................................................................20
User Objectives.....................................................................................................................................20
Operating Environment.........................................................................................................................21
Design and Implementation Constraints................................................................................................21
User Documentation..............................................................................................................................21
Assumptions and Dependencies............................................................................................................21
User Constraints....................................................................................................................................22
System Features.........................................................................................................................................22
Generalized Model of operation............................................................................................................22
Use case User Registration - Account Sign up(U1)...............................................................................24
Objective................................................................................................................24
External Interface Requirements...............................................................................................................26

User Interfaces.......................................................................................................................................26
Hardware Interfaces...............................................................................................................................26
Software Interfaces................................................................................................................................26
Communications Interfaces...................................................................................................................27
Other Nonfunctional Requirements...........................................................................................................27
Performance Requirements....................................................................................................................27
Safety Requirements..............................................................................................................................27
Security Requirements...........................................................................................................................28
Software Quality Attributes...................................................................................................................28
Other requirements Attributes...............................................................................................................30
Preliminary Object-Oriented Domain Analysis.........................................................................................30
Inheritance relationships........................................................................................................................30
User Classes and Characteristics...........................................................................................................30
Preliminary Budget and Schedule..............................................................................................................33
Other Requirements...................................................................................................................................34
Appendix A: Glossary of definitions, Acronyms and abbreviations......................................................34
Overview...................................................................................................................................................37
INTRODUCTION.....................................................................................................................................37
Purpose and Scope.................................................................................................................................37
Project Executive Summary..................................................................................................................38
System Overview..................................................................................................39
Design Constraints...............................................................................................40
1|Page
Future Contingencies...........................................................................................41
Document Organization.........................................................................................................................42
Points of Contact...................................................................................................................................42
Glossary.................................................................................................................................................42
SYSTEM ARCHITECTURE....................................................................................................................42
System Hardware Architecture..............................................................................................................43
System Software Architecture...............................................................................................................43
Internal Communications Architecture..................................................................................................44
FILE AND DATABASE DESIGN...........................................................................................................45
Database Management System Files.....................................................................................................45
Non-Database Management System Files.............................................................................................49
HUMAN-MACHINE INTERFACE.........................................................................................................49
Inputs.....................................................................................................................................................49
Registration............................................................................................................50
Login......................................................................................................................52
Outputs..................................................................................................................................................52
Order confirmation................................................................................................53
Restaurant’s Orders List........................................................................................54
Receipt...................................................................................................................55
Restaurant Analytics..............................................................................................55
Payment Voucher...................................................................................................56
DETAILED DESIGN................................................................................................................................56
Hardware Detailed Design.....................................................................................................................57
Software Detailed Design......................................................................................................................57
EXTERNAL INTERFACES.....................................................................................................................58
Interface Architecture............................................................................................................................58
Interface Detailed Design......................................................................................................................59
SYSTEM INTEGRITY CONTROLS.......................................................................................................60
Test plan identifier.....................................................................................................................................62
Introduction...............................................................................................................................................62
2|Page
Objectives..............................................................................................................................................62
Scope.....................................................................................................................................................63
Features to be tested..................................................................................................................................64
Customer...............................................................................................................................................64
Restaurant..............................................................................................................................................64
Admin....................................................................................................................................................64
Features not to be tested............................................................................................................................65
Process overview.......................................................................................................................................65
Testing process..........................................................................................................................................66
Test strategy..............................................................................................................................................67
Unit testing............................................................................................................................................67
Integration testing..................................................................................................................................67
System testing........................................................................................................................................67
Performance testing...............................................................................................................................67
User interface testing.............................................................................................................................68
Item pass/fail criteria.................................................................................................................................68
Suspension criteria.................................................................................................................................69
Test deliverables........................................................................................................................................69
Environmental needs.................................................................................................................................69
Client-side environments.......................................................................................................................70
Server-side environments......................................................................................................................70
Staffing and training needs........................................................................................................................70
Schedule....................................................................................................................................................71
Approval................................................................................................................................................71
General information...................................................................................................................................73
Technical specifications........................................................................................................................73
Authorized use permissions...................................................................................................................73
System features.........................................................................................................................................74
General features.....................................................................................................................................74
Registration............................................................................................................74
Login......................................................................................................................76
Password reset.......................................................................................................76
3|Page
Customer’s features...............................................................................................................................77
Customer’s dashboard...........................................................................................77
Make an order........................................................................................................78
view order history..................................................................................................80
View customers’ profile........................................................................................81
Restaurants features...............................................................................................................................82
Restaurant dashboard.............................................................................................82
Add menu...............................................................................................................82
View dashboard.....................................................................................................83
Add staff................................................................................................................84
Admin features......................................................................................................................................84
Admin dashboard...................................................................................................84
Admin Dashboard..................................................................................................85
Manage Restaurants...............................................................................................86
4|Page
Acknowledgment.
So much gratitude to my project coordinator Dr. Eng. Wilfred Gikaru and my Project supervisor
Dr. Phoebe Ongalo for their consistent guide and the support they gave me towards project
identification with the provision of information of the most current social and economic threats
that requires the skills of computation and some of the best available techniques to solve.
I would also wish to express my gratitude to the Department of Computer Science for the
resources and materials provided for the success of this project. This includes free WI-FI to
access online materials and for research wherever I felt stuck. The encouragements from the staff
were also sufficient for the success of this project.
Finally, more thanks to my colleague who added something to make my project better. All the
reviews and recommendations contributed towards providing a quality application and a
guarantee of full problem-solving software development.
Abstract/executive summary
The Online Platform Management Software is designed to cater to flexibility, scalability, and integration.
Sahani Restaurant Management Platform Software is a robust Management Solution. restaurants will be
more successful by providing better services to the customers and gaining greater control over the
business costs and profits. This Management Software System will give Your Business firm the business
management software solution it needs.
In a nutshell, the Restaurant Management software presents you with screens for the following:
Creation of your Stock Entries
Creation of products selling.
Creation of your System Users access levels
Input of sales
Input of purchases
The input of your expenses
A wide range of customized Reports
The latest design features to ensure maximum user experience
Multi-user support
High system security through the enabled log of system users
Report printing, receipts, and all category query reports
5|Page
Introduction
There has always been a need for more market outreach. An ideal solution to ensure a business
firm maximizes sales while maintaining good customer relations with much ease.
Take Alibaba, for example, a platform that allows product owners to sell their items virtually
while customers all over the world are entitled to making purchases wherever and whenever they
wish to, well as long as the product they seek to purchase is available.
To bridge this gap, a platform system, explicitly in this case for restaurants was a necessity. The
system is to cover a wider scope to accommodate customers, product suppliers, restaurant users
which includes: cashiers, waiters, managers, and kitchen users, and guests, those who only wish
to visit the platform without storing their information in it.
Moreover, the platform system provides statistical analysis on, well almost every transactional
events module, from daily sales reports, weekly reports, monthly reports, yearly reports, payment
category reports, stock reports, and much more.
Overview and Literature review

A. Existing systems
Digital technology has been impacting human behavior for a very long time. The existing
systems majorly are goal-oriented towards customer satisfaction; however, it ends with the
customer, the service to the registered platform product providers often suffers from server
limitations to flexibility, scalability, maintainability, and overall high operational cost.
So, the question remains, does higher operational costs contribute positively towards profit
maximization when the same business firm has to suffer from scalability-related aspects of
management? In many cases, a business has to subscribe to more than one software solution to
meet its goals, one for stock management while another for restaurant management. This does
not contribute towards smoothening the operational curve.
B. Some Limitations of current systems

Although the existing system works fine, there is still scope for improvement. The overall
number of modules accessible to the users of the system especially the restaurant should expand
the scope to offer a wider variety of services, allow customizations to meet the restaurants' goals,
and serve a higher degree of flexibility.
6|Page
Problem Statement
A multi-user system with a limited degree of access levels making it even harder for operations,
cut-off system users, lacking reporting features, no statistical analysis, a less intuitive designs
with lower system-users interaction levels.
Justification
The proposed system explicitly is aimed towards providing the best remedies and accurate
solutions to help mitigate the identified problems from the current system implementations in
terms of scalability, flexibility, provision of statistical analysis, spectacular design features, and
the most efficient report generations.
Objectives
 An easy query of sales per day/Month/Year, Sales made by Cashier/Waiter/Product.
 Track purchases made over some time e.g., daily, monthly, yearly.
 An easy query of remaining stock in the stores, deficit stock.
 Track items issued by the store to the kitchen, counter.
 Track item usage per product.
 Track daily portions produced from the kitchen and portions sold by the waiters/cashiers.
 Easy management of your debtors and creditors' accounts.
 Printable receipts per payment transaction.
 Printable reports per Query.
 Easy management of bank deposits, per bank, per Creditor account.
 Advanced security controls.
 User-friendliness and ease of use.
 Backup and restore facilities
As a result of the benefit of this system: -
 Your business becomes Easy and efficient to manage and run.

 You stay ahead of your competitors and on the edge of technology.
 You get reliable answers and results as Accountability is achieved.
7|Page
 You will be able to make more wise decisions concerning where your business
strengths are and its weak points.
 Add value and satisfaction.
 Improve credibility.
 Growth opportunity.
 Multi-User
 Allows Data Exporting to other systems.
 Period roll-overs
 Variance Reports between different periods e.g., daily, weekly, monthly, yearly.
 Comprehensive Audit Trails
Proposed solution
The proposed system, Sahani Restaurant Management Platform, is featured with adequate and
current techniques in providing the best remedies towards enhancing restaurant customer
relations through real-time menu updates, superior payment models, an efficient interaction
degree, and above all, sales maximization through a wider reach to the customers from widening
market. The customers also have greater access to several restaurants which enables them to
make self-benefiting decisions, which can be based on the prices, reputations, or popularity of
the restaurants they wish to buy their food from.
Methodology
My mode of data collection was a hybrid of interviews of restaurant owners and in-depth
analysis of the current systems in applications. The goal-seeking interviews with restaurant staff
were to acquire more on the challenges and shortcomings of the current systems in
implementations as well as the proposals for feature features they would wish to have included in
newer system solutions.
According to my findings, the higher management levels were suffering from a lack of statistical
analytic features, proper reporting solutions, and operational costs. The middle and lower
management personnel had a problem with limited system functionality features, no
customizations, poor designs which brought about fewer system interactions and mostly lack
exception handling.
8|Page
Their proposal was a more flexible system that would cover all parts of restaurants operations,
not to redesign the operations but to make them more efficient, enhance the quality assurance of
the system, and develop user-friendly applications.
Project Scope
This system platform will cover a wider range of applications, majorly categorized into three
main parts, The Administration, The Customer, and The Restaurants. The restaurant is
further subdivided into other user categories. These include the kitchen user, the cashier, and
the waiter.
The registered customer has the privilege to make orders from a variety of restaurants, make
payments, confirm orders, cancel orders, select delivery addresses, from the services offered by
the restaurants, which are delivery, dine-in, or and takeaway services.
The registered restaurants, on the other hand, adds menu items, stock management for the
kitchen, adds waiters and cashiers, manages customers orders, views reports, print
receipts, statistical analysis of orders and sales, chooses services they offer, sets locations
they are based in and many more functions.
The System Administrator has the privilege of Suspending, banning, or activating

restaurants based on subscriptions or complaints, or both. He is the superuser
Resources
The proposed system is an application program development-oriented without much necessities
of hardware and physical facilities. Some of the hardware requirements are user-oriented, a
restaurant would need a printer to print receipts, a point-of-sale terminal to handle payments, and
other necessities like tables for customers and a delivery system.
The funding should cover online hosting as the first step to making this application available
online for downloads as either an extension for major social apps and web browsers or an
independent stand-alone application. Moreover, the funding should be able to cover the users'
training on how, where, and when to use this program as well as the benefits of using the
program.
9|Page
Preliminary Results and Evaluation
Work Done Implementations Result Obtained Conclusion
Used
[1] Automated ▪ Carbon/Carbon ▪Real-time display This provided
Monitoring of Library of reports and sales solution to statistical
Orders and sales
▪An amazing analysis
administrative
▪Material design requirement and
dashboard
automated report
generations
[2] Multi user access ▪ admin = 1 ▪The best multi-user This application
levels system. model enabled user
▪restaurant = 2
▪secure application classifications to
▪customer = 3 ▪user-friendly enable the user to
application
▪ waiter = 4 have the correct
functional privileges
▪kitchen user = 5
as well as enhance
▪cashier = 6 the interaction
experience.
[3] Amazing and Design Technique ▪The best and most Responsive user
responsive features current user interface
▪Bootrap4 interface design
design features including
▪Material Theme
an amazing
▪ Laravel 8.2 dashboard and a
window loader.
▪node Js
▪HTML 5
[4] ORM Database ▪Laravel Database which can Migration flexible
Model be easily be accessed Database
with any
programming
10 | P a g e
language.
Challenges, obstacles and risks

Internet access: - this will require all users to be connected to the internet, either WIFI or using
data bundles, for them to access the system.
Computers and smartphones: - the system will require all users to possess a computer i.e., a
personal computer e.g., a laptop or require one to have a smartphone to access the system.
Computer literacy: - the system will require all users to be computer literate since not all users
will be conversant with matters relating to computers which are a challenge.
Schedule and budget.

Schedule.
The schedule duration is estimated to be between 10 to 12 weeks. The following table represents
a highly itemized decomposition of the preceding tasks.
YEAR 2021
MONTH JANUARY FEBRUARY MARCH
WEEKS 1st 2nd 3rd 4 th
1st 2nd 3rd 4th
1sst 2nd 3rd 4th
PROPOSAL
INTRODUCTION
REVIEWING
INTRODUCTION
LITERATURE
REVIEW
REVIEWING
LITERATURE
REVIEW
METHODOLOGY
REVIEWING
METHODOLOGY
FINAL REVIEWING
OF PROPOSAL
11 | P a g e
Budget.
A budget of the requirements to implement the project. The entire budget is estimated to be
around Kshs 20,000 to Kshs 25000.
Item Cost
Computer/Smartphone Kshs. 10,000
Windows Operating System Kshs. 10,000
Internet Bundles Kshs. 5,000
Conclusions and Future work

In this paper, there is a detailed explanation of various existing types of online platform
management systems. The approach for development in this domain focuses on flexibility,
efficiency, user-friendliness, maintainability, wider access to customers, wider access to
restaurants, software quality assurance as well as statistical analysis features.
The study revealed that there is a need for a restaurant to operate two different software
solutions, one for stock management while the other for restaurant management solutions,
However operate on a singular hybrid system that manages the entire scope of operations within
the restaurant.
Also, the multi-user support login can be categorized as Administrator, Restaurant Manager,
Customer, Cashier, kitchen user, and waiter. This, in turn, ensures the preservation of user
privileges as well as enhancing the user experience through the provision of the correct system
functions and customizations for faster operations and transactions.
12 | P a g e
SOFTWARE REQUIREMENTS
SPECIFICATION
FOR:
SAHANI WEB APP
EGERTON UNIVERSITY
13 | P a g e
REG NO: S13/15358/16
PROJECT SUPERVISOR: DR. PHOEBE

ONGALO
PROJECT COORDINATOR: DR. W. GIKARU
DATES: April 2021
VERSIONS: 2
14 | P a g e
Software Requirements Specification for Sahani
Page 15
Revision History
Name Date Reason for Changes Version
Brentone Alistar 03/14/21 Project Swap 1.0
Overview
SRS is the official statement of what the system developers should implement. SRS is a complete
description of the behavior of the system to be developed. SRS should include both a definition
of user requirements and a specification of the system requirements.
The SRS fully describes what the software will do and how it will be expected to perform. The
SRS precisely defines the software product that will be built. SRS used to know all the
requirements for software development and thus that will help in designing the software. It
provides feedback to the customer. Documents that describe the functions of the SRS include
the Software Requirements Document (SRD), Functional Requirements Document (FRD),
Functional Requirements Specifications document (FRS), among other synonyms.
The SRS defines the contract between the developer and the owner of the system.
Introduction
Purpose
The Online Platform Management Software is designed to cater to flexibility, scalability, and
integration. Sahani Restaurant Management Platform Software is a robust Management Solution.
restaurants will be more successful by providing better services to the customers and gaining
15 | P a g e
Page 16
greater control over the business costs and profits. This Management Software System will give
Your Business firm the business management software solution it needs. In a nutshell, the
Restaurant Management software presents you with screens for the following:

Input of sales
Input of purchases
Multi-user support
Document Conventions
This document follows the MLA Format. The bold-faced text has been used to emphasize
section and sub-section headings. Highlighting is to point out words in the glossary and italicized
text is used to label and recognize diagrams. When writing the SRS document for Sahani Online
Platform the following styles were used to make the document more effective and readable I
used Times New Roman font size 12 and headings which are bold and elegantly placed.
The following terminologies are also used:
DB Database
DDB Distributed Database
16 | P a g e
Page 17
ER Entity Relationship
User Anyone who uses the application
OS Operating System
OSDD Online Suspicious Discussion Detector
Intended Audience and Reading Suggestions

The intended readers of this document are the developers of the system, testers, online shopping
users, marketing agencies, online restaurants as well as other readers who seek to gain
knowledge and all the information about the system.
Project Scope
the waiter.
The registered customer has the privilege to make orders from a variety of restaurants, make
the restaurants, which are delivery, dine-in, or and takeaway services.

17 | P a g e
Page 18
Overall Description
Product Perspective
The software product being developed is platform-independent equipped with relevant and stable
programming language implementation to enable the software product to run on all browsers
including chrome, Mozilla, Microsoft edge and opera.
Databases for Sahani software product has been implements with eloquent implementation
paradigm making it cross platform to major query languages. This has been made possible
through the programming language database eloquence abstraction.
This product is aimed at upgrading the existing online shopping platforms through reformations
and the shopping standards in terms of added modules and functionalities, improved user-
software interaction experience, software flexibility, maintainability, as well as efficiency.
Implicitly, this system will be a better version of the already existing self-independent systems
especially online food delivery categorically. With the addition of more features, the system is
objectively oriented towards the provision of a better experience to its users and generally
towards enhancing better performance.
Currently, there is no software, which combines all functionalities the way the Sahani does.
Therefore, it is a prototype of a new software that merges online shopping platform families with
a wider scope of functional modules.
Product Features
Sahani contains the following features:
Guests can visit the landing page, search for food and drinks, view registered restaurants in the
platform, view menu items from any selected restaurants, but must login to place an order.
Customers in addition to the guests’ privileges, can access the customer portal, place orders,
confirm orders, cancel orders, specify delivery addresses, edit profile information among many
other privileges.
Restaurant’s owners will need to register their restaurants with their restaurants’ information.
After the registration and account confirmation, the restaurant profile will get activated by the
Sahani platform administrator, thus allowing the restaurant to operate. The manager can add
restaurant’s staff like waiters, cashiers, kitchen users among others, add menu items, add more
profile information, manage stock, view reports, print reports, and many more.
18 | P a g e
Page 19
The Platform Administrators role is in the management of the restaurants, the actions entitled to
the administrator are among being the super user to the platform, can ban restaurants operations,
suspend restaurants as well as activate restaurants. The admin can also view the overall platform
statistics.
The waiters will represent customers who doesn’t wish to use the system but need to dine-in or
make a takeaway order all the same. The waiters are entitled to the registered restaurant and only
make orders internally from registered restaurant menu
Moreover, the system will enable registration of a cashier who is entitled to completing payment
transactions, its implementation allows customers to select modes of payment either m-pesa
option or cash, bill splitting and receipt generation.
The last user in this series is the kitchen user, the user is solely responsible for the kitchen
management, management of stocks, recording of expenditures, and have profile edit privileges.
User Problem statement

The users of the system can be anybody with the capability of accessing the internet, specifically
the online shopping platform with high anticipation of online food and drink shopping. These
users are entitled to a variety of services both from the platform configurations and restaurants
services. It is with accuracy that the users know the working environment and standards of this
platform and thus won't need much expertise in implementation of the system to work without
any hitches with the aim of provision of uttermost satisfaction.
Sahani system domain comprises major online platforms used for online shopping, restaurants
management operations, stock managements by knowing which stocks were moved, how many
stocks are due to expire, which supplier a stock item belongs to and from sales-expenditure
differences the system will provide profit/loss reports.
User Objectives
To provide a reliable system that is easy to use and work with
To ensure 24 x 7 availability of the system
Provide a secure system that doesn’t lead to further complications
Provide a system that help implement online safety and regulations
Provide an interactive system that has good performance and minimum system requirements
such as memory size, processor speed, and data.
19 | P a g e
Page 20
Operating Environment
Operating environment for the Sahani is as listed below.
 distributed database
 client/server system
 Operating system: Independent
 database: Eloquent MySQL database
 platform: Web App.
Design and Implementation Constraints

Synchronization: the system will be structured to serve multiple users at a go for complete
utilization of its resources and consistency in performance.
Memory requirements: the device will have a minimum 2GB internal hard drive requirement.
Software and database cannot exceed this amount.
Permissions: there is no permission requirements needed by the current version of the system.
Language requirements: currently supports English. This is due to the software area of
coverage, that is, my design is to enable the Sahani to cover East Africa countries.
User Documentation
For user documentation and information, please consult section 4: External Interface
Requirements and attached user manual.
Assumptions and Dependencies

It is assumed that the user of the system will have strong internet connectivity and some
knowledge and expertise on the usage online shopping platforms because this system is
client/server-based hosting all the resources on the server and allowing authenticated users to
request for those resources.
Moreover, the implementation of these operational simulations to all instances of real-world

objects is assumed to be correctly configured and observes a preservation in the folding of
events with correct exception handling.
User Constraints
 The interactions with the platform will be based on role id.
20 | P a g e
Page 21
 Users have to provide unique credentials such as ID number for purposes of uniquely
identifying the users.
 In cases of feedbacks, substantial evidence should be provided to support the claim. For
example, an order made and claimed to have been completed when delivery was never
made.
System Features
This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section
by use case, mode of operation, user class, object class, functional hierarchy, or combinations
of these, whatever makes the most logical sense for your product.
Generalized Model of operation

3.1.1 Description and Priority
The Sahani Platform is designed to cater to flexibility, scalability, and integration. Sahani
Restaurant Management Platform Software is a robust Management Solution. restaurants will be
more successful by providing better services to the customers and gaining greater control over
the business costs and profits. This Management Software System will give Your Business firm
the business management software solution it needs.
3.1.2 Stimulus/Response Sequences
The implementation paradigm for this request response paradigm with follow
representational API, using both safe and unsafe request methods to facilitate user
software interaction through user sending requests to the server and the server
replying with a response
3.1.3 Functional Requirements
Other system features include:
DISTRIBUTED DATABASE:
A distributed database implies that a single application should be able to operate
transparently on data that is spread across a variety of different databases and
connected by a communication network hosted on different servers.
21 | P a g e
Page 22
CLIENT/SERVER SYSTEM
The term client/server refers primarily to an architecture or logical division of
responsibilities, the client is the application (also known as the front-end), and the
server is the DBMS (also known as the back-end).
A client/server system is a distributed system in which,
 Some sites are client sites and others are server sites.
 All the data resides at the server sites.
 All applications execute at the client sites.
3.1.4 Technical Issues
It is in good practice for the users of the system product to keep up with newer
released versions to ensure efficient compatibility and configuration accuracy
with the dynamic changes and updates on the platforms that are related to the
system’s operation.
3.1.5 Dependencies with other requirements
The system requires a good internet connection as an external dependency with

enough memory storage for good operation and performances.
Use case User Registration - Account Sign up(U1)
Objective
The purpose of the U1 use case is to provide relevant fields to the user for capturing user
credentials to ensure the unique identity of each and every user of the system that will facilitate
correct user reference.
3.2.2 Priority - This requirement is a high priority.
3.2.3 Source – The source of this use case is the user of the system.
22 | P a g e
Page 23
3.2.4 Actors – An end-user of the system (customer, admin, restaurant, waiter, kitchen user,
cashier) would be the relevant actor for this use case.
3.2.5 Flow of events-
3.2.5.1 Basic Flow-
3.2.5.1.2 User accesses the system program registration page.
3.2.5.1.3 the provided user credentials are captured and stored in a distributed database.
3.2.5.1.4 a verification information is sent to the email account.
3.2.5.1.5 the user logs into the email account and verifies the account.
3.2.5.2 Alternative Flow- At step 3.2.5.1.4, the user decides not to validate the
account.
3.2.5.2.1 User fails to verify the created account.
3.2.5.2.2 The account exits with verify the account prompt
3.2.5.2.3 The users’ privileges and access to major parts of the system is revoked.
3.2.5.3 Exception Flow – At step 3.2.5.1.4, the process encounters a problem.
3.2.5.3.1 System provides an error message indicating the error and relevant solution.
3.2.5.3.2 No user registration info is submitted or stored. The registration process

initializes.
3.1.6 Includes – None.
3.1.7 Requirements-
3.2.7.1 The system shall provide the option to skip registration.
3.2.7.2 The system shall provide the option to register a restaurant or customer account.
3.2.7.3 The system shall display a default user avatar.
3.2.7.4 The system shall indicate a need for registration should the user chose to skip
23 | P a g e
Page 24
3.2.8 Preconditions – Good internet connection.
3.2.9 Postconditions – An updated profile information reflecting the user information.
3.2.10 Nonfunctional requirements –
3.2.10.1 Performance Requirements-
3.2.10.1.1 The maximum allowed execution time for the U1 use case is 60 seconds,
starting at the time when the user presses the register button and
ending when the details have been saved and displayed.
3.2.10.2 Safety Requirements-unique email addresses for every registered user.
3.2.10.3 Security Requirements-password needs to be 8 characters long.
3.2.10.4 Software Quality Requirements-None.
External Interface Requirements

User Interfaces
The Sahani user interface has been specifically designed with the user in mind, giving them
intuitive usage of the application system. Sahani makes sure at every point, that the user spends
most of the time using the system application rather than figuring out how to use it. The home
screen offers a menu with a list of functions that the system performs. The Users can select one
of the options on the menu and are taken to the respective screen. Every screen displays the
menu on the list item. The user can click on any one of the options and is taken to the screen of
their choice. In addition, the application offers easy navigation options to the rest of the screens
efficiently. To scroll down any screen, simply touch the scroll bar on the screen, and roll down.
If the user does not know how to use any functionality or has any queries, the help option can be
used. The help screen contains a text field to enter search terms. A list of search results
pertaining to the query is displayed.
24 | P a g e
Page 25
Hardware Interfaces
This application will work on android phones and windows. Since the application must run
connected to the internet and need location data, Android devices must have a GPS unit and
internet connection in order to run this application.
For voice data inputs, the user requires a microphone connected to the computer. This is as a
supplementary input method should the user decide to enter data via voice input which will be
followed with voice translation into text and processing.
Software Interfaces
The Sahani online platform feature design entails the most elegant and iconic software designs
with the aim of giving its users maximum interaction, reducing execution time and minimizing
the number of errors to none. Right from the start stage, when the software loads and every time
the user makes a request to the server, the application software have been configured with a
stylish window loader, which will continue to animate request reply method until all requested
resources have been fully made available to the user via the server response. The design
implementations also consider the device resolution, responsive as it is in nature, the page
orientation and the menu placement vary with the variation of the device’s screen resolutions,
from big screens like tv, to medium screens like pc screens and finally small devices like smart
phones.
Communications Interfaces
The application will use HTTP protocol for communication over the internet.
Other Nonfunctional Requirements

Performance Requirements
 Sahani platform is a multi-user platform, a single user can log into his/her account using
as many devices as the user wants simultaneously at a go. This performance
consideration is to facilitate parallelization of activities making the performance of the
software to sky rocket, reduces the workload on the user as well as enabling resource
sharing.
25 | P a g e
Page 26
 A distributed eloquent database, one of the most powerful database abstractions made
possible by the implementation of the Laravel programming language which enables
easier database migrations by making it possible to use any query language to extract
database resources. The distributed database paradigm also enhances parallelization
which enhances the software execution speed performance.
Safety Requirements
As a measure against data loss, the software application will include a backing up feature that
ensures periodic backing up of data onto the google drives or accounts as an external source
and copy of the information for use in instances of server problems.
Password resets, verifications, and assignment of unique email addresses to the users is the
security convention to prevent unauthorized account access. The system also enforcer an 8-
character long password to help prevent brute-force attack on the passwords.
In cases of security events like hacked accounts, the administrator can always suspend the
hacked account, change the password and send the validation code to the authentic user.
Security Requirements
a) In the application side,
 The system must not request unnecessary permissions from the user in order to prevent
unwanted attacks.
 Stored data of the application should not be reached by other applications that is installed in
the user’s mobile device.
 Stored data in the mobile device and sent data via the internet should be encrypted. Send and
receive data should be transferred via HTTPS connection. And also authenticated and
encrypted socket-level communication should be implemented.
b) In the database side,

 SQL codes should not be stored in the application in case of application can be affected by
malware software.
26 | P a g e
Page 27
 Data that come from the application should be encrypted again on the database side.
Software Quality Attributes

Some of the software quality attributes that make the system an exemplary to some of the best
and preferred software products include:
a. Availability;
 the system will be a configuration product that will be made available to all users
for free, however, the restaurant users have to pay a subscription fee.
 The system should be available for 7 days and 24 hours.

In the application side, the system should be tested against failures before deploying the first
version or updated versions of the application. Deployed version should be error-free.
In the database side, in case of a failure, the system should recover any information for the user
and system.
b. Portability;
 the product is platform-independent and portable to devices that meet the

hardware and software requirement specifications for the usage of the software
program.
%100 percent of the program depends on the host. In order to change the host, all the
components of the database should be transferred.
c. Security;
in addition to several server firewalls and thread-safe mechanisms, several security

control mechanisms have been implemented to safeguard users from intentional and
unintentional security breaches.
d. Flexibility;
the features of the system are user-customizable to meet the desired user preferences and
ensure users’ maximum satisfaction and user-controlled usage.
e. Adaptability;
27 | P a g e
Page 28
frequent product updates on the product features and functionalities with regards to the
changing technological advancements to ensure a software product with efficient and
maximized user requirements.
f. Maintainability;
 the software maintainability will only involve deploying updates and

implementing these updates at free costs.
An SVN software should be used in the development phase in order to reduce complexity, make
the system traceable and recover the code from an unwanted crash while more than one
developer is dealing with the code.
Design elements should be documented well.
Since programming language is object-oriented, program tasks are independent of each other and
therefore easier to maintain.
All parts of the code should be easy to read.
g. Performance;
in terms of requests and responses, advanced and most current algorithms have been
implemented to facilitate faster processing of all user requests resulting in giving out
feedbacks/responses in time.
Other requirements Attributes

For information regarding functional requirements, refer to section 3: System Features. Each
feature has its requirements listed alongside the feature information. Special requirements for
each system feature are also mentioned in section 3. There are no additional Functional
requirements.
Preliminary Object-Oriented Domain Analysis

This section presents a list of the fundamental objects that must be modeled within the system to
satisfy its requirements. The purpose is to provide an alternative ‘structural’ view on the
requirements stated above and how they might be satisfied in the system.
Inheritance relationships
System Admin
28 | P a g e
Page 29
Restaurant
Waiter/Cashier/Kitchen User
User Classes and Characteristics

the waiter. The registered customer has the privilege to make orders from a variety of
restaurants, make payments, confirm orders, cancel orders, select delivery addresses, from the
services offered by the restaurants, which are delivery, dine-in, or and takeaway services.

6.2.1 Class descriptions

The main classes associated with the system and have direct influences on the general
performance of the system as identified during the OO Domain Analysis are the user class.
The user class primary performs subjectively to avail all the required data for processing by the
system. The availability of these data can be via order module of the system or adding of menu
items by the restaurants management. Likewise, at the other end of the system is administrator
tasked with implementing the rules and regulations on the platform usage.
6.2.1.1 User Class
29 | P a g e
Page 30
6.2.1.1.1 Abstract or Concrete:
the user class is an abstract class with methods and attributes that can be inherited
by other classes.
6.2.1.1.2 List of Super classes:

Restaurant class
6.2.1.1.3 List of Subclasses:

Waiter class
Cashier class
Kitchen user class
Customer class
Restaurant class
Administrator class
6.2.1.1.4 Purpose:
this class is the blueprint of all major objects in the system. It is tasked with the
role of holding together all other subclasses.
6.2.1.1.5 Collaborations:
this class interacts and indirectly dependent with the system administrative class
to inherit methods and features that are critical and essential for the general goals
of the system application.
6.2.1.1.6 Attributes:
user information
Name
Email
Password
30 | P a g e
Page 31
UserID
Other information
Profile Picture
Address
Social media address
6.2.1.1.7 Operations:
The operations get fully initiated after the verification of the account, this majorly
applies to independent classes like customer and Restaurant class. After the
verification stage, the account is fully activated and the user can perform any set
of assigned privileges, for the restaurant, there is one more step needed for full
activation, the administrator has to activate the account further to ensure that the
subscription fee had been paid.
6.2.1.1.8 Constraints:
Verification is paramount to implement authentication class and activate the
systems modules given to the user role.
Preliminary Budget and Schedule

This section provides an initial budget, itemized by cost factor and schedule including major
tasks to be accomplished, their interdependencies and their tentative start/stop dates. The
plan/schedule should also include information on hardware, software and other resources
required.
Item Cost
Computer/Smartphone Ksh. 15,000
Internet Bundles Ksh. 5,000
31 | P a g e
Page 32
Duration Activity
Jan
2021
Feb
2021
March
2021
May 2021
Problem definition
Feasibility study and analysis
32 | P a g e
Page 33
Requirement Analysis
System Design
Coding
Compiling and Testing
System Integration
33 | P a g e
Page 34
Testing
Presentation and Deployment
Maintenance
Other Requirements
For the restaurant users, a cashier machine is recommended as well as a lesser printer for
printing the receipts upon completion of payment by the customers, these should be positioned
to be accessed by the cashier user. Additionally, the manager can have a different printer for
printing sales reports, stock reports as well as orders reports.
Appendix A: Glossary of definitions, Acronyms and abbreviations
Glossary
API – Application Programming Interface

OS – Operating System
DB – Database
DDB – Distributed Database
34 | P a g e
Page 35
HTTP – Hypertext Transfer Protocol
URI – Uniform Resource Identifier
SQL – Structured Query Language
POS – Point Of Sale
Appendix B: Issues List

Exceptions handing of identified threats with proper reasons
Synchronization with the third-party API (POS)
EGERTON UNIVERSITY
35 | P a g e
Page 36
SOFTWARE DESIGN DOCUMENT (SDD)

FOR
TITLE: SAHANI ONLINE PLATFORM

REG. NO.: S13/15358/16
PROJECT SUPERVISOR: DR. PHOEBE ONGALO

PROJECT CORDINATOR: DR. ENG W. GIKARU
DATES: 14 FEB 2021
VERSION: 2.0
36 | P a g e
Page 37
Overview
The System Design Document describes the system requirements, operating environment,
system and subsystem architecture, files and database design, input formats, output layouts,
human-machine interfaces, detailed design, processing logic, and external interfaces.
INTRODUCTION
This System Design Document has been created to outline the proposed system design for the
Sahani Online Platform. Sahani is intended to make online restaurants services to be more user
friendly, offering extensively a wider scope of modules to cover all operations involved in the
standard day to day activities in the restaurants. The main aim of the system is to provide a better
management to the restaurants, expand the market coverages, this is via outreaching to all food
lovers with internet connection, and provide the most efficient and responsive interactions with
the users.
Purpose and Scope

the waiter. The registered customer has the privilege to make orders from a variety of
restaurants, make payments, confirm orders, cancel orders, select delivery addresses, from the
services offered by the restaurants, which are delivery, dine-in, or and takeaway services.

37 | P a g e
Page 38
Project Executive Summary
integration. Sahani Restaurant Management Platform Software is a robust Management Solution.
restaurants will be more successful by providing better services to the customers and gaining
greater control over the business costs and profits. This Management Software System will give
Your Business firm the business management software solution it needs.
In a nutshell, the Sahani Platform presents you with screens for the following:

Input of sales
Input of purchases
Multi-user support
System Overview
Context Diagram
38 | P a g e
Page 39
39 | P a g e
Page 40
Data Flow Diagram
Design Constraints
 The interactions with the platform will be based on role id.
 Users have to provide unique credentials such as ID number for purposes of uniquely
identifying the users.
 In cases of feedbacks, substantial evidence should be provided to support the claim. For
example, an order made and claimed to have been completed when delivery was never
made.
Synchronization: the system will be structured to serve multiple users at a go for complete
utilization of its resources and consistency in performance.
Memory requirements: the device will have a minimum 2GB internal hard drive requirement.
Software and database cannot exceed this amount.
40 | P a g e
Page 41
Permissions: there is no permission requirements needed by the current version of the system.
Language requirements: currently supports English. This is due to the software area of
coverage, that is, my design is to enable the Sahani to cover East Africa countries.
It is assumed that the user of the system will have strong internet connectivity and some
knowledge and expertise on the usage online shopping platforms because this system is
client/server-based hosting all the resources on the server and allowing authenticated
users to request for those resources.
Moreover, the implementation of these operational simulations to all instances of real-

world objects is assumed to be correctly configured and observes a preservation in the
folding of events with correct exception handling.
Future Contingencies
The system has major dependencies on the user of the system. This makes the performance of
the system mission critical depending particularly on some desired user characteristics and
capabilities.
The dependencies include:
 Clear sight
 Computer literacy
 Choice of device screen resolution
Sight dependency countermeasure is via implementation of clear contrasting colors which are
intuitive to the operations of the system. Computer illiteracy can be corrected through organized
vocational training of the system’s user to gain the required know- how with the regards to the
usage of the system. The design has implemented a paradigm to help with screen resolution
differences by specifying the screen layout in each case.
Document Organization
This document completely describes the system at the architecture level, including subsystems
and their services, hardware mapping, data management, access control, global software control
structure, and boundary conditions. The document is organized into seven major sections. Each
section provides detailed sub-sections relevant to the major section. Charts, tables, and graphics
have been inserted to explain or clarify content.
41 | P a g e
Page 42
Points of Contact
This section provides the organization code and title of the key points of contact (and alternates
if appropriate) for the information system development effort. These points of contact should
include the Project Manager, System Proponent, User Organization, Quality Assurance (QA)
Manager, Security Manager, and Configuration Manager, as appropriate.
Glossary
API – Application Programming Interface
OS – Operating System
DB – Database
DDB – Distributed Database
HTTP – Hypertext Transfer Protocol
URI – Uniform Resource Identifier
SQL – Structured Query Language
SYSTEM ARCHITECTURE
This section describes the system and/or subsystem(s) architecture for the project. References to
external entities should be minimal, as they will be described in detail in Section 6, External
Interfaces.
System Hardware Architecture

In this section, describe the overall system hardware and organization. Include a list of hardware
components (with a brief description of each item) and diagrams showing the connectivity
between the components.
System Software Architecture

The development of Sahani platform was through object-oriented programing language, Php
implemented as a framework, Laravel version 8.2. Functionally, the programming language
acted as the backbone for the project, opiniated on the front-end as well as the back-end.
However, implementation of other programming languages was equally important in providing

an amazing responsive feature of the system. These includes JavaScript, HTML, CSS,
42 | P a g e
Page 43
TypeScript, blade and Hack.
The relationships between the developed system modules enables the system to perform
functions that includes:
Customer user
User registration
Role-based login in
Placement orders
Confirmation of orders
Order cancellation before processing status
Payment upon order completion
Restaurant User
Restaurant registration
Restaurant Owner login
Adding of menu items
Updating restaurant’s profile
Adding restaurant staff
Order confirmation
Reporting module
Admin User
Login as a super user
Suspend, ban or activate restaurant account
Cashier
Responsible for completing payments
Login module
Mode of payment documentation
Belongs to a restaurant account
43 | P a g e
Page 44
Waiter
Belongs to a restaurant account
Uses the system on behalf of the customer
Makes orders
Confirm orders
Login into account
Kitchen User
Manages the kitchen
Responsible for the stock management
Internal Communications Architecture
In this section, describe the overall communications within the system. The Sahani platform
system has implemented the Representational Stateful Transfer communication paradigm.
With the secure HTTPs, clients(end-users) can make requests to the system’s resources or
methods using safe HTTP get method, additionally, the end user can post an information, remove
the information as a resource from the server with POST AND PATCH methods. This eventually
triggers the server to give a feedback through a response to the clients’ requests.
Clients will use a browser to interact with the system located within the server to make their
requests.
44 | P a g e
Page 45
FILE AND DATABASE DESIGN

The section reveals the final design of all database management system (DBMS) files and the
non-DBMS files associated with the system under development.
Database Management System Files

This section reveals the final design of the DBMS files and includes the following information,
as appropriate (refer to the data dictionary):
 Refined logical model; provide normalized table layouts, entity relationship diagrams,
and other logical design information
 A physical description of the DBMS schemas, sub-schemas, records, sets, tables,
storage page sizes, etc.
 Access methods (such as indexed, via set, sequential, random access, sorted pointer
array, etc.)
 Estimate of the DBMS file size or volume of data within the file, and data pages,
including overhead resulting from access methods and free space
 Definition of the update frequency of the database tables, views, files, areas, records,
sets, and data pages; estimate the number of transactions if the database is an online
transaction-based system
45 | P a g e
Page 46
Overall Database Schema
A total of 46 tables
46 | P a g e
Page 47
User migration
Restaurant profile migration
47 | P a g e
Page 48
Restaurant menu
Non-Database Management System Files

 Each tuple in the database tables has a structure to completely represent the object it
stores. The indexing is done based on the foreign keys to provide a faster search of the
records
 The input lengths are defined based on the maximum length of the input field. This
collectively, give the overall size of the table. The blocking factor will be the input
type, for example, an integer will only accept integer values.
 File access methods includes, index sequential, virtual sequential, random access, etc.
HUMAN-MACHINE INTERFACE
This section provides the detailed design of the system and subsystem inputs and outputs relative
to the user/operator.
Inputs
This section is a description of the input media used by the operator for providing information to
48 | P a g e
Page 49
the system. This provides the layout of all input data screens or graphical user interfaces (GUIs)
(for example, windows), graphical representation of each interface, and definition of all data
elements associated with each screen or GUI, or reference to the data dictionary. This section
contains edit criteria for the data elements, including specific values, range of values,
mandatory/optional, alphanumeric values, and length. Also, data entry controls prevent edit
bypassing.
Registration
Customer Registration
This interface will take username in type text, email must be in email format, the password must
be length 8 characters or more, and both password and confirm password fields have to match.
49 | P a g e
Page 50
Restaurant Registration
50 | P a g e
Page 51
Login
User authentication is based on the assigned roles
Order food/drink
Make payment
Outputs
This section describes the system output design relative to the user/operator; shows a mapping to
the high-level data flows described in Section 1.2.1. System outputs include reports, data display
screens, and GUIs, query results, etc. The output files are described in Section 3 and may be
referenced in this section. The following should be provided, if appropriate:
51 | P a g e
Page 52
Order confirmation
Restaurant’s Orders List
52 | P a g e
Page 53
Receipt
Restaurant Analytics
Payment Voucher
53 | P a g e
Page 54
DETAILED DESIGN
This section provides the information needed for a system development team to actually build
and integrate the hardware components, code and integrate the software modules, and
interconnect the hardware and software segments into a functional product. Additionally, this
section addresses the detailed procedures for combining separate COTS packages into a single
system. Every detailed requirement should map back to the SRS, and the mapping should be
presented in an update to the RTM and include the RTM as an appendix to this design document.
Hardware Detailed Design

A hardware component is the lowest level of design granularity in the system. Depending on the
design requirements, there may be one or more components per system. This section should
provide enough detailed information about individual component requirements to correctly build
and/or procure all the hardware for the system (or integrate COTS items).
54 | P a g e
Page 55
Requirement Specification
Power Mains Voltage or phones battery in case
of mobile phone
Connector serial/parallel, 11-pin, male/female, etc
Memory and storage Min memory of 1GB RAM and 16 GB
internal storage
Processor Min 2HZ
Graphical representation depicting the monitors, printers
number of hardware items
User interfaces buttons, toggle switches, etc
Monitor Touch screen or pc monitor
Software Detailed Design

A software module is the lowest level of design granularity in the system. Depending on the
software development approach, there may be one or more modules per system. This section
should provide enough detailed information about logic and data necessary to completely write
source code for all modules in the system (and/or integrate COTS software programs).
55 | P a g e
Page 56
EXTERNAL INTERFACES
External systems are any systems that are not within the scope of the system under development,
regardless whether the other systems are managed by the State or another agency. In this
section, describe the electronic interface(s) between this system and each of the other systems
and/or subsystem(s), emphasizing the point of view of the system being developed.
Interface Architecture
In this section, describe the interface(s) between the system being developed and other systems;
for example, batch transfers, queries, etc. Include the interface architecture(s) being
implemented, such as wide area networks, gateways, etc. Provide a diagram depicting the
communications path(s) between this system and each of the other systems, which should map to
56 | P a g e
Page 57
the context diagrams in Section 1.2.1. If appropriate, use subsections to address each interface
being implemented.
Interface Detailed Design

 The data format requirements; if there is a need to reformat data before they are
transmitted or after incoming data is received, tools and/or methods for the reformat
process should be defined
 Specifications for hand-shaking protocols between the two systems; include the
content and format of the information to be included in the hand-shake messages, the
timing for exchanging these messages, and the steps to be taken when errors are
identified
 Format(s) for error reports exchanged between the systems; should address the
disposition of error reports; for example, retained in a file, sent to a printer, flag/alarm
sent to the operator, etc.
 Graphical representation of the connectivity between systems, showing the
direction of data flow
 Query and response descriptions
If a formal Interface Control Document (ICD) exists for a given interface, the information
can be copied, or the ICD can be referenced in this section.
SYSTEM INTEGRITY CONTROLS

 Internal security to restrict access of critical data items to only those access types
required by users
57 | P a g e
Page 58
 Audit procedures to meet control, reporting, and retention period requirements for
operational and management reports
 Application audit trails to dynamically audit retrieval access to designated critical
data
 Standard Tables to be used or requested for validating data fields
 Verification processes for additions, deletions, or updates of critical data
 Ability to identify all audit information by user identification, network terminal
identification, date, time, and data accessed or changed.
EGERTON UNIVERSITY
58 | P a g e
Page 59
FACULTY OF SCIENCE
COMPUTER SCIENCE DEPARTMENT
TEST PLAN FOR SAHANI PLATFORM SYSTEM
PRESENTED BY: BRENTONE ALISTAR

S13/15358/16
SUPERVISOR: DR. PHOEBE ONGALO
COORDINATOR: DR. ENG W. GIKARU
59 | P a g e
Page 60
Test plan identifier
This is the test plan for Automatic Answer Checker System (AACS). The system targets to
improve the process of exam making. It entails development of a web application that will be of
service to enable students to take exams and then receive results immediately. Users will only
require a browser and internet connection for use. The system will allow registered users or
students to exams which maybe one attempt or has no restrictions on number of attempts. Exams
will be set by admin.
Introduction
The goal of this document is to develop a test plan for the Sahani Platform System. This
document defines all the procedures and activities required to prepare for testing of the
functionalities of the system. The objectives of the test plan are to define the activities to perform
testing, define the test deliverables and to identify the various risks and contingencies involved in
testing.
Objectives
integration. Sahani Management Platform Software is a robust Management Solution. Sahani
will be more successful by providing better services to the customers and gaining greater control
over the business costs and profits. This Management Software System will give Your Business
firm the business management software solution it needs. In a nutshell, the Sahani Management
software presents you with screens for the following:

Input of sales
Input of purchases
60 | P a g e
Page 61
Multi-user support
Scope
main parts, The Administration, The Customer, and The Sahanis. The Sahani is further
subdivided into other user categories. These include the kitchen user, the cashier, and the
waiter.
The registered customer has the privilege to make orders from a variety of Sahanis, make
the Sahanis, which are delivery, dine-in, or and takeaway services.
The registered Sahanis, on the other hand, adds menu items, stock management for the
The System Administrator has the privilege of Suspending, banning, or activating Sahanis
based on subscriptions or complaints, or both. He is the superuser
Features to be tested
The following features will be tested:
Customer
Registration and authentication.
Functionality to view and edit profile.
Functionality to view restaurants.
61 | P a g e
Page 62
Functionality to make orders.
Functionality to confirm orders.
Restaurant
Registration and authentication.
Functionality to add menu items.
Functionality to add staff.
Functionality to complete profile.
Admin
Login authentication
Functionality to view registered restaurants.
Functionality to Manage Restaurants.
Functionality to respond to queries.
Functionality to view restaurants records.
Features not to be tested

All the above-mentioned features will be tested. Testing is dependent on the time available, in
the event that time will not allow testing of all features, then the features with the highest
priorities will be considered first. Other features that will not be tested include the following.
FEATURE DESCRIPTION
Network security This is beyond scope.
Process overview
The following steps represent the overall flow of the testing process:
Identify the requirements to be tested. All test cases shall be derived using the current Program
Specification.
Identify which particular test(s) will be used to test each module.
62 | P a g e
Page 63
Review the test data and test cases to ensure that the unit has been thoroughly verified and that
the test data and test cases are adequate to verify proper operation of the unit.
Identify the expected results for each test.
Document the test case configuration, test data, and expected results.
Perform the test(s).
Document the test data, test cases, and test configuration used during the testing process. This
information shall be submitted via the Unit/System Test Report (STR).
Successful unit testing is required before the unit is eligible for component integration/system
testing.
Unsuccessful testing requires a Bug Report Form to be generated. This document shall describe
the test case, the problem encountered, its possible cause, and the sequence of events that led to
the problem. It shall be used as a basis for later technical analysis.
Test documents shall be submitted. Any specifications to be reviewed, revised, or updated shall
be handled immediately.
Testing process
Organize Project: It involves creating a System Test Plan, Schedule & Test Approach, and
assigning responsibilities.
Design System Test: It involves identifying Test Cycles, Test Cases, Entrance & Exit Criteria,
Expected Results. In general, test conditions, expected results will be identified by the Test Team
in conjunction with the Development Team. The Test will then identify Test Cases and the Data
required. The Test conditions are derived from the Program Specifications Document.
Design Test Procedure: It includes setting up procedures such as Error Management systems
and Status reporting.
Build Test Environment: It includes requesting, building hardware, software and data set-ups.
Execute System Tests: The tests identified in the Design Test Procedures will be executed. All
results will be documented and Bug Report Forms filled out and given to the Development Team
as necessary.
Signoff: Signoff happens when all pre-defined exit criteria have been achieved.
Test strategy
The testing will be done using both manual and automatic test tools. The testing will cover the
requirements for all of the different roles participating in the site: customers, restaurants and
63 | P a g e
Page 64
administrators. The following outlines the types of testing that will be done for unit, integration,
and system testing.
Unit testing
Unit testing is a method of testing that verifies the individual units of source code are working
properly. The goal of unit testing is to isolate each part of the program and show that the
individual parts are correct.
Unit Testing is done at the source or code/implementation level for language-specific

programming errors such as bad syntax, logic errors, or to test particular functions or code
modules. The unit test cases shall be designed to test the validity of the program’s correctness.
This test will be performed by the developers.
Integration testing
Integration tests exercise an entire subsystem and ensure that a set of components play nicely
together.
System testing
The goals of system testing are to detect faults that can only be exposed by testing the entire
integrated system or some major part of it. Generally, system testing is mainly concerned with
areas such as performance, security, validation, load, and configuration sensitivity. But in this
case focus is only on Performance and Load testing.
Performance testing
This test will be conducted to evaluate the fulfilment of a system with specified performance
requirements. This will be performed by:
Deleting data and check if it follows the right sorting algorithm to sort the resulting data or
output.
Trying to store new data and check if it over writes the existing once i.e. using an existing
username or email.
Trying to load the data while they are already loaded.
64 | P a g e
Page 65
User interface testing
User Interface (UI) testing verifies a user’s interaction with the software. The goal of UI testing
is to ensure that the UI provides the user with the appropriate access and navigation through the
functions of the target-of-test. In addition, UI testing ensures that the objects within the UI
function as expected and conform to corporate or industry standards.
For the website, unit testing is done first. Because unit testing will ensure that the all components
of the system are working properly or not. If a single unit does not work properly the integration
test will not necessary to perform.
Item pass/fail criteria

A test scenario will be considered a failure case if any of the following happens:
User registration fails.

User authentication fails.
Order making fails.
Menu adding fails.
Staff Adding fails.
The system crashes.
Suspension criteria
The test will be suspended if any of these events occur:
A user cannot register.

A user cannot login.
The system crashes.
Test deliverables
The following documents will be generated as a result of these testing activities:
65 | P a g e
Page 66
Master test plan (this document)
Individual test plans for each phase of the testing cycle
Test Design Specifications
Test log for each phase
Acceptance Test plan.
Unit test plan.
Screen Prototypes.
Test report.
Test scenario and expected result in an excel sheet.
System manual.
Environmental needs
There are essentially two parts to the Sahani system: the client-side, which will facilitate access
to the system by customers, administrators, restaurant’s managers and restaurant’s staff via the
Internet. The server-side which will deal with processing of information, storage of information
in a database and retrieval of information from the database.
Client-side environments
The client-side is any web browser that runs on client device. Client devices are workstations,
laptops and mobile devices with internet access enabled.
Supported browsers are:
Opera browsers
Chrome browsers
Mozilla browsers
Internet Explorer
Safari browsers
Server-side environments
The system will be hosted on Php admin server that will provide the following functionalities:
66 | P a g e
Page 67
A MySQL database for data storage.
Storage of system resources.
Staffing and training needs

The following will be the required staff for testing the system:
Project Manager: Responsible for managing the total implementation of the Web application.
Test manager: Responsible for developing the master test plan, reviewing the test deliverables,
managing the test cycles, collecting metrics and reporting status to the Project Manager, and
recommending when testing is complete.
Test engineer: Responsible for designing the tests, creating the test procedures, creating the test
data, executing tests, preparing incident reports, analyzing incidents, writing automated test
procedures, and reporting metrics to the test manager.
Each and every member assigned to this project should be experienced with:
General development & testing techniques.

System’s development lifecycle methodology.
All development and automated testing tools that they may be required to use.
Schedule
The schedule for testing the system will be as follows:
Testing will be done throughout the process of its development depending on the type testing in
question.
Approval
The test will be approved once it meets all quality requirements.
67 | P a g e
Page 68
EGERTON UNIVERSITY
USER MANUAL
FOR
SAHANI PLATFORM SYSTEM
REG. NO: S13/15358/16
PROJECT SUPERVISOR: DR. PHOEBE ONGALO
PROJECT COORDINATOR: DR. WILFRED G.

GIKARU
VERSION: 1.0
68 | P a g e
Page 69
General information
Technical specifications
This chapter describes the Sahani in general terms and provides details of the operating
environment and minimum configuration necessary for the satisfactory operation of the system.
Authorized use permissions

This Project is available to the general public. Users only need to register for accounts as
customers or restaurant owners. Restaurant’s staff can be added by the manages. Each user is
given a role id to identify the set of modules access to the user. Administrator features are for
management of restaurant
System features
On the home page of guest account, there are the following links at the top:
69 | P a g e
Page 70
Sahani logo it redirects to home page.
Login it redirects to customer login page.
Register it redirects to customer registration page.
General features
Registration
This is the first thing that a user is required to do in order to access other system features. It
requires a user to correctly fill in all details on the registration form. An activation link will be
sent to the registration email address. To complete the registration, a user has to click on the link
sent to their email address to activate their account.
Customer’s Registration page
70 | P a g e
Page 71
Restaurant’s registration page
In case of any errors, an error message is displayed in red text.
71 | P a g e
Page 72
Login
This feature allows registered users to log in to the system and access system features. A user is
required to enter the correct email and password. If any of this is not correct, an error message is
displayed containing error information. The login page also contains a link to reset a user
password, which redirects to page that allows user to enter emai address and a password reset
link is sent to the entered email. The link is located directly above the log in button.
Password reset
This feature allows a user to reset an account password in the event that a user has forgotten their
password. A user should enter their correct email and click the “submit” button. A reset
password link is sent to the user’s email address. A user clicks the link which redirects to reset
password page, where the user resets password and if successful then the user logs into their
account. In case a user inputs an email address that does not exist in the system, an error message
will be displayed.
72 | P a g e
Page 73
Customer’s features
Customer’s dashboard
Below is a screenshot of how the customer’s landing page looks like.
73 | P a g e
Page 74
Once the customer login successful, this landing appears. Here the customer is able to see the list
of module links. A user should click on any of the links to use a feature. The features accessible
from this dashboard are:
Dashboard
Restaurants
Profile Account
Make an order
The customer is able to view restaurant’s menus and make an order. The customer can also
confirm the orders
74 | P a g e
Page 75
75 | P a g e
Page 76
Customer’s dashboard
76 | P a g e
Page 77
view order history
View customers’ profile
77 | P a g e
Page 78
Restaurants features
Restaurant dashboard
Below is a screenshot of the restaurant’s landing page.
Once the restaurant login successful, this landing page appears. The restaurant is able to see all
the feature and clink on the links.
78 | P a g e
Page 79
Add menu
Restaurant is able to add menu. The screenshot is shown below.
View dashboard
79 | P a g e
Page 80
Add staff
Admin features
Admin dashboard
Below is a screenshot of the admin home page. Once the admin login successful, the landing
page below is shown.
80 | P a g e
Page 81
Admin Dashboard
Manage Restaurants
Here the admin is able to view users and can delete or change user.
81 | P a g e
Page 82
82 | P a g e

Project Documentation

Uploaded by

Document Information

Original Description:

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

Project Documentation

Uploaded by

Copyright:

Available Formats

EGERTON UNIVERSITY

PREPARED BY: BRENTONE ALISTAR

REG NO: S13/15358/16

PROJECT SUPERVISOR: DR. PHOEBE

PROJECT COORDINATOR: DR. W. GIKARU

DATES: April 2021

B. Some Limitations of current systems..................................................................7

Conclusions and Future work................................................................................................................12

External Interface Requirements...............................................................................................................26

Restaurant’s Orders List........................................................................................54

view order history..................................................................................................80

View customers’ profile........................................................................................81

Creation of your Stock Entries

Creation of products selling.

Creation of your System Users access levels

The input of your expenses

A wide range of customized Reports

The latest design features to ensure maximum user experience

High system security through the enabled log of system users

Report printing, receipts, and all category query reports

Overview and Literature review

B. Some Limitations of current systems

 Your business becomes Easy and efficient to manage and run.

The System Administrator has the privilege of Suspending, banning, or activating

Challenges, obstacles and risks

Schedule and budget.

Conclusions and Future work

REG NO: S13/15358/16

PROJECT SUPERVISOR: DR. PHOEBE

PROJECT COORDINATOR: DR. W. GIKARU

DATES: April 2021

Creation of your Stock Entries

The following terminologies are also used:

DDB Distributed Database

User Anyone who uses the application

OSDD Online Suspicious Discussion Detector

Intended Audience and Reading Suggestions

The System Administrator has the privilege of Suspending, banning, or activating

User Problem statement

Design and Implementation Constraints

Requirements and attached user manual.

Assumptions and Dependencies

Moreover, the implementation of these operational simulations to all instances of real-world

Generalized Model of operation

3.1.3 Functional Requirements

Other system features include:

A client/server system is a distributed system in which,

3.1.5 Dependencies with other requirements

The system requires a good internet connection as an external dependency with

Use case User Registration - Account Sign up(U1)

3.2.2 Priority - This requirement is a high priority.

3.2.5 Flow of events-

3.2.5.1 Basic Flow-

3.2.5.1.2 User accesses the system program registration page.

3.2.5.1.4 a verification information is sent to the email account.

3.2.5.2.1 User fails to verify the created account.

3.2.5.2.2 The account exits with verify the account prompt

3.2.5.3 Exception Flow – At step 3.2.5.1.4, the process encounters a problem.

3.2.5.3.2 No user registration info is submitted or stored. The registration process

3.1.6 Includes – None.

3.2.7.1 The system shall provide the option to skip registration.

3.2.7.3 The system shall display a default user avatar.