Software Requirement Specification For Waiters On Wheels Information Technology Essay
This group project is about making a software requirement specification document for Waiters on Wheels. A software requirement specification 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.
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 notified with the changes in the order if any customer calls in to change the order.
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 difficult 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 filing 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 filing cabinets which are located in different areas and incase there is any need to retrieve any data it is difficult and time consuming.
Occupy a lot of space:
The data is stored in filing 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 difficult:
There is no proper way to communicate with the delivery boy and it is difficult 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 efficient, 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.
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 modification 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 modified order as well. All this is just a one click away.
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 different dishes. The search can be made on a variety of food menus. The customer will be able to filter 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 profits.
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
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 non-functional. 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 first 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 fill 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.
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 confirm 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 modified order upon selecting ‘modify this’ button.
1.5.4 The system shall create and display the new modified 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 confirmation dialog box with the delete order message.
Order status
1.7.1 The system shall load and display the status of the order.
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 modification 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 modification 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 modification 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.
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 specified 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 confirmation 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.
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).
Efficiency 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 fixes and patches.
2.6.2 The system shall generate logs of all changes, updates, or fixes 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 notifications
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
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 specific 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 defines 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.
The preliminary baseline requirements which got approved were accounted for the final 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 different 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, conflicts and miscommunication during the process the version name or identifier 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
SRS Document Release 1.2.
Abhijeet
5th Mar 2011
Version 1.3
SRS Document Release 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 unmodified.
An impact analysis is carried out on each change.
Every incorporated requirement change is traced to an approved change request
The justification 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 specific release.
Implemented: the requirements code for implementation has been designed, written and tested.
Verified: the implemented requirement has been confirmed for correct functioning in the integrated product. The requirement is traced for applicable test cases.
Rejected: the requirement is not planned for implementation in the upcoming release.
Deleted: the requirement has been removed from the baseline.
TYPES OF REQUIREMENTS
User requirements
Software requirements
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 different requirement engineering activities and we were able to understand the relationships between these activities. We were also introduced to different techniques of requirements elicitation and analysis. As we came to a finishing 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 different 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.
Order Now