Online Food Ordering Management System Project: Analysis & Design

This document outlines the development of an Online Food Ordering Management System (OFOMS) for Fingerlicking Foods, a small and medium enterprise. The project addresses the inefficiencies of the current manual and spreadsheet-based system, especially during peak hours. It details the problem description, proposed system capabilities including a relational database, customer and staff subsystems, and accounting features. The project provides an analysis of project approval factors such as estimated completion time (20 weeks), development costs ($48,500), and annual operating costs ($6,800). It also includes risk and feasibility analyses, the project environment, work breakdown structure, Gantt chart, functional and non-functional requirements, stakeholder identification, customer questionnaires, domain model class diagrams, use case descriptions and diagrams, activity diagrams, sequence diagrams, system components, storyboards, and deployment strategies. The anticipated benefits include increased orders, reduced order processing time, and improved accounting efficiency, alongside intangible benefits such as better customer satisfaction and advertising. This project offers a comprehensive plan for implementing a robust online food ordering system.

S
[Date]
[Document title]
[Document subtitle]
Student name
[company name]

Contents
Table of figures............................................................................................................................................1
1 identify the problem.................................................................................................................................2
System vision document..........................................................................................................................2
Problem description................................................................................................................................2
Proposed System capabilities..................................................................................................................2
Business benefits of the proposed system..............................................................................................3
2 Quantity project approval factors.............................................................................................................3
a. Estimated time for project completion................................................................................................3
b. Project development costs..................................................................................................................4
C. Estimated annual operating costs.......................................................................................................5
d. cost benefit analysis............................................................................................................................5
I. Anticipated benefits..........................................................................................................................5
II. Estimated annual benefits...............................................................................................................6
3 Risk and feasibility analysis.......................................................................................................................6
a. Organization risks and Feasibility.........................................................................................................6
b. Technological Risks and feasibility.......................................................................................................6
c. resources risk and feasibility................................................................................................................7
d. Schedule Risks and feasibility..............................................................................................................7
4. Project environment................................................................................................................................7
a. Information captured..........................................................................................................................7
b. Work environment..............................................................................................................................7
C Processes and procedures....................................................................................................................8
Reporting and documentation.............................................................................................................8
Programming.......................................................................................................................................8
Testing.................................................................................................................................................8
Deliverables.........................................................................................................................................8
Code and version control.....................................................................................................................8
5. Schedule the work...................................................................................................................................9
a. Work breakdown structure..................................................................................................................9
B Gantt chart.........................................................................................................................................10
6 Functional and non-functional requirements.........................................................................................11

6.1 Functional requirements.................................................................................................................11
6.2 Nonfunctional requirements...........................................................................................................11
7 Stakeholders...........................................................................................................................................12
8 Customers questionnaire........................................................................................................................12
9 Domain model class diagram..................................................................................................................15
10 Brief use case description.....................................................................................................................16
11 Fully developed use case description...................................................................................................16
12. Use case diagram.................................................................................................................................17
12 Activity diagram....................................................................................................................................18
13 Sequence diagram................................................................................................................................19
15 System components.............................................................................................................................20
16 Story boards.........................................................................................................................................20
17 deploy solution.....................................................................................................................................20
17.1 Converting and initializing data.....................................................................................................20
17.2 Training users................................................................................................................................21
17.3 Configuring the production environment......................................................................................21
17.4 Packaging, installing and deploying components..........................................................................21
17.5 Change and version control...........................................................................................................21
17.6 Testing...............................................................................................................................................21
18 References............................................................................................................................................21
Table of figures
Figure 1: Stakeholder map.........................................................................................................................12
Figure 2:class diagram...............................................................................................................................16
Figure 3: Use case diagram........................................................................................................................17
Figure 4: Activity diagram..........................................................................................................................18
Figure 5:sequence diagram.......................................................................................................................19
Figure 6: Architecture diagram..................................................................................................................20

1 identify the problem
System vision document
Online Food Ordering Management System (OFOMS)
Problem description
Fingerlicking Foods is a small and medium enterprise that deals with food delivery to its customers. The
business has grown overtime because of their good products and services delivered to their customers.
Due to fast growing rate of the business, the current in use by the system is proofing to be very
ineffective especially in the peak times of the day when many orders are made. The current system in
use by the business requires a customer to be registered if they are a first time customer. Most of the
operations are run by phone whereby if a customer calls the business they have to provide their
customer number. If the customer is new a quick registration is done over the phone. Their details are
recorded and a unique number sent to them via text. The unique number is used to identify the
customer onwards. After registering the customer, the customer can make their orders through the
phone. The order details are recorded and the customer is sent a confirmation text via SMS showing
details of the order and approximately how long it will take for the order to be delivered to their
address. The payment is done to the delivery man once the food is delivered to the customer. All details
are recorded in spreadsheets which is the primary way of storing data in the business. The current
system was effective when the business did not have a lot of customers and the orders it received per
day were not very many. Currently the new system is becoming very ineffective in regards to handling
the growing business. The current system in use is very cumbersome for the workers of the business
because of use of spreadsheets. Generation of reports by the management becomes a problem too
where by it’s hard to come up with good reports that can help facilitate decision making in the business.
There is need for a new system that will help manage day to day activities of the business. The new
system will completely replace the current system by improving all the aspects of the current system
and adding new features that will help in running of the system.
Proposed System capabilities
Here, system capabilities are discussed at a broad level to show why there is need for a new information
by showing its features. The capabilities of the proposed system are;
 Provide a compact relational database which will be used to store all the data generated by the
different business activities undertaken by the business.
 Provide a feature through which customers can be able to register in the database without
making calls to the business or going to the business premises.
 Provide a feature through which a customer can log in into their account and make an order for
a certain type of food. The customer should be able to see all the different types of food
delivered by the business and their ingredients among other factors like the delivery time and
the price of the food.
 Provide a feature through which customers can pay for an order while still using the system. This
can be achieved by use of PayPal checkout or payment by visa.

 Provide a feature through which the staff of the business all orders. These orders include the
most recent orders which have just arrived. The staff should then coordinate with the respective
to make sure that the food is prepared and delivered on time.
 Provide an accounting system for the business through which the business can see all the money
generated by orders within a certain timeline.
Business benefits of the proposed system
The main reason for purchasing the proposed system is to improve on the business process so that the
business may realize more profits an ultimately maintain a positive growing trend. This will be achieved
through use of the different features mentioned above by all the involved stakeholders. The visible
benefits if implementing the new system are;
 The new system will help ease the process of making an order by a customer thus giving the
customer more satisfaction.
 The new system will provide an easy way of managing orders made by the customers thus the
staff will be able to serve and deliver in time thus leading to customer satisfaction.
 The new system will provide an easy way of paying for orders by the customers where by
customers will be able to make a payment after making an order.
 The new system will help the management to generate different reports that can be used to
help make business related decisions for the business. The data can also be used for other
services like customer segmentation whereby for example a segment for loyal customers can be
derived from doing an analysis on the data. This can only be possible if a compact database has
been designed and deployed to act as the backend of the application system.
 The new system will help the business to advertise its different range of products. When a
customer visits the online application, they are able to see all the different types of foods that
they can order. The current system relies on making flyers which are given to customers during
delivery. This method is not very effective as compared to the online application which is easy to
convince the customer by use of images and videos which cannot be put on a flyer.
 The new application system will also help the business to have an online presence thus reaching
a wider base of customers.
2 Quantity project approval factors
a. Estimated time for project completion
The estimated time for project completion is based on the different stages that the whole project will go
through until the end product is delivered to the customer. The basic time factor to be used to
breakdown the time used for various stages is weeks where by work on the project will be done for five
days every week and for six hours every day. The project is s undertaken throughout the projected
development time but unforeseen cases which might cause the projected time to increase can be
considered if they arise underway during the project development.
Estimated completion time for Online Food Ordering System

Stage Functional
requirements
Iterations required Estimated time
Application database 5 5 3 weeks
Customer subsystem 6 3 4 weeks
Staff subsystem 3 3 3 weeks
Accounting subsystem 3 3 3 weeks
integration 4 4 weeks
Total development
time
18 weeks
Acceptance and
regression testing
2 weeks
Total project time 20 weeks
Table 1: Estimated project completion time
b. Project development costs
The following table shows the development costs that will be incurred as a result of developing the
system. The costs have been estimated to range below the recommended budget of the system and not
to surpass it.
Summarized development costs for the Online Food Ordering management system
Expense Amount (AUD)
Project manager (1) $16,000
Developers(3) $15000
Training $1500
Licenses $5500
Hardware $8500
Office space $2000
Total $48500
Table 2: Development costs
The project manager is estimated will be working for two hours every week by supervising and making
sure the project is being developed while sticking to the development plan and project budget. The
team manager is in charge of the whole project thus is assumed to be paid $40 per hour. The total cost
is broken down to;
2hrs for 20 weeks for $40/hr
2*20*40=1600
The system will be developed by a team of 3 developers who have been agreed to be paid $50 dollars
per day for the 20 weeks. The total amount results to ;
$50*3 developers * 5 days a week * 20 weeks= $15000
The training is supposed to be conducted for a week i.e. five days. The training takes place 2 hours every
day. One developer from the team of developer will conduct the training and will paid $1500 for the
whole training.
For the license an annual fee of $5500 will have to be paid for MySQL Enterprise Edition.

For the hardware required to implement the system a HP DL360P Gen8 server value at $4700 will have
to be purchased. This server has 2x Xeon E5-2640 six core processor which will be capable of handling all
the operations conducted by the business. This server also has a 16GB ram. 4 Desktop computers will
also be purchased valued at $500 each. The cost of networking the premises will cost $1500.
Total=$4700+$2000+$1500=$8200
The office space is will cost $2000 for the duration of time the project will be under development. The
cost includes temporary furnishing and setup.
C. Estimated annual operating costs
The estimated annual operating costs is the cost that will be at the expense of the business at the end of
every business year from the deployment of the system. The system is given a grace period of 1 year
under which any issues with the system are fixed for free. Other expenses are;
Estimated annual operating costs
Recurring expense Amount
License $5500
Static IP $300
Internet $1000
Total $6800
Table 3: Annual operating costs
d. cost benefit analysis
I. Anticipated benefits
The anticipated benefits of the system include both tangible and the intangible benefits. Tangible
benefits are measurable in terms of the monetary value they bring while intangible cannot but facilitate
to tangible benefits.
Tangible benefits
The following are tangible benefits that will be realized from the system;
 Increased orders- the number of orders processed for a day will rise as a result of implementing
the new system. This is because the new system will make it easier to handle new orders as they
arrive. Increase in orders can also be attributed to the fact that ordering with the new system
will be very easy for the customers.
 Reduced time in processing the orders by the staff. This will be achieved the new system will
make it easy for the staff to view new orders.
 Reduced time for accounting works in the business. The new system will make it very easy to
carry out different accounting tasks for the staff as it will make report generation easy and fast.
Intangible benefits
The following are the intangible benefits that will be realized by the system;
 Realization of an online presence for the business. This will help reach a wider customer base.
 Increased advertising through the website part of the system through which orders are made.
Display of other products and use of recommender system features to recommend to customers
other products are related to the product that the customer has purchased.

 Reduced workload for all the staff. The current system is cumbersome and the proposed will
come in place to reduce the workload by the workers.
 Ease of making an order for the customers. With the new system, customers will be able to
make orders and make payments very easily.
II. Estimated annual benefits
Estimated annual benefits
Cost saving/ Benefits Amount
Increased orders per day $150,000
Cutting outsourcing accounting $5000
Total $155000
Table 4: Estimated annual benefits
The increased orders per day is estimated to bring around $12500 per day. Collectively in one year the
amount can be accrue to $150,000. However, with increased orders, it means the business will have to
adjust and employ more delivery people so the cost of employing more delivery people is subtracted.
3 Risk and feasibility analysis
Feasibility analysis is a study done to determine whether it’s viable to undertake the project or
not(Kossiakoff and sweet, 2003). The study aims to proof that the benefits of the system outweigh the
risks that will be incurred as a result of implementing the system(MacDonough, 2013).
a. Organization risks and Feasibility
The current system in use by the business involves use of spreadsheets and other manual ways of
storing information generated by the business. Communication to customers is done by use of SMS
where by an employee has to draft the SMS by hand after receiving the order from the customer via a
phone call. The new proposed system will automate most of the manual processes that exist in the
current system. Due to automation and use of a new system, the following risks might arise and the
possible way they can be mitigated.
 Employees might take time to adapt to the new system as the new system is completely
different from the current as most of the processes are automated. This might require the
business to choose a strategic method of system changeover to enable the employees to adapt
to the new system. Parallel system changeover is recommended for this case.
 Some employees might be replaced by the automation of most of the processes by the new
system thus their roles will become obsolete to the business. This can lead to layoffs. However,
as the business is expected to get more orders the business can restructure where suitable to
incorporate some employees in the newly created positions.
 The fact that the system is running on machines which are prone to failure sometimes, the
reliability of the system is not always guaranteed as the system might experience some
downtime thus no business will be taking time during the downtime. This risk can be mitigated
by replicating of the system resources to eliminate a single point of failure.
b. Technological Risks and feasibility
System changeover is one of the reasons why projects and especially systems fail to take ground after
deployment. For the proposed system the business has to invest in the method of system changeover

because direct system changeover for this case might not work very well. A strategy like parallel system
changeover can be implemented as the training takes place so that the employees adapt to the new
system without causing technological risks.
Technology is ever changing so the issue of being left behind can be a technological risk in the future as
the competitors can implement better technologies in future that might overshadow the business. This
can be solved by doing regular updates.
c. resources risk and feasibility
The budget rolled out by the business is $50,000. This means that all the operations that are carried
during the different stages of the system development have to be constrained to the laid out budget.
One of the risks that might arise is underestimation of the budget thus the project ends up spending
more money than was budgeted. One way of dealing with recourses risk is to ensure a good
development plan is laid put before the start of the project. The plan will state how all the resources are
used during the development process.
Labor resource is another risk that can be experienced during the project development cycle where by a
team member can quit or fall sick and their role at that time is very crucial to the continuation of the
project. Replacing a team member with similar skills and capability with a lot of urgency can be
expensive and thus affect the laid budget.
d. Schedule Risks and feasibility
Schedule risks might happen if the laid out schedule timelines are missed and collectively the schedule is
not followed. This might result to missing of delivery of deliverables or delivery of the complete system
on time. Schedule risks can be caused by underestimation as a result of poor planning. To mitigate this
risk a detailed plan should be laid out before the start of the project.
4. Project environment
a. Information captured
Information repositories and tools
Information captured Tool Users
Project schedule Microsoft project professional Project manager
Annual/development costs and
annual benefits
Microsoft excel Project manager
Project documentation Microsoft Word Project manager
database MySQL database Staff, team members
Customer subsystem Dreamweaver Development team
Staff subsystem Dreamweaver Development team
Team communication Skype, email, WhatsApp Development team
Version control(Versioning) GIT Development team
Table 5: Information captured
b. Work environment
The work environment to be provided to the development team developing the system is very crucial to
the success of the system. The development team will be allocated an office space from where they will

develop the system up to when it’s deployed. The office should have high internet connectivity to make
sure that the tasks that require internet access are handled effectively. The team will also be provided
with an integrated development environment (IDE) to help ease the work. The IDE will be Dreamweaver.
C Processes and procedures
Reporting and documentation
The primary tool that will be used for reporting and documentation is Microsoft Word. The project
manager is responsible for making sure all the necessary documents are prepared including the project
documentation. The project manager has to record all the information about meetings that are held, the
costs accrued during the development of the project among other reports. Meetings are held twice very
week. The first meeting is held on Monday to outline the weekly plan and to assign different roles for
tasks to be performed that week. The second meeting is held on Friday to assess the week that was. All
this information should be recorded.
Programming
The programming approach is scrum. Scrum involves dividing the system into subsystems and those
subsystems into subsequent subsystems. The team members are then assigned different scrums which
are the parts of the system. The parts are interrelated so the team will have to maintain a good
communication strategy to make sure all the scrums are developed to perfection and are delivered on
time. The meeting held on Monday will be used to assign different scrums to the team members and the
meeting Friday will be used to review the scrums assigned to the team members. The team members in
the presence of team manager or not are supposed to hold to standup meetings every day; in the
morning and in the evening.
Testing
Testing will be done throughout the development of the project. This type of testing will be done by the
developers where by unit tests and component testing will be conducted on every step of the
development. When the system is completed, system testing and regression testing will be done by the
team of developers. Before deployment beta testing will be done using the actual users of the system
who are the staff of the business.
Deliverables
The project manager is in charge of making sure all the deliverables are achieved on time. After
requirements engineering, the first deliverable is a fully working database that is supposed to be derived
from the data functionality analysis. The next deliverable will be the design of both customer subsystem
and staff subsystem. Implementation will involve use of scrum until the final system is completed
Code and version control
Versioning of the codes will be done by use of Git. Using Git will help ensure that there is consistency in
the code. Upon delivery of a subsystem the version is saved in the Git repository. This will help to
control different versions that might arise from various changes done on that subsystem. The best
version of every subsystem will be used to form the complete system.
5. Schedule the work
a. Work breakdown structure
The following is the work breakdown structure for the Online Food ordering management system.

I. Project planning
1. Project manager and the development team and formulates the project plan- 2days
2. Project manager documents the plan and shares with all the team members for
revision-1 day
3. Project manager meets with the development team to draft a work breakdown
structure- 1day
4. Project manager arranges with the meeting with the Fingerlicking business management
team- 5hrs
II. Analysis tasks
1. Meeting with the development team to formulate and propose a project schedule that
will be used during the whole project while discussing the system from a business
perspective. 1 day
2. Document schedule and share with the development team- 3hrs
3. Do requirements gathering by visiting the Fingerlicking business to come up with the
functional requirements of the business by getting the usability goals from the different
users of the system. This will involve studying the current system- 4 days
4. Documents the results of the requirements engineering -1 day
5. Hold meeting to analyze the documented requirements to come up with the system
capabilities and functions-1 day
6. Meeting with the project team to analyze functional requirements to come up with a
structural diagram showing actors and use cases within the boundary of the system-
1day
III. Design tasks
1. Design the system database- 4 days
2. Test database use test data- 1 day
3. Design customer subsystem- 3days
4. Design staff subsystem- 3 days
5. Hold meeting to discuss and document the proposed designs- 1day
IV. Implementation
1. Implement the database on a MySQL server- 2days
2. Implement the design of the customer subsystem -3 days
3. Implement the design of the staff subsystem- 3 days
4. Formulate tests- 6hrs
5. Formulate test data- 6hrs
6. Test system- 2days
7. Hold meeting with the business staff for user acceptance testing- 1day
8. Implement proposed changes and additions by the Fingerlicking staff- 3days
9. Meet with the business staff to obtain their final approval on the system-5hrs
The work breakdown structure above is meant to act as a guide and may not completely be followed as
some tasks may take more time than projected while others might take lesser time than
projected(Makar, 2016).

B Gantt chart
The following Gantt chart has been designed using Microsoft project 2o16 and represents the work
breakdown structure demonstrated in the section above.

6 Functional and non-functional requirements
6.1 Functional requirements
The functional requirements of the online food ordering management system are the requirements that
translate to the business rules of the business (Bahil and Dean, 1997). The functional requirements state
what the users of the system expect from the system in order to achieve various tasks. The following are
the functional requirements of the proposed system for the business.
Area of operation Functions Description
Customer registration  Register
 Login
 Update profile
A new customer should be able to open
the system and create an account
registering using the customer
registration form. After registration the
customer can login and update their
profile.
Order operation  View foods
 Select order
 Make payment
 Get confirmation
message
A customer who wants to make an order
should be able to view foods available for
delivery, choose the food they want to be
delivered to them, make the respective
payment for the order and get a
confirmation message
Receive orders  View orders
 Confirm order
 Update status
The staff of the business should be able
to view new orders and confirm them
meaning that the order has been
received and is being worked on. When
the delivery person delivers to the
destination he or she update the delivery
status for that order.
Generate reports  Choose report type
 Generate report
The staff in charge of reports should be
able to generate types of reports using
the system.
6.2 Nonfunctional requirements
Nonfunctional requirements are requirements that do not translate but are necessary for the functional
requirements of the system to work effectively(Constantinides, 2014). Nonfunctional requirements
specify how a system is supposed to undertake a functional requirement in order to achieve a given
result.
The nonfunctional requirements of the proposed system are;
Category requirement
Performance The system should perform all processes using
the least amount of time.
Reliability The system should provide a high level of
robustness. It should be able to deal with any
errors that might arise
Availability The proposed system should be available at all
times

Usability The proposed system should be easy to use for
both the user and the staff.
7 Stakeholders
Stakeholders are directly or indirectly involved with a system. In other words stakeholders of a system
affect the path taken by a project in one way or another. There are four types of stakeholders for this
proposed system;
 Internal executive- actual users of the system who will be using the system when its deployed,
for example the staff or the customers
 External executive- this is the development team that will develop the system
 Internal operational- are internal to the business and have a very high influence on the
decisions made in the business
 External operational- these type of stakeholders are external to the business but have a high
influence on the decision made by the business
The diagram below shows the stakeholder map showing the stakeholders of the busness.
Figure 1: Stakeholder map
Stakeholders who will be using the system after its deployment are;
 Customers
 Staff in charge of orders
 Staff in charge of generating reports
8 Customers questionnaire
The primary focus of the proposed system is customers and how they make orders thus they play a
crucial role to how the system is implemented and how it will be used. The following questionnaire
shows the type of questions that could be addressed to customers to help in gathering functional
requirements (Seymour and Biemer, 2011).

Questionnaire addresses to a customer to get the customer’s view of the system
1. What do you think about the current system of ordering food for Fingerlicking Foods?
______________________________________________________________________________
______________________________________________________________________________
2. What would you like to be improved in the current system?
______________________________________________________________________________
______________________________________________________________________________
3. What do you think the customer registration page should contain?
______________________________________________________________________________
______________________________________________________________________________
4. How do you think the order foods page should look like
______________________________________________________________________________
______________________________________________________________________________
5. How would you like to pay for an order? (if none please give a reason)
Visa
PayPal
Any
None
______________________________________________________________________________
______________________________________________________________________________
6. What is your biggest issue with implementing a food ordering system?
______________________________________________________________________________
______________________________________________________________________________
7. How do you think the new system will improve the whole process of making orders?
______________________________________________________________________________
______________________________________________________________________________

Open ended response
Give your view on how the current system can be improved by stating what you like and don’t
like and what you think could remain if a new food ordering system is implemented
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________

______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
9 Domain model class diagram

Figure 2:class diagram
10 Brief use case description
Use case Description
Register When the customer opens the OFOMS for the
first time they are supposed to create an account
by registering using the customer registration
details
Login A customer needs to login using their username
and password in order to enter into their account
A staff can also login to access the web portal of
the application
Make order A customer who is logged into their account can
make an order by choosing the type of food they
want and making an order
Cancel order A customer can cancel order if it takes more time
that its supposed to take.
Make payment After making an order the customer is supposed
to pay for the total amount of that order
Manage food A staff can add ,update or delete a food
appearing in the website
Confirm order To confirm an order a staff has to view all new
orders and then confirm a specific order to
confirm it
Generate reports A staff member delegated for report generation
can generate different types of report in the
system.
Table 6: use case description
11 Fully developed use case description
Use Case ID: UC-1
Use Case Name: Make order
Created By: Student name Last Updated By: Student name
Date Created: 9/30/2017 Date Last Updated: 9/30/2017
Actor: customer
Description: A customer who is logged into their account can make an order by
choosing the type of food they want and making an order
Preconditions: Customer must be logged in
Post conditions: A message is shown
Priority: High
Frequency of Use: Frequent

Normal Course of Events: 1. Customer views foods
2. Customer select a type of food
3. Customer selects make order
4. System displays a status message of the order
Alternative Courses: 3. Customer makes order
3.1 Ordered food is not available
3.2 System displays message
3.3 System shows the online menu
Exceptions:
Includes: Checking food availability
Special Requirements: A customer must have a device capable of accessing the internet
Assumptions: Every customer knows how to use a computer and surf the
internet
Notes and Issues: The application has to be developed to adapt to all screen sizes
Table 7: fully developed use case description
12. Use case diagram
Figure 3: Use case diagram

12 Activity diagram
Figure 4: Activity diagram

13 Sequence diagram
Figure 5:sequence diagram

15 System components
Figure 6: Architecture diagram
The diagram above sows high level conceptual architectural diagram of the proposed system. The
system will run one server which will be configured to act as the web server and to host the database
server too. MySQL enterprise edition will be used for the database server while the web server will use
Apache. The operating system of the server will be Linux.
16 Story boards
There are four story boards that can be used to show the conceptual design of the system. These story
boards are;
Login
Make order
Confirm order
Generate report
17 deploy solution
17.1 Converting and initializing data
The current system in use by the business is use of spreadsheets to store data. These spreadsheets can
provide a basis on which data can be extracted and initialized by writing a script in the MySQL server to
translate the data in the spreadsheets into rows in the database tables.
17.2 Training users
The training will take place for five days upon which the different staff who are supposed will be trained.
The first training will involve all thee staff. It will provide an overview of the system. After the initial

training all the other trainings will distinguished by the type of user or role you have in the system where
by users with different roles will be trained independently
17.3 Configuring the production environment
Configuration of the production environment is basically configuring the server that will house the
database server and the web server. The server will have to be booted using Linux operating system
which is open source. After installation all packages necessary to install both MySQL enterprise Edition
and Apache will be installed. MySQL will then be installed and configured. Apache will then be installed
and configured to use the static IP purchased by the business.
17.4 Packaging, installing and deploying components
The OFOMS system is a web application so it does not have to be packaged into a setup. After
configuration of the web server, the application can be copied into the right directory and then tested if
everything is working correctly. The database will have to be transferred from the testing environment.
A dump of the structure of the database without the test data can be created and deployed in MySQL in
the production environment
17.5 Change and version control
By default OFOMS will be using Git for change and version control. This will ensure that no changes are
made directly on the production environment. Any changes will have to be made in Git and then the
changes are updated in the production environment to ensure all changes and versions are recorded in
case of referral in the future.
17.6 Testing
Testing on the system will be done from when implementation begins uto when the system is deployed.
Testing will begin from the first unit where by unit testing will be and component testing will be done on
the intergrated units (Pittet, 2015). When the system is complete system testing will be done. After
deployment regression testing will be done where by the testing will try to uncover faults.
18 References
Bahil, T., and F. Dean. (1997). The Requirements Discovery Process, SAND—96-2901C, Sandia National
Laboratories, Albuquerque, NM.
Constantinides , C. (2014, July 25). Functional Requirements vs Non Functional Requirements. Retrieved
August 20, 2017, from https://www.onedesk.com/functional-requirements-vs-non-functional-
requirements/
Kossiakoff, A. and Sweet, N. (2003). Systems Engineering Principles and Practices, Hoboken, N.J., John
Wiley & Sons.
MacDonough, M. (2013, April 30). Types of Feasibility Studies. Retrieved August 20, 2017, from
http://www.brighthubpm.com/project-planning/56372-types-of-feasibility-studies/
Makar, A. (2016, May 17). How to Make Your Project Schedule Work for You. Retrieved August 20, 2017,
from https://www.liquidplanner.com/blog/project-schedule-isnt-working/

Pittet, S. (2015). The different types of software testing. Retrieved August 20, 2017, from
https://www.atlassian.com/continuous-delivery/different-types-of-software-testing
Seymour, and Biemer, S. M. (May 24, 2011). Systems Engineering Principles and Practice, 2nd Ed.,
Hoboken, N.J., John Wiley & Sons.
System Design. (2015, November 15). Retrieved August 20, 2017, from
http://sebokwiki.org/wiki/System_Design
Types of Software Testing: List of 100 Different Testing Types. (2017, August 11). Retrieved August 20,
2017, from https://www.guru99.com/types-of-software-testing.html