Software Requirement Specification For Waiters On Wheels Information Technology Essay

9/23/2016
SoftwareRequirementSpecificationForWaitersOnWheelsInformationTechnologyEssay
Software Requirement Specication For

Waiters On Wheels Information
Technology Essay
Published: 23, March 2015
This group project is about making a software requirement specication document for
Waiters on Wheels. A software requirement specication document is a reference point
for questions and for detail about the problem to be solved and the motivation of a
project. The SRS that we are going to produce for Waiters on Wheels will discuss the
software requirements, functional requirements and non functional requirements for the
development of a computerized delivery tracking system for the company. This document
will also highlight on the current system, a detailed description of the new system and the
four phases of requirement development and requirement management for developing
the new system. The main objective of developing a new system is to provide easy
accessibility for its customers, a user friendly and a better management system for
Waiters on Wheels.
CURRENT SYSTEM
The current meal delivery system at Waiters on Wheels by Sue and Tom Bickford is a fully
manual system. The manual systems basically comprises of pen and paper. Such systems
are called manual systems because they involve data processing which does not make use
of any stored-program computing equipment. Listed below is an overall look of the
activities of the current manual system at Waiters on Wheels.
(/services/essay-writing-service.php)
When the customer calls in wanting to order, the details of the customer and the order are
recorded.
Details of order are sent to the right restaurant.
The delivery boy calls in and tells if they are free.
The free delivery boy is assigned the task of picking up the order.
The restaurant is notied with the changes in the order if any customer calls in to change
the order.
https://www.ukessays.com/essays/informationtechnology/softwarerequirementspecificationforwaitersonwheelsinformationtechnologyessay.php
1/14
9/23/2016
The delivery boy picks up the food from the restaurant with a copy of the bill.
On delivery the driver collects the bill amount plus a service charge
End of the day the amount the delivery boy has is compared with the records.
A deposit slip for the bank is created for the day's total receipts.
End of the week a statement and a cheque is sent for each restaurant at the agreed
wholesale price.
LIMITATIONS OF THE CURRENT SYSTEM

Time consuming:
The data entry is done by writing on paper and all the process are done manually. This
manual system of data entry and processes require time and a lot of time gets wasted.
Duplication of data:
It is dicult to keep track of the customer data and transaction details and hence the data
gets repeatedly written resulting in duplication of data.
Data insecurity:
The data is kept in cabinets and are openly available to anyone. Anyone might misuse the
personal details of the customers and other system data against the customer or the
company.
Human errors:
Human errors get in the way while processing data and the data loses its validity and
credibility.
Data inconsistency:
Misplace of data during manual ling makes the data unavailable for future use.
Work repetition:
Since the data is written on paper the data has to be reentered again if there are any
changes to be made and this result in repetition of work.
Excess of paper work:
Since all the customers' details and other data are written on paper there is too much of
paper work involved.
Slow data retrieval:
The data is stored in ling cabinets which are located in dierent areas and incase there is
any need to retrieve any data it is dicult and time consuming.
Occupy a lot of space:
2/14
9/23/2016
The data is stored in ling cabinets and these cabinets occupy too much space. The more
paper work done the more space required.
One driver One shift:
The current system has only one delivery boy working only in the dinner shift.
Delivery tracking is dicult:
There is no proper way to communicate with the delivery boy and it is dicult to track the
delivery boy status.
PROPOSED SYSTEM
The Waiters on Wheels, which started humbly with only just two restaurants and one
driver, have expanded their business very fast that their number of customers has
increased enormously in a short period of time. The manual system they have been
operating is no longer capable of tolerating the current business operations. They are in
need of a customer computer system to support their daily business operations. They are
in need of an ecient, a more reliable and a much secure system that would provide
home delivery system with a more complete food selection. This section will highlight on
the proposed computerized delivery tracking system for Waiters on Wheels.
(/order/)
FEATURES OF THE PROPOSED SYSTEM
Listed below are the features of our proposed system for Waiters on Wheels.
Administrative login
The proposed system will feature a simple user interface administrative login for creation,
deletion and modication of customer information, menu groups and menu items.
User-friendly GUI
The GUI (Graphical User Interface) of the proposed system is made in such a way that is
easy for customers to use and understand. Images and icons are been used to make it
more user-friendly.
Web-integrated database system
The system will also consist of a database that can hold large amount of data which is
integrated with the company's website. The database will hold all the details of its
registered customers and other important data.
One click ordering
In the proposed system customers can select food from various food menus and the
system will enable them to modify their order and send the modied order as well. All this
is just a one click away.
3/14
9/23/2016
Order status check

The customers can easily check on the status of their order. They can check if their food
order has been processed or if it's still pending. If the customer makes any changes in the
order the customer will still be informed about the new status.
Food menu
The proposed system will provide the customer with the search option for dierent
dishes. The search can be made on a variety of food menus. The customer will be able to
lter food menu according to vegetarian or non-vegetarian.
GPS and GPRS enabled smart device
Each delivery boy is provided with a smart device with GPS and GPRS enabled. This device
will help the delivery boy in updating his location and his current status.
Phone support
The proposed system is not only limited to online ordering but it encompasses a phone
support system where the customers can call and order through phone. This is a support
to attend the customers who have no internet access. Through phone support customers
can also check on the status of their order.
Report generation
It is important for a business to keep track of their daily transactions. The proposed
system will generate reports of their daily transactions and weekly reports which can be
used to compare the business prots.
OPERATING ENVIRONMENT
The Waiters on Wheels computerized tracking system shall operate on:
Windows 2000/2003/XP/Vista/7.
SQL Server 2002/2005.
Microsoft Internet Explorer 6.0 and above.
Mozilla Firefox 3.0 and above.
Google chrome.
Netscape.
*With JavaScript enabled.
FUNCTIONAL REQUIREMENTS
4/14
9/23/2016
A requirement, in context of software engineering, is a particular documented need a

product or software should perform. A requirement can be either functional or nonfunctional. Functional requirements of a system describe the systems services and states
how the system should behave to a particular input from the user. The functional
requirements mainly depend on the type of software, expected users and the type of
system where the software is used. The functional requirements of the proposed system
for Waiters on Wheels are divided in to the following main categories.
Registration
Sign in/Sign out
Selection menu
Filling order
Modifying order
Deleting order
Order status
Managing customer data
Managing restaurant data
Managing employee/delivery boy data
Generating reports
Payment
Registration
1.1.1 The system shall record all the details of the customer including rst name, last
name, address, email and password.
1.1.2 The system shall check if the customer is already registered or not.
1.1.3 The system shall prompt the user to update their address.
1.1.4 The system should allow the user to ll other details of the customer including age,
sex and occupation.
1.1.5 The system shall direct the user to the log in/sign in page upon registration.
Sign in/Sign out
1.2.1 The system shall load the sign in page.
1.2.2 The system shall ask for registration if the customer is not registered.
1.2.3 The system shall record the email address and password.
1.2.4 The system shall display 'sign in' button.
5/14
9/23/2016
(/services/example-essays/)
1.2.5 The system shall direct the customer to the ordering page upon signing in.
1.2.6 The system shall disconnect the user upon signing out.
Selection menu
1.3.1 The system shall load the page for selecting the available restaurants and food type.
1.3.2 The system shall display the default food types in a dropdown menu.
1.3.3 The system shall display the restaurants in a dropdown menu.
1.3.4 The system shall record the food type and restaurant upon pressing 'ok' button.
1.3.5 The system shall direct the user to the sign in page upon pressing 'back' button.
Filling Order
1.4.1 The system shall load and display the order page.
1.4.2 The system shall load the food items from the category selected by the user.
1.4.3 The system should display the default value of '1' for each quantity of food.
1.4.4 The system shall record the quantity of food the customer enters.
1.4.5 The system shall record and update the customer food cart upon every selection
from customer.
1.4.6 The system shall direct the customer to the payment page or conrm the order upon
selecting 'order this' button.
Modifying order
1.5.1 The system shall load and display Modify page.
1.5.2 The system shall record and update the order according to the update inputs from
the customer.
1.5.3 The system shall display the modied order upon selecting 'modify this' button.
1.5.4 The system shall create and display the new modied order upon selecting're-order'
button.
Deleting order
1.6.1 The system shall load and display the ordered food items.
1.6.2 The system shall clear the food items upon pressing 'delete order' button.
1.6.3 The system shall display the conrmation dialog box with the delete order message.
Order status
1.7.1 The system shall load and display the status of the order.
6/14
9/23/2016
1.7.2 The system shall display the estimated time for delivery.
Managing customer data
1.8.1 The system shall load and display the registered customers with their name, contact
number, address and the number of orders taken.
1.8.2 The system shall record and update the list of customers upon addition/registration
of a new customer.
1.8.3 The system shall record and update the list upon modication or deletion of any
customer.
1.8.4 The system shall print the customer list upon selecting 'print' button.
Managing restaurant data
1.9.1 The system shall load and display the list of restaurant partners with their name,
contact number, address and the amount due for each restaurant.
1.9.2 The system shall record and update the restaurant list upon addition of a new
restaurant.
1.9.3 The system shall record and update the list upon modication or deletion of any of
the restaurant.
1.9.4 The system shall print the restaurant list upon selecting 'print' button.
Managing employee/delivery boy data
1.10.1 The system shall load and display employees/ delivery boys with their name,
contact number, device ID the number of orders delivered.
1.10.2 The system shall record and update the list of employees upon hiring a new
employee/delivery boy.
1.10.3 The system shall record and update the list upon modication or deletion of any
employee/delivery boy.
1.10.4 The system shall print the employee/delivery boy list upon selecting 'print' button
Generating Reports
1.11.1 The system shall load and display the accounts of the company as a daily statement
with details of amount in RM.
1.11.2 The system shall do all the mathematical calculations upon giving inputs.
1.11.3 The system shall print the daily statement upon selecting 'print' button.
Payment
1.12.1 The system shall display the payment options for the customer, either by cash or
online.
7/14
9/23/2016
1.12.2 The system shall direct the customer to the secure payment gateway upon selecting
online payment.
1.12.3 The system shall load and display the secure payment gateway.
1.12.4 The system shall record and update the payment details upon payment.
NON-FUNCTIONAL REQUIREMENTS
Non-functional requirements are very critical requirements for any system. They are
criteria that judge the functioning of the system and are often called qualities of a system.
Qualities or the non-functional requirements of a system are mainly categorized into
execution qualities and evolution qualities. Since these so called qualities play a very
critical part of a system it is important to have a clear look at them. The new system
proposed for Waiters on Wheels must meet the following qualities or non-functional
requirements.
Performance requirements
2.1.1 The system shall be able to handle 1000 registered customers logged in at the same
time.
2.1.2 The system shall be able to load food menu and restaurants in less than 1 second.
2.1.3 The system shall be able to search for a specied food menu in less than 5 seconds.
2.1.4 The system shall be able to notify customer about the order status in less than 1
second.
2.1.5 The system shall be able to update delivery boy status in less than 1 second.
2.1.6 The system shall be able to validate credit cards/debit cards in less than 2 seconds.
2.1.7 The system shall be able to restore 1000 records per second.
2.1.8 The system shall display conrmation or denial messages in not more than 2
seconds.
2.1.9 The system shall be able to generate reports in less than 5 seconds.
2.1.10 The system shall be able to download the web pages in not more than 7 seconds in
a 50Kbps internet connection.
Security requirements
2.2.1 The system shall detect consecutive failed login attempts.
2.2.2 The system shall authenticate credit cards/debit cards against fraud.
2.2.3 The system shall encrypt all sensitive information via https.
2.2.4 The system shall encrypt all sensitive customer data in database.
8/14
9/23/2016
2.2.5 The system shall only allow the employees to add, delete or modify food menu and
restaurant menu.
2.2.6 The system shall allow customers to view only their order and not the food ordered
by other customers.
2.2.7 The system shall be protected by antivirus software, preferably by Kaspersky
antivirus.
Safety requirements
2.3.1 The system will do periodic backups of the database to ensure the latest updated
database is available.
Availability requirements
2.4.1 The system shall be available to customers at 99.99% during lunch time (between
1100 and 1400 hrs) and dinner time (between 1900-2100 hrs).
Eciency requirements
2.5.1 The system shall validate 'existing' credit card information in the system after each
log in when returning to customers.
2.5.2 The system shall automatically load default restaurants for a chosen food order.
2.5.3 The system shall validate email address existence.
Maintainability requirements
2.6.1 The system shall be easily updatable for security xes and patches.
2.6.2 The system shall generate logs of all changes, updates, or xes that are done to the
site.
2.6.3 The system shall be easy to upgrade.
Usability requirements
2.7.1 The system shall be easy to use.
2.7.2 The system shall prompt friendly and easy to read error messages.
2.7.3 The system shall be easy to learn.
2.7.4 The system shall make use of 'help' to assist customers and employees.
2.7.5 The system shall use constant symbols and colors for clear notications
Robustness requirements
2.8.1 The system shall enable the user to recover an incomplete order that has been
interrupted due to a connection error or internet failure.
Portability requirements
9/14
9/23/2016
2.9.1 The system shall be easy to migrate or backed up via USB drive.
Testability requirements
2.10.1 The system should be able to run under debug mode.
2.10.2 The system should be able to run test order mode.
2.10.3 The system should be able to run test credit card/debit card transactions.
REQUIREMENTS MANAGEMENT
Requirement management is an important process in requirements engineering and
software development. It is the process of managing changing requirements and it
includes all activities that maintain the integrity, accuracy, and currency of the
requirements agreement as the project progresses. In this project, requirements
management is carried out according to the following main stages.
Establishing the requirements baseline.
Controlling the changes to the requirements baseline.
Keeping project plans current with the requirements.
Controlling versions of both individual and requirements documents.
Tracking the status of the requirements in the baseline.
Managing the logical links between individual requirements and other project work
products.
ESTABLISHING BASELINE REQUIREMENTS
The very important step of requirements management is establishing a requirement
baseline. It is the set of requirements the development team is devoted to apply in a
specic release. A requirements baseline incorporates the original requirements plus or
minus the approved changes. The requirements baseline which is signed and approved
helps in the basis of ensuring the project is complete and it is very important as it denes
the scope of a project. Several steps were taken in establishing a requirement baseline for
the project.
The needs are collected and documented as requirements
These requirements are submitted for review.
The requirements which got approved were considered as the preliminary baseline
requirements.
The requirements which got rejected underwent exclusion.
The requirements in the preliminary baseline were reviewed again.
10/14
9/23/2016
The preliminary baseline requirements which got approved were accounted for the nal
baseline requirements.
The requirements in the preliminary baseline which got rejected are taken to review
exception stage.
The requirements which get approved from review exception stage are sent to the
preliminary baseline again, and the ones which got rejected were sent to the exclusion.
(DIAGRAM)
VERSION CONTROL
Version control is one of the essential stages in requirement management process. During
the project of Waiters on Wheels, every version of the requirement document is kept in
dierent and unique names. It is made sure every member is accessible to current
requirement document and is surely informed about the changes. To minimize confusion,
conicts and miscommunication during the process the version name or identier is
changed every time there was a requirement change and the privilege was given to the
designated individual only.
A Revision History is attached with each circulated requirement document stating the
changes made, the person who made the change, the date of each change, and the reason
for each change. An appending version number is given to each requirement document
which is incremented every time a change was made and the version renewed. Below is a
sample Revision History practiced during the version control process.
Date
Version
Description
Author
2nd Jan 2011
Version 1.1
SRS Document Release 1.1.
Arun
4th Feb 2011
Version 1.2
11/14
9/23/2016
Abhijeet
5th Mar 2011
Version 1.3
Shifan
Fig 1.1: Sample revision history.
CHANGE CONTROL MANAGEMENT
The change control process is driven by the Change Control Board (CCB) which includes
people from both parties. It is the Change Control Board who decides whether a change
needs to be allowed or denied. The change control process is carried under the following
policy.
All requirement changes are carried according to the process. If not, it is not considered.
Only the feasibility study is carried on unapproved changes. No design or implementation
is carried out.
Not every request is guaranteed of the change. Only the CCB decides the changes for
implementation.
The changes in the database have to be visible to all stakeholders of the project.
The original of change request is kept unmodied.
An impact analysis is carried out on each change.
Every incorporated requirement change is traced to an approved change request
The justication of every approval or rejection of a change request is recorded.
TRACEABILITY MATRIX
REQUIREMENT STATUSES
In a project development it is more meaningful to classify the status of its requirements
into main categories than comparing it with percentage completion. Some of the statuses
used in the project are:
Proposed: the requirement request from user.
Approved: the requirement has been analyzed and allocated for the baseline of a specic
release.
Implemented: the requirements code for implementation has been designed, written and
tested.
UKESSAYS(/)
12/14
UKESSAYS(/)
9/23/2016
Veried: the implemented requirement has been conrmed for correct functioning in the
product. The requirement
is traced for applicable
test cases. (/myaccount/)
Print
integrated
Rejected:
the requirement is not planned for implementation in the upcoming release.
(https://www.facebook.com/sharer/sharer.php?u=https://www.ukessays.com/essays/information-technology
Deleted:
the requirement has been removed from the baseline.
(https://plus.google.com/share?url=https://www.ukessays.com/essays/infor
waiters-on-wheels-information-technology-essay.php)
TYPES
OF REQUIREMENTS (https://twitter.com/intent/tweet?
information-technology-essay.php)
text=Software%20Requirement%20Specication%20For%20Waiters%20On%20Wheels%20Information%20Technol
User requirements
technology/software-requirement-specication-for-waiters-on-wheels-information-technology-essay.php&via=ukes
Software
requirements
url=https://www.ukessays.com/essays/information-technology/software-requirement-specication-for-waiters-on-w
Functional requirements
Non-functional requirements
Domain requirements
CONCLUSION
This project has been a real good learning experience for all of us. The project helped us
enhance our knowledge about requirements engineering process and its components.
During the project we were exposed to dierent requirement engineering activities and
we were able to understand the relationships between these activities. We were also
introduced to dierent techniques of requirements elicitation and analysis. As we came to
a nishing point of this project we learned the importance of requirements validation and
the important role the requirement reviews play in the validation process.
We were also able to broaden our knowledge on the requirements management process
as a whole. The knowledge about dierent stages in the management process, why these
stages are necessary and how they support the other requirements management activities
are the areas we have a clear understanding now.
Request Removal
If you are the original writer of this essay and no longer wish to have the essay published
on the UK Essays website then please click on the link below to request removal:
REQUEST THE REMOVAL OF THIS ESSAY
More from UK Essays

Information Technology Essay Writing Service
UKESSAYS(/)
13/14
9/23/2016
UKESSAYS(/)
Essays
Print
(/myaccount/)
More Information Technology Essays
(https://www.facebook.com/sharer/sharer.php?u=https://www.ukessays.com/essays/information-technology
information-technology-essay.php) (https://plus.google.com/share?url=https://www.ukessays.com/essays/infor
waiters-on-wheels-information-technology-essay.php)
Information Technology Dissertation Examples

(https://twitter.com/intent/tweet?
Examples of Our Work
text=Software%20Requirement%20Specication%20For%20Waiters%20On%20Wheels%20Information%20Technol
technology/software-requirement-specication-for-waiters-on-wheels-information-technology-essay.php&via=ukes
url=https://www.ukessays.com/essays/information-technology/software-requirement-specication-for-waiters-on-w
Place Your Order Today

Take the next step and invest in your future
PLACE AN ORDER
(/order/?product=2)
Copyright 2003 - 2016 - UK Essays is a trading name of All Answers Ltd, a company registered in England
and Wales. Company Registration No: 4964706. VAT Registration No: 842417633. Registered Data Controller
No: Z1821391. Registered oce: Venture House, Cross Street, Arnold, Nottingham, Nottinghamshire, NG5
7PJ.
UKESSAYS(/)
14/14

Software Requirement Specification For Waiters On Wheels Information Technology Essay

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Software Requirement Specification For Waiters On Wheels Information Technology Essay

Hochgeladen von

Copyright:

Verfügbare Formate

9/23/2016

Software Requirement Specication For

LIMITATIONS OF THE CURRENT SYSTEM

Order status check

A requirement, in context of software engineering, is a particular documented need a

More from UK Essays

More Information Technology Essays

Information Technology Dissertation Examples

Place Your Order Today

Das könnte Ihnen auch gefallen