RENG Assignment Final

UC2F1811SE Requirements Engineering Group 2
Module Code : CT056-3-2 Requirements Engineering

Intake Code : UC2F1811SE
Lecturer Name : SIVANATHAN CHELLIAH
Hand in Date : 15 March 2019
Tutorial No. : 1
Group No. : 2
Student ID Student Name

TP042225 Kiirthana Ragaseagran
TP048946 Arvin Elangkovan
TP048986 Chua Li Hann
1
TABLE OF CONTENTS
1.0 Introduction ............................................................................................................................... 4
1.1 Project Background ............................................................................................................... 4
1.2 Current Flow of Operation .................................................................................................... 5
1.3 Project Assumption ............................................................................................................... 6
1.4 Problem Analysis .................................................................................................................. 7
1.4.1 Performance Problem..................................................................................................... 7
1.4.2 Information Problem ...................................................................................................... 8
1.4.3 Economics Problem ....................................................................................................... 9
1.4.4 Control and Security Problem ........................................................................................ 9
1.4.5 Efficiency Problem ...................................................................................................... 10
1.4.6 Services Problem ......................................................................................................... 11
1.5 Project Scope ...................................................................................................................... 12
1.6 Project Aims and Objectives ............................................................................................... 13
2.0 Schedule Planning ................................................................................................................... 14
2.1 Gantt chart ........................................................................................................................... 14
2.2 Workload Matrix ................................................................................................................. 15
3.0 Requirements Development Processes ................................................................................... 16
3.1 Elicitation ............................................................................................................................ 16
3.1.1 Customers .................................................................................................................... 16
3.1.2 Management (Tom and Sue) ........................................................................................ 18
3.1.3 Restaurants ................................................................................................................... 20
3.1.4 Drivers.......................................................................................................................... 21
2
3.2 Analysis............................................................................................................................... 22
3.2.1 Use Case Diagram........................................................................................................ 22
3.2.2 Use Case Specification ................................................................................................ 23
3.2.3 Context Diagram .......................................................................................................... 31
3.2.4 Level 0 ......................................................................................................................... 32
3.2.5 Data Dictionary ............................................................................................................ 33
3.3 Requirement Specification .................................................................................................. 35
3.4 Validation & Verification ................................................................................................... 37
3.4.1 Validation Techniques ................................................................................................. 37
3.4.2 Requirements Inspection and Checklist ....................................................................... 40
4.0 Requirements Management .................................................................................................... 45
4.1 Change Control ................................................................................................................... 46
4.2 Version Control ................................................................................................................... 47
4.3 Status Tracking ................................................................................................................... 48
4.4 Traceability ......................................................................................................................... 49
4.5 Requirement Management Tool Support and Planning ...................................................... 51
5.0 Weekly Reports ....................................................................................................................... 54
6.0 References ............................................................................................................................... 58
7.0 Appendix ................................................................................................................................. 60
7.1 Peer-to-peer assessment ...................................................................................................... 60
7.2 Software Requirement Specification (SRS)........................................................................ 68
7.3 Analysis Model ................................................................................................................... 74
7.3.1 Use Case Diagram........................................................................................................ 74
7.3.2 Context Diagram .......................................................................................................... 75
7.3.3 Level 0 ......................................................................................................................... 76
3
1.0 INTRODUCTION
1.1 PROJECT BACKGROUND
Waiters on Wheels is a restaurant meal-delivery service started in 1997 by Sue and Tom Bickford.
The Bickfords both worked for restaurants while in college and always dreamed of opening their
own restaurant. But unfortunately, the initial investment was always out of reach. The Bickfords
noticed that many restaurants offer takeout food, and some restaurants, primarily pizzerias, offer
home delivery service. Many people they met, however, seemed to want home delivery service
but with a more complete food selection.
Waiter on Wheels was conceived as the best of both worlds for Sue and Tom – a restaurant service
but without the high initial investment. The Bickfords contracted with a variety of well-known
restaurants in town to accept orders from customers and to deliver the complete meals. After the
restaurant prepares the meal to order, it charges Waiters on Wheels a wholesale price, and the
customer pays retail plus a service charge and tip. Waiters on Wheels started modestly, with only
two restaurants and one delivery driver working the dinner shift. Business rapidly expanded, and
the Bickfords realized they needed a customer computer system to support their business
operations. They hired your consultant firm to help them define what sort of a system they needed.
Sue described the current system as such “When a customer calls in wanting to order, I need to
record it and get the information to the right restaurant. I need to know which driver to ask to pick
up the order, so I need drivers to call in and tell me when they are free. Sometimes customers’ call
back wanting to change their orders, so I need to get my hands on the original order and notify the
restaurant to make the change.”
Tom continued, “The drivers get the copy of the bill directly from the restaurant when they pick
up the meal, which should agree with our calculations. The drivers collect the amount plus a service
charge. When drivers report in at closing, we add up the money they have and compare it to the
records we have. After all drivers report in, we need to create a deposit slip for the bank for the
day’s total receipts. At the end of each week, we calculate what we owe each restaurant at the
agreed-to-wholesale price and send them a statement and check.”
4
1.2 CURRENT FLOW OF OPERATION
5
1.3 PROJECT ASSUMPTION
The current system is entirely manual base system to run their daily business. In other word, the
current system is more to batch processing system. In a simple explanation, batch system mean
collecting data and groping the data into a batch and then processing the batch. So In this case
study they were few scenarios can be assume:
Using telephone / Land line
As it mentions in case study they were using telephone lines to receive and make order from
customer to restaurant and they also must call the delivery driver to get the current location for
next task. So, from here we assumed that they using telephone lines to make and receive orders.
No GPS tracking system
Besides that, in this case study have mention that to deliver the customers items the office staff
must make a call to the driver to get the latest location. Form here we can be assumed that their
existing system do not have location tracker to track and place the delivery for drivers.
Online ordering system
Last but not least, it can be assuming that their business is based on man power which mean
everything is written in black and white. As an evidence in third paragraph stated that that they
write the orders and record the conversation manually. In other word, we can that they don’t have
computerized system where it can do everything automatically
6
1.4 PROBLEM ANALYSIS
1.4.1 Performance Problem

1.4.1.1 Throughput
Throughput of Waiter on Wheels is awful as they are unable to receive many orders in a day. The
two telephone lines are utilized for ordering, forwarding order, changing order and calling drivers
for delivery, thus, there is a high possibility that the telephone line is continually engaged. Hence,
they can't have new requests coming in as the telephone line is constantly clogged with requests
from different clients. This will influence the business of Waiters on Wheels as a portion of the
clients won't have the capacity to reach and put in their orders.
1.4.1.2 Response Time
There will be high response time as the workers will have to manually write down the orders that
they receive from their clients. Some of the information that they should note down is client name,
contact number, address and the items which are ordered. The congested telephone lines will also
increase the response time as very less orders requests will have the capacity to break through to
them. Moreover, the delivery drivers should manually call and inform the organization that they
are free to do delivery services so they can be assigned to the next task. This will therefore also
increase the response time.
7
1.4.2 Information Problem
The output produced by Waiters on Wheels causes difficulties for deliver as they are utilizing a
paper-based system.
1.4.2.1 Output
Inaccurate and lack of basic information may occur. For example, inaccuracy of name and address
of the clients may occur if the staffs who is responsible at recording the requests neglected to their
duty professionally. The staff who was in control around then should be in charge of their
oversight. Lack of knowledge regarding the area of the delivery drivers or the availability of the
delivery drivers is also an issue in light of the fact that there is no specific system which enables
the organization to track on the delivery driver's area.
1.4.2.2 Input
The information given by the clients may not be accurately captured by the staffs and may contain
mistakes. The staff will have a high chance of recovering inaccurate data or orders or inaccurate
adjustment of orders since manual recoding of data are prone to human mistakes. Clients will
receive inaccurate orders, and this will lead the clients to feel disappointed. The staffs of this
organization may also face troubles to catch information from the clients as the telephone line
might be unclear or interrupted for the staff to receive orders. Information excess may also happen
if both the staff and clients lack in communication skills as it will be hard for them to understand
each other. Information duplication will also happen as the staff may catch similar information
more than once.
1.4.2.3 Stored Data
When utilizing the current system which consists of the utilization of telephone line and Manual
Paper-based System, clients may have changes in ordering after making orders. For example,
modification to-be-done on the previous orders made by the clients may be too late and is
impossible in time. This is because the current system is not a real-time based system where
information or data can be refreshed immediately if changes are made.
8
1.4.3 Economics Problem
1.4.3.1 Cost are Untraceable to Source
A manual inventory system depends more on the actions of people, which makes human errors
increase. Moreover, drivers may not be familiar with calculating the services charge as they may
make more mistakes. The daily revenue of the order may not be accurate as it depends on the
drivers report as well as it is calculating manually. Whenever there is a wrong order goes to the
customer, the order will be returned as the driver will call Tom and Sue to explain the situation for
them. As he will travel back to the restaurant to get the new order and then deliver it again to the
customer and that will affect the revenue because of the gas cost and the opportunity of this
situation is commonly.
1.4.4 Control and Security Problem

1.4.4.1 Less security and control
As the restaurant calculate the revenue manually and kept it in a hardware with Tom and Sue, there
will not be a security system that will know if the one who is using the hardware are Tom and Sue
or someone else. So, it is not fully secure. Moreover, the hardware might hang and loss some
important information. There will be another problem in case of the hardware get stolen as it will
be so easy to access to the restaurant information and details of the staff and customer. All these
data cannot be back if there is no cloud or backup space keeps this information secure.
9
1.4.5 Efficiency Problem
1.4.5.1 Data is redundantly input or copied
Each time a customer calls in to make an order, the phone operator will need to write down the
customer details even if the customer has made an order before. This repetitive process causes the
data to be recorded redundantly that reduces the efficiency of the ordering process.
1.4.5.2 Consolidate by location
In this current system, Tom and Sue does not consolidate the drivers, restaurants and delivery
location according to the location where it will be trouble for the drivers in order to collect the
food and deliver to customer on time when the locations are not consolidate. This will lead to more
time consuming on delivery and decrease customer satisfaction.
1.4.5.3 Waste Materials
When the phone operators take an order, each time they will need to record it on a new sheet of
paper. This will result in a lot of paper waste when the paper records are being disposed.
1.4.5.4 Excessive effort is required
Having to manually record the information and orders of customers each time they call in is very
tedious. Same goes to calling the restaurants to inform about the order as these processes could be
automated. Other than that, drivers who needs to deliver food will not be familiar the delivery
location. Therefore, drivers need to spend more time on their route by finding for a right route in
order to deliver the food to the right customer
1.4.5.5 Easy Usage
Having a manual record is not user friendly to use where all the operations are made through call
while there are low throughput. Thus will lead to excessive loss of customers when they are not
happy on using the system which is not easy to use. Other than that, customers are clueless with
the time of delivery whereby customers need to wait for the driver’s call in order to receive their
order.
10
1.4.6 Services Problem
1.4.6.1 System produces inaccurate results
When phone operators record the orders and details of customer, they might record it incorrectly
as it is being informed through the phone and the line might be unclear at that moment. This might
also occur when the phone operator calls to inform the restaurant and drivers about the customer
orders and information. When comparing the records with the daily revenue, it could have an
inaccurate result as well as the drivers might report in the wrong amount of money or the owner
took the old record instead of the new record that customers have made a change in order.
1.4.6.2 System produces inconsistent results
As the same information is being passed on multiple times through the phone from the customers
to the restaurant and drivers, the information transferred might be inconsistent. Therefore, creating
an inconsistent result. The records might be inconsistent as well as it is manually compared and
calculated.
11
1.5 PROJECT SCOPE
Justification
Because the business rapidly expanded, Tom and Sue Bickford realized they needed a
customer computer system to support their business operations. So we come up with the new
Website system for Waiters on Wheels that will accommodate and replace the old system, because
the old system will slow down the operation of Waiters on Wheels. This system will involve all
stakeholders to use it, it will basically record the order details made by the customers, record the
payment made by performing calculations, then track the driver availability for pick up the order.
Project Scope Description
This new Website system will allow the customers to make food order online, either with
desktop or smartphone. The system will record the order details from customer for instance the
details of foods and customer information then send it the corresponding restaurants to be ordered,
then the system will check the driver availability to pick up the order and send it to the customers,
after that it will receive the payment report from driver and do the calculation for income at the
end of the day also generate deposit slip for the bank. After the end of each week, it will calculate
how many they owe to each restaurants and create statement with check and send it to
corresponding restaurants.
Project Acceptance Criteria
The system needs to accept correct order information by the customers, then accept the
correct payment information (amount, etc.) from the driver then generate correct result for the
payment information.
Constraints
There are few constraints from this system:

1. The system needs internet connection in order for customers to create the orders because
this is Website system, if the internet/server is down then the system will down.
2. The system will need the database to store all the data, if the database computer is down
we can’t store any data and probably they will be lost. (Regularly data backup required).
3. The information of customers might be exposed to the internet like personal information
and credit card (Security system needed).
12
1.6 PROJECT AIMS AND OBJECTIVES
The primary of the proposed system is to develop a computerised delivery tracking system for
their daily routine business. It is aimed to improve the efficiency of the system. The existing system
which is the manual system is difficult to be handled and not very efficient. Besides that,
developing the new delivery tracking system, it is aimed to receive and send orders in a faster
manner to customers. Additionally, the proposed system will also be useful to very cost saving as
Waiters on Wheels aims to save cost and gain more profit.
The main objectives of the proposed system are to run the business more efficiently. By using the
tracking system, it will tom and sue can run their business with less input and more output. For
example, in new system we provide current location tracking system for delivery staff. We provide
this feature because in previous system tom and sue must call the drivers and ask them their current
location and let them know their next task. Where by in, this system tom and sue no need to make
any call via phones because once the system received the order it will look which driver is nearby
the delivery area to deliver their items. Moreover, the objective of the proposed system is also to
be more technological where all their restaurant operation computerized. All orders, delivery
notification and invoices should be stored in the computer and not manually. It can be store using
the databases. This would help to improve the business profit and quality of Waiters and Wheels.
13
2.0 SCHEDULE PLANNING
2.1 GANTT CHART
14
2.2 WORKLOAD MATRIX
Kiirthana Arvin Chua Li Hann

TP042225 TP048946 TP048986
Introduction Project Introduction and 33.33 33.33 33.33
Background
Problem Identification 33.33 33.33 33.33
Scope 33.33 33.33 33.33
Aim and Objectives 33.33 33.33 33.33
Proposed System 33.33 33.33 33.33
Scheduled Gant Chart 33.33 33.33 33.33
Planning Workload Matrix 33.33 33.33 33.33
Requirement Stakeholders Identification 33.33 33.33 33.33
Elicitation Requirement Discovery Techniques 33.33 33.33 33.33
Requirement Context Diagram 33.33 33.33 33.33
Analysis Data Dictionary 33.33 33.33 33.33
Use Case Diagram 33.33 33.33 33.33
Requirement Requirement Specification 33.33 33.33 33.33
Specification
Requirement Requirement Validation Process 33.33 33.33 33.33
Validation Requirement Validation 33.33 33.33 33.33
Techniques
Requirement Verification Process 33.33 33.33 33.33
Requirement Verification 33.33 33.33 33.33
Techniques
Requirement Requirement Management Plans 33.33 33.33 33.33
Management Requirement Baseline 33.33 33.33 33.33
Version Control 33.33 33.33 33.33
Requirement Attributes 33.33 33.33 33.33
Requirement Traceability 33.33 33.33 33.33
Change-Control 33.33 33.33 33.33
15
3.0 REQUIREMENTS DEVELOPMENT PROCESSES
3.1 ELICITATION
This section will be eliciting the requirements from stakeholders using a few elicitation techniques.
Below are the following stakeholders that are involved in Waiters on Wheels and their
requirements.
3.1.1 Customers
The requirements of customers of Waiter on Wheels are gathered through questionnaires using
online forms and physical paper forms. This method is used as it is believed to be the best approach
as the customers range is huge.
 Based on the result that gotten form customer we have made some conclusion what the
customer really expects from the system. The customer have complained that, the Waiters
on Wheels provide slow service throughout the process. Most of the customers have
complained that they have to wait for a long time in order to receive their items that they
have ordered. This was lead from 1.4.1.2 low response time as per mentioned in
performance problem.
 Due to low throughput referring to 1.4.1.1, some customer have complained that sometime
when they trying to order the order they couldn’t place the order due to heavily congested
telephone line.
 Moreover, the static also shows high percentage of customer not satisfied because they
never get what they have ordered. This is because the delivery person tend to send the items
to wrong destination. This was lead from an inaccurate input 1.4.2.1 and output 1.4.2.2
information problem.
16
So as a solution for all this problems form customers perspective view, the statics state most of the
customer prefer online ordering application as a solution. By providing this online application all
the customer’s able to place their orders based on the items amiability and no need to provide the
information every time whenever they place order. This is because in order to place an order using
this online application they must register as a member their account and provide the necessary
information. The customer also wish to edit their orders or in other word they prefer to change
their order in a limited time. For example, all the customer who have register able to edit, add,
view or cancel the order within 10 min. If they exceed specific time they will be charger fine as a
penalty. When we discuss about the system based on customers feedback they prefer to have a
simpler interface to make them easier to use the system or in other words the online ordering
system should be more graphical representation instead of text base For example, in the online
system it can display the real food picture in menu scree so customer easily can select their food
instead of reading the food discerption. In conclusion, most of the customer who have participated
in this questionnaire process prefer to have a computerised system in Waiters on Wheels daily
business.
17
3.1.2 Management (Tom and Sue)
The requirements of owners of Waiter on Wheels are gathered through the interview technique of
elicitation. This is because it is easier to meetup with the owners and able to get more accurate
information through interview. We try to conclude and categorize the answer from the owners,
examples of answer from the owners.
 When we discuss about the ordering function, the owner of this system need all the
transaction and ordering process in new system should be store in database. To make sure
the ordering take place in the new system the customer must register first. From here, we
can include that the customers information also should be stored as well for business
purpose. By storing the customer’s information in systems database it will be easy to
deliver the items that have purchased and it will be able to contact the customers if there is
any issues by referring to 1.4.2.3 stored data in information problem as discussed.
 Besides all that, tom and sue stated that in the new system there must be auto calculation
process, it mean the system able to count all the total price for the driver and also some
calculation for the management (profit, expenses, amount to pay restaurant) daily and
monthly there must be total sum amount that Tom and Sue should pay the restaurant
referring to 1.4.3.1 in economics problem.
 By doing this, it make the Tom and Sue to finish their daily accounting process and this
will be one step closer to paperless environment instead of writing and printing number of
papers where human errors are most likely to happen as referring to 1.4.5.1 in problem
analysis.
 When discussing about deliver the items in the new system, the owner (Tom and Sue)
prefer that the new system able to track the availability of the driver and which driver is
the nearest to send orders to the customers which refers to 1.4.6.1 in services problem. This
is because previously, the old process the owner have to call the driver one by one and ask
verify the amiability to deliver the items. Sometimes the owner couldn’t reach the driver
due to some reason so they couldn’t find and deliver the items wisely.
 Other than that, the owner stated that there must be a navigation system for drivers so it
will be easier for driver to be arrived at the destination instead of asking with people along
the way. So this feature also can make the driver to send the items on time without losing
somewhere in this route as per discussed in 1.4.5.4 in efficiency problem.
18
 Last but not least, the owner of this system stated that the new system must be easier and
convenient for the customer to user. Whereby they prefer to have more graphical
presentation in their system referring to 1.4.5.5 in efficiency problem. For example,
customer able to see the menu list with picture of it. So customer does not really have to
read the items detail and ordering it.
 Moreover, Tom and Sue stated there must be a detail of estimated arrival time for diver
arrive the item pick up location referring to 1.4.5.5 in efficiency problem. This will be more
convenient for the customer because they know the estimated arrival time so they can get
ready to collect it. Once the customer made the payment there must be a receipt send to the
customer and systems server as a reference. In new system Tom and Sue also stated there
must be a feedback functionality to track the customers experience and improve in business
plan process In a nut shell, based on the interview that have been conducted its crystal clear
that owner of this system need the new system to fix all the problem and improve their
business plan.
19
3.1.3 Restaurants
The restaurants are the panel of restaurants that will be featured in the system of Waiters on
Wheels. The panel of restaurants are placed in a focus group to gather their requirements. This
technique is used as we could identify the restaurants but there are too many of them to individually
meetup.
 For restaurants side they have complaint that some of the meals are cooked but there was
no driver to pick up the food, causing the food to be wasted referring to 1.4.6.1 in services
problem. This due to the orders that have missed out from waiters on wheels without Tom
and Sue knowing therefor they did not call for driver.
 Other than that, referring to 1.4.1.2 in performance problem the panel of restaurants also
complaints that drivers are quite slow in picking up the orders where the panel of restaurant
find it difficult on placing all the packed food which often causes confusions and
troublesome especially during peak hours.
All these problems can be solved by developing an online ordering system that will store all the
records and automatically assign the order to the restaurants, and has report generator to generate
reports accurately based on the orders taken from the system.
20
3.1.4 Drivers
Drivers is one of the most important stakeholders in this system, because they are the one that take
the order from restaurants and deliver it directly to the customers, also receive the bill from
restaurants and payment from customers. We need to know how they are organized by Waiters on
Wheels by observing the problem faced by the drivers on this current system.
 From what we observed from the system about the driver availability for pick up the
customer orders, they need to call in and tell that they’re free refer 1.4.1.1 in performance
problem. So we create assumption about the new system able to record driver’s
information’s. For example, the new system have driver full detail and information in
system database for security purpose.
 Moreover, the new system should be able to track the availability of the driver and which
driver is the nearest to send orders to the customers referring 1.4.5.2 in efficiency problem.
To track the driver’s amiability the system programed when the driver print the receipt to
the customer after deliver the system will detect that currently this driver is free and able
to next deliver. To track which driver is the nearest and suitable there will be a GPS system
will track and measure the deliver distance so the system will choose the nearest or shortest
distance driver to deliver the items.
 Other than that, the new system will provide navigation guide for destination that driver
doesn’t know the way to reach referring to 1.4.5.4 in efficiency problem. By doing this the
driveable to deliver the items on time and will be on track without losing anywhere. In new
system the drivers will be informed if there is any changes or the items that the drivers
going to deliver being cancel. For example, if there is some changes based on customer’s
decision the drivers have to change it back to the current order list.
21
3.2 ANALYSIS
After gathering the requirement from the stakeholder in the elicitation process, some models will
be used to demonstrate what the system should do. This is important to transform the requirement
that is in natural form into more specific, less ambiguous form. Analysis models such as the use
case diagram with use case specification, context diagram, level 0 with the data dictionary will be
used
3.2.1 Use Case Diagram
22
3.2.2 Use Case Specification
 Customer
Use Case ID U1
Use Case Login
Summary The customer can login to their website to
survey the information
Actor CUSTOMER
Pre-Condition Customer must login
Post Condition  Customer can edit their information
 Customer can delete the information
 Customer can view the information
 Customer can search the information
Exception Sequence If user is already is existed the system rejects
the new user
Sub Use Case --
Use Case ID U2
Use Case Delivery Status
Summary The customer can check the delivery status
and the restaurant will update the delivery
status
Actor CUSTOMER and RESTAURANT
Pre-Condition Customer must login and order the food
Post Condition  Customer can check the information
 Restaurant will update the delivery
status
Exception Sequence
Sub Use Case --
23
Use Case ID U3
Use Case Make Payment
Summary The customer after order food and make
payment by online method
Actor CUSTOMER
Pre-Condition Customer must login and order the food and
make payment
Post Condition  Customer order the information
 Customer make payment
Exception Sequence Customer make sure order food before make
payment
Sub Use Case --
Use Case ID U4
Use Case Make Order
Summary The customer can order the food
Actor CUSTOMER
Pre-Condition Customer must login and order the food
Post Condition Customer can make order various
type of food.
 Customer can order many food
Exception Sequence Customer should login and can order the
food
Sub Use Case Type of food, Personnel Details
24
 Restaurant
Use Case ID C1
Use Case Login
Summary The restaurant can login to their website to
receive the information
Actor RESTAURANT
Pre-Condition Restaurant must login and order the food
Post Condition  Restaurants can receive the
information

the new user
Sub Use Case --
Use Case ID C2
Use Case Receive Order
Summary The restaurant will receive the order
information
Actor RESTAURANT
Pre-Condition Restaurant must login and receive the order
information
Post Condition  Restaurants can receive the
information
 Restaurant can update information
Exception Sequence The restaurant will receive the information
and update it
Sub Use Case --
25
 Drivers
Use Case ID D1
Use Case Login
Summary The Driver can login to their website to
receive the information
Actor Driver
Pre-Condition Driver must login and view the information
Post Condition  Driver are able to view the order
 Driver can update their location
status
Exception Sequence Driver have their own unique profile
Sub Use Case --
Use Case ID D2
Use Case Retrieve Information
Summary The Driver login to retrive the information
Actor Driver
Pre-Condition Driver will need to login to view the
information
Post Condition  Driver retrieve the order and proceed
delivering it
 Confirmation of delivery has been
made
Exception Sequence Deliveries to multiple customer is limited
toits number
Sub Use Case --
26
Use Case ID D3
Use Case Delivery Confirmation
Summary The Driver confirm the deliver has been
made with receipt provided to the customer
Actor Driver
Pre-Condition Driver must login and confirm it
Post Condition  Driver confirm the delivery
 Driver provide receipt and remove
the order form the list
the new user
Sub Use Case --
27
 Management
Use Case ID M1
Use Case Login
Summary Management login to view and edit the
information
Actor Management
Pre-Condition Management will require to provide the valid
login information
Post Condition Management are able to login and
make use of the functions
Exception Sequence Every management staff has their own login
credentials
Sub Use Case --
Use Case ID M2
Use Case Report
Summary Management view the report provided
monthly, daily, or weekly
Actor Management
Pre-Condition Management will need to login before this
function is enabled
Post Condition Management view the reports in
various formats
 Reports can be filtered by the
management
 Management can export and import
reports
Exception Sequence Monthly report will only available at the end
of each month same goes to daily and weekly
which only available at the end of each day
and week.
Sub Use Case --
28
Use Case ID M3
Use Case Remove Driver
Summary Management will remove existent driver if
there are more suitable driver nearby
Actor Management
Pre-Condition Management will pass the information as fast
as possible to the driver
Post Condition  Management remove the driver
 Management update the customer of
the driver status
Exception Sequence --
Sub Use Case --
Use Case ID M4
Use Case Allocate Driver
Summary Management will allocate the most suitable
driver for the order
Actor Management
Pre-Condition Management will need to locate the nearest
and available driver
Post Condition  Management provide the order
information
 Management proceed to update the
order status
Exception Sequence --
Sub Use Case --
29
Use Case ID M5
Use Case Change Order
Summary Management will quickly change the order
and pass the info to the restaurant
Actor Management
Pre-Condition Management need to have the purpose
changes
Post Condition  Management change the order
information
 Management notify the party
effected by the changes
Exception Sequence Order can only be change within a period of
time
Sub Use Case --
Use Case ID M6
Use Case Retrieve Order
Summary Management will retrieve the order
submitted from the customer
Actor Management
Pre-Condition Management will only retrieve valid order
Post Condition  Management view the order and
place document it
 Management passes the order to
restaurant
Exception Sequence Only valid order are retrieved
Sub Use Case --
30
3.2.3 Context Diagram
31
3.2.4 Level 0
32
3.2.5 Data Dictionary
 Entity
Entity RESTAURANTS
Description Send the order information to the
management
Input Data Flows Send Status
Output Data Flows Receive Order
Entity CUSTOMER
Description Customer can login and make online order
and payment
Input Data Flows Change and cancel order
Output Data Flows Login, Make Order and Make Payment
Entity MANAGEMENT
Description Management can manage the system and can
cancel or change the order. Management can
allocate nearby drive to send to order
Input Data Flows Change/Cancel Order
Output Data Flows Allocate Drivers
Entity DRIVERS
Description Delivery the food on the time and send the
food to the correct place
Input Data Flows Receive delivery details
Output Data Flows Send Delivery Status
33
 Process
Process 1.0 ORDERS

Description Receive order from restaurants and delegate
it and send status back.
Input Data Flows Receive Order
Output Data Flows Send Status
Process 2.0 PAYMENT

Description Customer are able to make the payment,
order and may login the system as well.
Input Data Flows Login, Make Order and Make Payment
Output Data Flows Send Status
Process 1.0 ORDERS

Description Once drivers receives their details that may
start to send the order to the respective
customers
Input Data Flows Allocate Drivers, Receive delivery details
Output Data Flows Change/Cancel Order, Receive delivery
details
 Data Stores
Data Store Name REPORT

Description This data store will receive all the reports
given by drivers and payment
Input Data Flows Sales Report, Send Billing Report, Send
delivery report
Output Data Flows
34
3.3 REQUIREMENT SPECIFICATION
A software requirement specification (SRS) is a document that captures complete description

about how the system is expected to perform. It usually signed off the end of requirement
engineering phase. The software requirement specifications is developed to describe the functional
and non-functional requirement for Waiters on Wheels online delivery system. The aim of this
section is to be used by the developer that will implement and verify the correct functioning of the
system. The SRS is attached in the appendix. Following are some of the SRS contents.
 Introduction
The introduction gives an overview about the project and what can the user expected to read
in the SRS.
 Purpose
This section talks about the purpose of the SRS and how will the SRS used in the feature
 Project Scope and Feature
The system describes about the area where the project will be cover
 Reference
This section includes referencing of the outsource when creating the new system with website
provided.
 Overall Descriptions
This section displays a high-level overview of the system. It includes the product perspective,
type of users involve, environment, constraints, user documentation, assumption and
dependencies made.
 Product Perspective
This section describe view from the product side which include the release expectation of the
system
 User Classes and Characteristics
This section includes the user which will interact with the system and their characteristics.
35
 Operating Environment
This section describes about the environment that the system will be operating in.
 Design and Implementation Constraints
This section includes the constraints or the things that must be following when developing the
system.
 User Documentation
This section lists all the documentation that will be delivered with the system to help the user
understand more on the operating of the system.
 Assumption and Dependencies
This section will list the dependencies being made to the system and the dependencies of the
system will affect the operation of the system
 External Interface Requirements
This section list the requirements needed outside the system boundary.
 User Interface
This section describe about the graphical user interface of the system, the screen layout and
various interface needed.
 Hardware Interfaces
This section describes about the hardware interface and the extension hardware that needed for
the system.
 Software Interface
This section includes the software interfaces that needed by the system.
 Communication Interface
This section describes the interfaces that used by the system to send certain data to certain user.
36
3.4 VALIDATION & VERIFICATION
3.4.1 Validation Techniques

Requirements Validation phase ensures that the system is built accurately to the
stakeholder’s requirements. For the Waiters on Wheels system, several validation techniques were
used to ensure that the system is the product that the stakeholders at Waiters on Wheels want. The
following are the three validation techniques that were used.
1) Prototyping
The prototyping technique is one of the techniques that is for the implementation of the
proposed Waiters on Wheels system. By using this technique, the developers of the Waiters on
Wheels system are able to demonstrate a functional initial design to the stakeholders on
whether it is the type of system they want. The users that test the prototype of the Waiters on
Wheels system are able to test the functionalities and design options of the prototype and
provide feedback (Rapids Reproductions, 2019). The feedback gained contains information on
the strengths and weaknesses of the prototype. The feedback gained through testing will be
used to enhance the initial design of the product towards fulfilling requirements. Furthermore,
by using the prototyping technique, the prototype of the Waiters on Wheels system can be used
to check whether all functional and non-functional requirements are fulfilled based on
stakeholder’s requirements. In addition to that, the developers of the Waiters on Wheels system
can identify errors while prototyping in which problems that are found can be fixed before the
problems are carried towards the final product. Another advantage in testing is that the
developers are able to experiment with different solutions to problems with cost savings in
mind so that the final product will be built within budget. In addition to that, prototyping
requires stakeholders’ involvement for testing purposes as user acceptance is highly regarded
and revisions of the prototype are released each time there is a change in the system. Although
the prototype is often not delivered to stakeholders as the final product as it is only used for
testing purposes, there is a chance that a fully-functioning prototype is eventually turned into
the final product itself. Hence, proving how prototyping is one of the greatest techniques to be
used for the implementation of the Waiters on Wheels system.
37
2) Requirement reviews
The second validation technique that may be used to validate the system is requirement
reviews. As requirements review involves both the project team and the stakeholders, the SRS
documents are checked to identify any errors in terms of requirements. This method can also
be done formally or informally where it would simply involve discussion between the project
team and the stakeholders of Waiters on Wheels. By using the informal approach, many
problems can be identified just by discussing the requirements before making a formal
approach whereby each stakeholder of Waiters on Wheels is given a “walkthrough” of each
requirement and its implications (Requirements et al., 2019). By using this method, both parties
are able to check the requirements as a whole to ensure the system is complete or if there are
any requirements left out which makes this method one of the greatest methods of validating
the system towards meeting the requirements of the stakeholders of Waiters on Wheels.
There are many industry jargons that are used for accurate checking as shown below
 Verifiability proves how each requirement is able to be tested in real world

application
 Comprehensibility proves how much the stakeholders or end users of the Waiters
on Wheels system understand about the system based on the given requirements.
 Traceability proves how every original requirement of the Waiters on Wheels
system is addressed uniquely and clearly stated so that they are easily manageable
and traceable to assess the impact to the final product if there are any changes in
requirements.
 Adaptability proves how adaptive the requirements of the Waiters on Wheels
system are without having a large impact on other system requirements.
All the errors and conflicts are pointed out and documented by the project team of the Waiters
on Wheels system in which all the information is then used to find a proposed solution.
38
3) Test-case generation
In this method, the Waiters on Wheels project team identifies the difficulty to test a specific
requirement. The difficulty level of testing a requirement plays a big role in implementation of a
requirement because if it is difficult to test the system, it directly increases the difficulty of the
implementation of a specific requirement. Therefore, this method is used to check on how easily a
requirement provided by the stakeholders by the Waiters on Wheels is able to be tested. If it is
time consuming and requires ridiculous amounts of effort to test a specific requirement by the
stakeholder of the Waiters on Wheels system, then a different approach should be taken to
implement that specific requirement (Anchal Chauhan, 2018). This is a necessary step as it is
important to develop user-friendly tests instead of tests based solely on programming to ensure
that future problems can be reduced dramatically during implementation of the Waiters on Wheels
system.
39
3.4.2 Requirements Inspection and Checklist
Requirements Inspection can also be considered as a real world or virtual meeting in which
the design, codes and requirements of the proposed system are reviewed by other people. The
reason why the inspection technique should be used for the Waiters on Wheels system is to gain
reasoning from people viewing at the system from different angles because different people have
different perspectives. Since people who are not involved in the requirements and implementation
development of the Waiters on Wheels system are in charge of the inspection process, defects may
be easier to be identified as they have no exposure to the requirements and the implementation of
the system. In addition to that, inspectors may be able to share valuable knowledge and experience
on defect detection practices which would benefit the project team and stakeholders on identifying
defects during the early stages of development. This enables the flaws of the system and
requirements to be detected early which would provide benefits like reduction in error correction
costs, detection of flaws before extreme programming or solutions to the project team of Waiters
on Wheels system on the code which has error even before the underlying cause of the problem is
not discovered. Once the inspection process is done, the overall development effort and costs are
reduced dramatically.
Furthermore, inspection has great advantages over testing as it is able to cater for non-
functional properties such as maintainability, reusability and how evolvable the system can be. In
addition to that, other properties are very much tough to be test through testing such as scalability,
efficiency, security, integrity, exception handling and robustness are able to be identified better
through the inspection process rather than testing (Professionalqa.com, 2019). Besides that,
requirements, architecture and the design of the SRS documents of Waiters on Wheels cannot be
evaluated through an execution of test thus making inspection a great way for validation and
verification process.
There are three different kinds of inspection as shown and elaborated below:
1. Formal technical review

In this type of inspection, participants are the developers and designated key
individuals. This inspection requires advanced preparation by participants whereby usually
a typical checklist is used. Meetings that are held are led by moderators and not the author.
As meetings are formal, most information are documented and followed (Maurya, 2019).
40
2. Walkthrough
This inspection usually doesn’t require advance preparation beforehand as the author
discusses about the topics throughout the meetings. Furthermore, this inspection does not
require formal follow-ups and one of the benefits of it is its low cost. The type of inspection
for the Waiters on Wheels system will undergo is the formal technical review inspection.
Although it may be higher in cost, the likelihood of finding out bugs and errors is higher
in this type of inspection (Projectconnections.com, 2018. Below are the inspection process
steps used in the Waiters on Wheels system.
Inspection process steps
Step Description
Planning Confirms material to be inspected meets entry
criteria. Arranges the availability of
appropriate participants. Schedules a meeting
place and time
Overview Educates group of participants in what is to be
inspected. Assigns inspection roles to
participants.
Preparation Participants separately learn the material and
find potential defects
Inspection Meeting Identified defects are agreed on by the group
and classified
Rework The author corrects all defects the material
Follow-up The moderator or the entire team verifies that
all fixes are effective and that no additional
defects have been introduced
41
Step 1: Planning
In the planning stage the materials to be inspected throughout the Waiters and Wheel system are
checked whether they meet entry criteria. The Waiters on Wheels system meets the entry criteria
as the artefact of the Waiters on Wheels system is accompanied by the SRS document. In addition
to that, the availability of developers and project team of the Waiters and Wheels system is ensured
so that meetings scheduled on a fixing a place and time will be fully attended.
Step 2: Overview
In this step, the group of participants which consists of the developers and project team of the
Waiters on Wheels system is educated in terms of what the inspection is focused on. These
inspection roles are then assigned to participants of the meeting.
Step 3: Preparation
In this step, the participants of the inspection team separately learn up the material which is, in this
case, the SRS document and the Waiters on Wheels system implementation and defects are
identified.
Step 4: Inspection meeting
In this step, the identified defects of the requirements or system are discussed among participants
and solutions are discussed among one another. These defects then are classified in their respective
class for documentation.
Step 5: Rework
In this step, all the defects that are identified are reworked and fixed in the Waiters on Wheels
system
Step 6: Follow up
In this final step, the moderator of the inspection team and the other roles of the inspection team
that handles the documentation and implementation of the Waiters on Wheels system all the fixes
on the system and that no additional defects exist.
42
Inspection team assigned roles
The project team and developer along with the inspection teams are assigned in different roles as
shown as below along with their responsibilities.
Role Description
Moderator Responsible for administrative tasks,
disseminating inspection materials, scheduling
meetings, moderating the inspection meeting,
collecting data, overseeing follow-up, and
issuing the inspection report
Author Responsible for artifact to be inspected
satisfying inspection entry criteria, for
providing the overview of the product, for
providing clarifications at the meeting, and for
rework needed to satisfy exit criteria.
Reader During the meeting, leads the inspection team
through the artifact being inspected. Interprets
sections of the artifact by paraphrase.
Highlights important parts.
Inspector Familiarizes himself/herself with the artifact to
be inspected and identifies issues with it
Recorder Documents issues, decisions, and
recommendations. Records inspection data for
process analysis.
43
Checklist
Content Yes (Y) / No (N)

1. Do requirements exhibit a clear distinction between functions and
data?
2. Do requirements define all the information to be displayed to users?
3. Do requirements address system and user response to error
conditions?
4. Is each requirement stated clearly, concisely, and unambiguously?
5. Is each requirement testable?
6. Are there ambiguous or implied requirements?
7. Are there conflicting requirements?
8. Are there areas not addressed in the SRS that need to be?
9. Are performance requirements (such as response time, data storage
requirements) stated?
10. If the requirements involve complex decision chains, are they
expressed in a form that facilitates comprehension (i.e., decision tables,
decision trees, etc.)?
11. Have requirements for performing software upgrades been
specified?
12. Are there requirements that contain an unnecessary level of design
detail?
13. Have the real-time constraints been specified in sufficient detail?
14. Has the precision and accuracy of calculations been specified?
15. Is it possible to develop a thorough set of tests based on the
information contained in the SRS? If not, what information is missing?
16. Have Assumptions and Dependencies been clearly stated?
17. Does the document contain all the information called out in the
outline for the SRS?
Table 3.1: Requirement Inspection Checklist (Swqual.com, 2018).
44
4.0 REQUIREMENTS MANAGEMENT
Requirement baseline is complete after validation. A baseline document is created to be signed off
by Tom and Sue and other stakeholders. The requirement baseline documents including:-
 Use Case
Description of user requirements using scenarios.
 System Requirement Specifications
Detailed descriptions of the functionalites and services that should be performed by the system.
 Data Dictionary
Information that describes the data items and structure of databases and show relationship
between the data elements to provide better understanding for the stakeholders
 Analysis Model
Various graphical models, which are the context diagram, level 0 data flow diagram, use case
diagram are used to model the requirements.
The baseline document will be used as a basis of the requirement management process once
the stakeholders of Waiter on Wheels approve the document. Changes in the baseline
document after it has been approved will undergo strict change control as the project team has
to discuss with the stakeholders to get a revised agreement.
45
4.1 CHANGE CONTROL
Throughout the requirement engineering process, there are many changes that occur that affect the
system and the stakeholders. Many internal and external environment factors that cause the
changes and become quite difficult to manage. For example, rapid changes in technology and
changes in the law which causes the changes. Change management is not a standalone process for
designing a business solution. It consists of tolls, techniques and processes which manages the
process. The change management process has a sequence of steps that are implemented by a
change in requirements are not always negative. According to (SearchDisasterRecovery, 2019)
change in requirements are not always destructive. They are just guidelines or indications that
show the stakeholders about the requirements and restrictions of the system itself. Management
becomes difficult if changes occur rapidly without development. The process of requirements
change management is as follows:
 Problem analysis and change specification: During this stage, the problem or the change
proposal is analysed to check whether it is valid. The results of the analysis is sent back to
the change requestor who may respond with a more specific requirements change proposal,
or a request withdrawal.
 Change analysis and costing: The effect of the change is analysed using traceability
information and general knowledge of the system requirements. Once the analysis is
completed, a decision is made whether to proceed with the change in requirements.
 Change implementation: Based on the requirements document, the system design and
implementation are modified. Ideally, the document should be organized so that changes
can be easily implemented.
Thus, using good requirements engineering techniques and conducting change in requirements
quickly will help in achieving a successful and efficient change management process.
46
4.2 VERSION CONTROL
Version control is crucial in the documentation of the system and should be done carefully in order
to separate the versions of the SRS. By doing this, tracing back problems can be done easily by
going through the old documentation. The person who updates the document must take down the
changes in detail so that it will be a lot more convenient to to question the person who is responsible
should problems arise. As all of the requirements will be having their unique identifier, the version
of each requirement will be changed as well if a requirement is changed (Teach.branus.net, 2019).
For example, RF-1 is one of the functionalities to notify the driver of new order and RF-2 is one
of the functionalities to keep track of the current location of the driver and estimate the time needed
to get to the target destination. Based on the unique identifier above, the "R" stands for response
and "F" stands for functions. It is basically one of the alerting methods to notify the driver so that
they can respond on demand. If this requirement is changed or updated with additional features,
then the unique identifier for this requirement will be changed as well such as RF-1.1, RF-2.1 and
so on.
47
4.3 STATUS TRACKING
Proposed: The requirement will be proposed to the software development team if there are
any changes for any requirements. Later on, the software development team will decide on whether
to approve the proposed system based on the analysis on the changes of requirement.
Approved: Once there are any proposed changes, the development team will examine the
impact on the whole project and estimated resources that are needed such as time and budget.
Besides this, the changes in requirements have be reflected on the baseline which is identified in
the requirement specification initially. The requirement changes will be approved once the results
of the mentioned criteria are accepted.
Implemented: The requirement has been translated into a code based on the design of the
specification. The code will be unit tested later on in order to validate the correctness of the
requirement. Later on, the changed requirement will be written into the requirements specification
with updated version.
Verified: The implemented requirement has been verified for its correctness and
completeness by integrating the changed requirement to the fully functioning system. Besides this,
the requirement has been traced with various test cases to prevent any huge impact towards the
system.
Deleted: Removal of approved requirement from the baseline is made. Supporting

explanation will be provided in the documentation later on.
Rejected: Proposed changes of requirement that have been rejected. Rejected requirement
will not be implement furthermore. Supporting explanation will be provided in documentation
later on.
48
4.4 TRACEABILITY
Changes are bound to happen during requirement process. When making changes to a single
requirement, it may impact other requirements related to it and the system design itself. There are
many types of relationships among requirements. When incorporating those changes, the analyst
needs to trace the impact of those changes on other requirements and the overall system design
(Sommerville, 2011). This is where Traceability comes into play.
Traceability is used to ensure that the requirements defined enable developers to trace them
backwards to its origin, such as a use case, product feature or business rule. In addition, it can also
be traced forward into the bits of design, code and test plans that were created based of that
requirement (TechTarget, 2007). The process of tracking a requirement backward or forward is
called traceability analysis. Traceability analysis is undertaken to ensure that all the customer’s
requirements have been met and to easily track the impact when incorporating changes to the
system. The outcome of traceability analysis is Traceability Matrix (Chambers.com.au, 2011).
49
TRACEABIILITY MATRIX
Modify New Signup/ Record Generate Retrieve Report

Order Order Login Payment
Check Order Availability
IC-1 
IC-2   
IC-3   
UD-1
UD-2 
AD-1    
AD-2    
AD-3
UIR-1   
UIR-2    
UIR-3   
UIR-4    
HIR-1 
SIR-1   
SIR-2 
CIR-1 
CIR-2 
PR-1  
PR-2 
PR-3     
PR-4   
RR-1      
RR-2      
SR-1 
SR-2 
SR-3 
50
4.5 REQUIREMENT MANAGEMENT TOOL SUPPORT AND PLANNING
Requirement Management Tool is a software that will help to manage requirement

engineering process This is because managing the requirement manually is time consuming and
inefficient. With this management tool, we can store and trace back all of our requirements faster
and easier. If there are some requirements that needs to be changed, we can use management tools
because there are lot of requirements in the system so we shouldn’t do it manually (Bartlett, 2019).
This can save much more time in the requirements development and management processes.
A. Characteristics of a Requirement Management Tool (Eriksson, 2019)

 Store the requirements information
 Store the requirements attributes
 Check the requirements consistency
 Identify undefined or missing requirements
 Prioritize requirements
 Trace the requirements and to test the requirements functions
 Work as interface to test management tools
B. Reasons to use Requirement Management System
Manage version and changes
Requirement baseline should be defined for our project. With the help from a
Requirement Management Tool, we can keep track of the changes that have been made to
the requirements so we can revert back to the previous version of the system when needed.
Store requirement attributes
We need to store the attributes for each requirement because it can consist of a lot
of the information needed. With the help of requirement management tools we can generate
system-defined attributes and add additional attributes. With these features, it makes it
easier to select and view attributes of the requirements
51
Link requirement to other system elements
We can trace the requirements to other components of the system in order to ensure
that everything is clear during the implementation stage because there must be some
requirements that need to be linked to other requirements in order to define the links
between them with requirement management tools.
Track Status
During development process, we can track all the requirements status with ease to
know which requirements have been implemented and which requirements have not.
Control access
We can set permissions for the requirements information. Some requirements might
still be under revision and not be published yet, so we can define which requirements can
be accessed by the project team.
Communicate with stakeholders
With the help of requirement management tools, project members can discuss
project-related matters through e-mail if the project member is working remotely in order
to keep track of development.
C. Types of Requirement Management Tool (Scenarioplus.org.uk, 2013).

1) Heavyweight requirement management tool
This type of requirement management tool will help the team to manage all
requirements processes from beginning to end. Heavyweight requirement management
tools require a big investment because they are expensive and targeted for large projects
development. Examples: IBM Rational Requisite Pro, Rational DOORS.
52
2) Middleweight requirement management tool
This type of requirement management tool is targeted for medium-sized business and
organization so they are not expensive and does not require a big investment but they
provide a good set of tools for many requirements development and management
processes. Examples: Accompa Requirement Tool, Jama Software
3) Lightweight requirement management tool
This type of requirement management tool is suitable for small businesses and
organizations to work on small projects, because there is almost no need for
investments (some of the software is free) by providing just the essential tools for
developing the projects. Examples: liteRM, rmtoo
D. Benefits from using Requirement Management Tool

There are a lot of benefits that we can get if we choose to use requirements management
tools for developing and managing our projects. Some of the benefits are:
 Saves time to market the system
 Improve the overall quality of the system
 Increase satisfaction level of customers
 Achieve well-structured requirements
 Improve traceability of requirements
Basically, using requirement management tools will improve the overall progress of project
development because we can save more time and an improved requirements management.
Using requirement management tools is also much better to store all requirements of the
project rather than storing them in text files or documents (DiCenso, 2015).
53
5.0 WEEKLY REPORTS
Project Process Report 1
PROJECT PROGRESS REPORT Prepared By: Chua Li Hann

AS AT 19th December, 2018 Date of Last Report: None
Module: Requirements Engineering Report No.: 01
COMPLETED SINCE LAST REPORT
Task Description Date
Completed
1. None -
IN PROGRESS
Task Description Est. Start Date
1 PIECES Framework. 19 Dec 2018
Performance and Information
Economics and Control and Security
Efficiency and Service
2 Project Introduction, scope, objectives, aim and current flow of 19 Dec 2018
operations
OUTSTANDING FOR THE PERIOD ENDING :

1 None -
ISSUES/COMMENTS
None
Documentation Authorisation Date:
54
PROJECT PROGRESS REPORT Prepared By: Arvin A/L Elangkovan
AS AT 19th January, 2019 Date of Last Report: 19th December, 2018

Completed
1. PIECES Framework 23 Dec 2018
2. Project Introduction, scope, objectives, aim 23 Dec 2018
3. Current flow of operations 23 Dec 2018
4. Project Assumptions and solutions 23 Dec 2018
5. Gantt chart and schedule planning 26 Dec 2018
IN PROGRESS
Task Description Est. Compl. Date
1. Requirement Development Process 25 Jan 2019
2. Requirement management planning 4 Feb 2019
3. Requirements Identification 4 Feb 2019
4. Change requirement process 6 Feb 2019

1. Editing PIECES Framework. 19 Jan 2019
ISSUES/COMMENTS
Reworked PIECES Framework Explanation.
Did not complete within projected timeframe.
55
PROJECT PROGRESS REPORT Prepared By: Kiirthana Ragaseagran
AS AT 20th February, 2019 Date of Last Report: 19 January 2019

Completed
1. Requirement Development Process 3 Feb 2019
2. Requirement management planning 4 Feb 2019
3. Requirements Identification 8 Feb 2019
4. Change requirement process 10 Feb 2019
IN PROGRESS
Task Description Est. Compl. Date
1. Traceability 26 Feb 2019
2. Tool support 26 Feb 2019

1. Editing: Elicitation Documentation. 30 Jan 2019
ISSUES/COMMENTS
Elicitation explanation can be improved.
Did not meet targeted completion time.
56
PROJECT PROGRESS REPORT Prepared By: Kiirthana Ragaseagran

AS AT 28th February, 2019 Date of Last Report: 20th February 2019

Completed
1. Traceability 24 Feb 2019
2. Tool support 26 Feb 2019
IN PROGRESS
Task Description Est. Compl.
Date
1. Final editing and compilation. 3 Mar 2019

None -
ISSUES/COMMENTS
None.
57
6.0 REFERENCES
Anchal Chauhan, P. (2018). Test case Generation Techniques. [online] Ijcttjournal.org.

Available at: https://www.ijcttjournal.org/archives/ijctt-v57p112 [Accessed 14 Mar. 2019].
Bartlett, J. (2019). Top Requirements Management Tools List - TestLodge Blog. [online]
TestLodge Blog. Available at: https://blog.testlodge.com/requirements-management-tools-list/
[Accessed 14 Mar. 2019].
Chambers.com.au. (2011). Traceability Analysis | Requirement Management | Software

Engineering. [online] Available at:
http://www.chambers.com.au/glossary/traceability_analysis.php [Accessed 14 Mar. 2019].
DiCenso, K. (2015). Advantages of using a requirements management tool - Seilevel Blog -

Software Requirements. [online] Seilevel Blog - Software Requirements. Available at:
https://www.seilevel.com/requirements/advantages-of-using-a-requirements-management-tool
Eriksson, U. (2019). The Insider's Guide to Requirements Management Tools. [online] ReQtest.
Available at: https://reqtest.com/requirements-blog/requirements-management-tools/ [Accessed
14 Mar. 2019].
Maurya, A. (2019). What is FTR in SQA?What are its objective? Explain the steps in FTR.
[online] Available at: https://www.ques10.com/p/21338/what-is-ftr-in-sqawhat-are-its-objective-
explain-1/ [Accessed 14 Mar. 2019].
Professionalqa.com. (2019). Software Inspection |Professionalqa.com. [online] Available at:

http://www.professionalqa.com/software-inspection [Accessed 14 Mar. 2019].
Projectconnections.com. (2018). Requirements Walkthrough Checklist. [online] Available at:

https://www.projectconnections.com/templates/detail/requirements-walkthrough-meeting.html
Rapids Reproductions. (2019). The Advantages & Disadvantages of Prototyping - Rapids

Reproductions. [online] Available at: https://rapidsrepro.com/advantages-disadvantages-
prototyping/ [Accessed 14 Mar. 2019].
58
Requirements, E., Aurum, A., Wohlin, C. and Heidelberg, S. (2019). Engineering and Managing
Software Requirements | Aybüke Aurum | Springer. [online] Springer.com. Available at:
https://www.springer.com/us/book/9783540250432 [Accessed 14 Mar. 2019].
Scenarioplus.org.uk. (2013). Requirements Tools. [online] Available at:

http://www.scenarioplus.org.uk/vendors.htm [Accessed 14 Mar. 2019].
SearchDisasterRecovery. (2019). What is change control? - Definition from WhatIs.com. [online]

Available at: https://searchdisasterrecovery.techtarget.com/definition/change-control [Accessed
14 Mar. 2019].
Sommerville, I. (2011). Software engineering. Harlow: Pearson Education Ltd.
Swqual.com. (2018). [online] Available at:

http://www.swqual.com/images/requirements_checklist.pdf [Accessed 14 Mar. 2019].
Teach.branus.net. (2019). Requirements Management. [online] Available at:

http://teach.branus.net/CIS520/lectures/lecture11.html [Accessed 14 Mar. 2019].
59
7.0 APPENDIX
7.1 PEER-TO-PEER ASSESSMENT

Peer-to-peer assessment (Kiirthana Ragaseagran)
ASIA PACIFIC INSTITUTE OF INFORMATION TECHNOLOGY
CT056-3.5-2-RENG Requirements Engineering
Group No : Group 2
Name : Kiirthana Ragaseagran
Student ID : TP042225
Part A : Self Evaluation

1. What was your contribution to the project? Contribution
a) Project Background 33.33%
b) Current Flow of operations 33.33%
c) Project Assumptions 33.33%
d) Problem Analysis 33.33%
e) Problem Solution 33.33%
f) Project Scope, Aims and Objectives 33.33%
g) Schedule Planning 33.33%
h) Elicitation 33.33%
i) Analysis 33.33%
j) Specification 33.33%
k) Validation and Verification 33.33%
l) Change control 33.33%
m) Version control 33.33%
n) Status Tracking 33.33%
o) Traceability 33.33%
p) Requirement Management Tools 33.33%
q) Progress report 33.33%
60
r) Software Requirement Specification (SRS) 33.33%
2. Total amount of time spent in group meetings: 300 minutes
3. How many group meetings were held? 4
4. How many group meetings have you attended? 4
5. List reasons for not attending meetings, if any.

NONE
Please assess using the scale [1] [2] [3] [4] [5]
Never Rarely Sometimes Usually Always
I have made a serious effort at

x
assigned work before group meetings
I have attempted to make
x
contributions in group meetings
I have cooperated with the group

x
effort
61
Please List Team Members' Names Here

1. Chua Li Hann
Part B : Peer to Peer Evaluation

1. Do you feel that the distribution of the tasks was fair? Please explain.
Yes, the distribution was fair as everyone has the equivalent workload based on
their capabilities and the amount of tasks. Each meeting will be ended with
distribution of tasks to ensure the task can be done within estimated period..
[1] [2] [3] [4] [5]

Please assess using the scale
Has he / she made a serious effort at assigned work before group meetings?
Chua Li Hann x
Has he / she attempted to make contributions in group meetings?
Chua Li Hann x
Has he / she cooperated with the group effort?
Chua Li Hann x
Sign : _________________
62
Peer-to-peer assessment (Chua Li Hann)
Group No : Group 2
Name : Chua Li Hann

s) Project Background 33.33%
t) Current Flow of operations 33.33%
u) Project Assumptions 33.33%
v) Problem Analysis 33.33%
w) Problem Solution 33.33%
x) Project Scope, Aims and Objectives 33.33%
y) Schedule Planning 33.33%
z) Elicitation 33.33%
aa) Analysis 33.33%
bb) Specification 33.33%
cc) Validation and Verification 33.33%
dd) Change control 33.33%
ee) Version control 33.33%
ff) Status Tracking 33.33%
gg) Traceability 33.33%
hh) Requirement Management Tools 33.33%
ii) Progress report 33.33%
jj) Software Requirement Specification (SRS) 33.33%
63

NONE
[1] [2] [3] [4] [5]


x
x

x
effort

1. Arvin Elangkovan

[1] [2] [3] [4] [5]

Arvin Elangkovan x
Arvin Elangkovan x
Arvin Elangkovan x
64
Sign : _________________
Peer-to-peer assessment (Arvin Elangkovan)
Group No : Group 2
Name : Arvin Elangkovan

a) Project Background 33.33%
b) Current Flow of operations 33.33%
c) Project Assumptions 33.33%
d) Problem Analysis 33.33%
e) Problem Solution 33.33%
f) Project Scope, Aims and Objectives 33.33%
g) Schedule Planning 33.33%
h) Elicitation 33.33%
i) Analysis 33.33%
j) Specification 33.33%
k) Validation and Verification 33.33%
l) Change control 33.33%
m) Version control 33.33%
n) Status Tracking 33.33%
o) Traceability 33.33%
p) Requirement Management Tools 33.33%
q) Progress report 33.33%
r) Software Requirement Specification (SRS) 33.33%
65

NONE
[1] [2] [3] [4] [5]


x
x

x
effort

1. Kiirthana Ragaseagran

[1] [2] [3] [4] [5]

Kiirthana Ragaseagran x
66
Sign : _________________
67
7.2 SOFTWARE REQUIREMENT SPECIFICATION (SRS)
 Table of Contents
1 Introduction
1.1 Purpose
This Software Requirements Specification (SRS) describe about the software functional
and non-functional for the release 1.0 of Waiter on Wheels Ordering and Delivering System. The
intention of this document is to be used by the developer team that will implement and verify the
correct functioning of the system. This SRS documentation also serves as the agreement for the
stakeholders to agree what the system should do. All the requirements specified here are high
priorities and committed for releases 1.0.
68
1.2 Project Scope and Product Features
Waiters on Wheels, a restaurant with a manual ordering system which needed huge
manpower to carry on daily business process. In order to expand the business growth and compete
with others, an automated system is requested to maximize the throughput and response time. The
automated system is known as online ordering and delivery web application.
One of the product features is online ordering and delivering meal. It is able to receive and
retrieve the order to run the daily process of Waiters On Wheels. Besides this, GPS tracking system
helps to keep tracking on the drivers. The system can estimate the location of the driver and
destination of delivery meal and resulting in the most suitable driver to deliver the meal. Other
than this, the system also able to auto generate reports for daily sales based on the needs of the
client. Further details are explained in the following of this documentation.
1.3 References
1. Payment Credit Card Requirements
http://econnect.custhelp.com/app/answers/detail/a_id/654/~/payment-credit-card-requirements
2. Online Payment Processing
https://www.bankcardcentral.com/resources/learnaboutcreditcardprocessing/101onlinepayments.
html
2 Overall Descriptions
2.1 Product Perspective
The Waiter on Wheels Ordering and Delivering System is a new system that replaces the
current system that used the manual way of receiving order, forward order to restaurant and
delivering order. The external entities and system interface for release 1.0 are illustrated in the
context diagram that shown in Chapter 6.1. The system is expected to be fully functioning system
that is user-friendly after several releases.
69
2.2 User Classes and Characteristics
User Class Description

Owner (Tom Tom and Sue is the owner of Waiter on Wheels since 1997. As the business
and Sue) growth rapidly, Tom and Sue realize that they need a customer computer system
to support their business operations. A new system is needed because of the
problems that occur when using the current system. Tom and Sue want the new
system to accept the order made by the customer through online. Tom and Sue
also want the system carry out the business process automatically. These process
include the forward of the order to the respectively restaurant and the
recommended driver will be call to pick up the food. Tom and Sue will used the
system to generate the weekly sales report for themselves, the end-of-week
restaurant payment to the restaurant and the end-of-day deposit slip for the bank.
Restaurants Restaurant will used the system to check the information of the order made by
the customer. The information of the order made by the customer will forward
to the restaurant account and the restaurant will log in into the system to view
the order. Restaurant will be in charge of the status of the order, which include
“pending”, “cooking” and “delivering”. Customer can only edit the order when
the status is in “pending”. When restaurant start to cook the food, the status will
be updated to “cooking” and the customer is not allow edit the details of the
order. After the food has been cooked, the system will send the notification to
the recommended driver. When the food is handled to the driver, the order status
will now become “delivering”.
Drivers Driver is responsible to deliver the food to the customer. Each driver will have
to install a GPS Tracking System that integrates with the new system into their
vehicle. The GPS Tracking System will send the current location of the drive to
the system. Driver will need to update their own status into the system. When the
driver is delivering food, the status will become unavailable and when the driver
has finished the delivering, the status will be available. The information about
the current location and the status of the driver will be used for the system to
identify the most recommended driver to pick up the order. Notification will be
70
send to the driver that has been chosen for picking up the food. Driver will collect
the fees from the customer if the customer has not paid the fees online yet.
Customers There are two types of customer which are customer with membership account
and customer without membership account. Both of these customers can place
orders using the new system. The only difference is that the customer without
membership account will not get any benefit such as membership discount.
Customer with membership account will not have to key in their personal
information because it is already store in their account, while the customer
without account will need to key in their information when placing an order.
Customer can choose to pay the fees online or pay the fees on delivery. Online
receipt will be generating to the customer for referencing and security purpose.
Changes can be made to the order if the food status is “pending”.
2.3 Operating Environment
OE-1: The Waiter on Wheels Ordering and Delivering System shall operate with the
following Web browsers: Internet Explorer versions 8 and above, Google
Chrome version 40 and above, safari version 6 and above and Firefox version
45 and above.
OE-2: The Waiter on Wheels Ordering and Delivering System shall operate on the
SQL server database.
OE-3: The Waiter on Wheels Ordering and Delivering System shall permit the access
of 4 different users, which are the owner, customer, restaurant and driver.
2.4 Design and Implementation Constraints
CO-1: The proposed system shall be developed using ASP.Net, HTML and JavaScript.
CO-2: The proposed system shall be coded using Microsoft Visual Studio 2015.
CO-3: All HTML code shall conform to the HTML 5.0 standard.
71
2.5 User Documentation
UD-1: A user manual that illustrates and describe all system function will be provided
to the product owners for assistance purpose.
UD-2: A step-by-step tutorial on placing an order and checking the order status will be
available in the online system where the customer can access it if they need help
for placing a new order. The information of the order made in the tutorial will not
be store into the system.
2.6 Assumptions and Dependencies
AS-1: The operating hours for the online system is same as the business operation hour,
which is from 8.00AM to 11.00 PM every day.
DE-1: The operation of the Waiter on Wheels Ordering and Delivering System depends
on the changes being made by the restaurant regarding the available food and
beverage.
3.0 External Interface Requirements
3.1 User Interfaces
UI-1: Help link will be provided in each HTML page to explain how to use that
page.
UI-2: The web pages permit complete navigation using the mouse and keyboard
combination.
UI-3: All the web pages for the website will be linked with each other by
hyperlinks. User will be directed to another page accurately by these
hyperlinks.
72
3.2 Hardware Interfaces
HI-1: The system shall be able to run on the computer that using Windows
Operating System in Waiter on Wheels and Restaurant.
HI-2: Standard mouse and keyboard is required to interact with the system.
3.3 Software Interfaces
SI-1: GPS Tracking System that keeps tracks the location of the driver so that the
system can determine the recommended driver to ask for picking up the
order from the restaurant.
SI-2: Database System that store about the customer information, order
information, driver information, restaurant information and the available
food and beverage.
3.4 Communications Interfaces
CI-1: The system shall send an e-mail message to the customer to verify the
information provided by the customer when customer registers a new
membership account.
CI-2: The system shall send notification to the driver once the meal has been
prepared.
73
7.3 ANALYSIS MODEL
7.3.1 Use Case Diagram
74
7.3.2 Context Diagram
75
7.3.3 Level 0
76

RENG Assignment Final

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

RENG Assignment Final

Transféré par

Droits d'auteur :

Formats disponibles

UC2F1811SE Requirements Engineering Group 2

Module Code : CT056-3-2 Requirements Engineering

Student ID Student Name

1.0 Introduction ............................................................................................................................... 4

1.1 Project Background ............................................................................................................... 4

1.2 Current Flow of Operation .................................................................................................... 5

1.3 Project Assumption ............................................................................................................... 6

1.4 Problem Analysis .................................................................................................................. 7

1.4.1 Performance Problem..................................................................................................... 7

1.4.2 Information Problem ...................................................................................................... 8

1.4.3 Economics Problem ....................................................................................................... 9

1.4.4 Control and Security Problem ........................................................................................ 9

1.4.5 Efficiency Problem ...................................................................................................... 10

1.4.6 Services Problem ......................................................................................................... 11

1.5 Project Scope ...................................................................................................................... 12

1.6 Project Aims and Objectives ............................................................................................... 13

2.0 Schedule Planning ................................................................................................................... 14

2.1 Gantt chart ........................................................................................................................... 14

2.2 Workload Matrix ................................................................................................................. 15

3.0 Requirements Development Processes ................................................................................... 16

3.1 Elicitation ............................................................................................................................ 16

3.1.1 Customers .................................................................................................................... 16

3.1.2 Management (Tom and Sue) ........................................................................................ 18

3.1.3 Restaurants ................................................................................................................... 20

3.2.1 Use Case Diagram........................................................................................................ 22

3.2.2 Use Case Specification ................................................................................................ 23

3.2.3 Context Diagram .......................................................................................................... 31

3.2.4 Level 0 ......................................................................................................................... 32

3.2.5 Data Dictionary ............................................................................................................ 33

3.3 Requirement Specification .................................................................................................. 35

3.4 Validation & Verification ................................................................................................... 37

3.4.1 Validation Techniques ................................................................................................. 37

3.4.2 Requirements Inspection and Checklist ....................................................................... 40

4.0 Requirements Management .................................................................................................... 45

4.1 Change Control ................................................................................................................... 46

4.2 Version Control ................................................................................................................... 47

4.3 Status Tracking ................................................................................................................... 48

4.4 Traceability ......................................................................................................................... 49

4.5 Requirement Management Tool Support and Planning ...................................................... 51

5.0 Weekly Reports ....................................................................................................................... 54

6.0 References ............................................................................................................................... 58

7.0 Appendix ................................................................................................................................. 60

7.1 Peer-to-peer assessment ...................................................................................................... 60

7.2 Software Requirement Specification (SRS)........................................................................ 68

7.3 Analysis Model ................................................................................................................... 74

7.3.1 Use Case Diagram........................................................................................................ 74

7.3.2 Context Diagram .......................................................................................................... 75

7.3.3 Level 0 ......................................................................................................................... 76

1.1 PROJECT BACKGROUND

1.2 CURRENT FLOW OF OPERATION

1.3 PROJECT ASSUMPTION

Using telephone / Land line

No GPS tracking system

Online ordering system

1.4 PROBLEM ANALYSIS

1.4.1 Performance Problem

1.4.1.2 Response Time

1.4.2.3 Stored Data

1.4.4 Control and Security Problem

1.4.5.2 Consolidate by location

1.4.5.3 Waste Materials

1.4.5.4 Excessive effort is required

1.4.5.5 Easy Usage