This document summarizes a case study of a software engineering student project to design a restaurant management system. Key points: - Students designed and developed the software over one semester, using architectural styles like layered and shared repository. - The software allows employees to clock in/out, take orders, manage inventory, and generates sales reports. Managers can edit employee and menu items. - Testing focused on functionality, security, and usability. Formal usability testing was not possible due to time constraints. - Students struggled with translating architectures into design and managing project timelines around individual schedules. Knowledge of Java APIs also presented challenges. Lessons learned focus on introducing architectures earlier and improving time management.

1. A Case Study in the Design of a Restaurant Management System
Wesley Williams, Devon M. Simmonds
Department of Computer Science
University of North Carolina Wilmington
{waw5709, simmondsd}@uncw.edu
Abstract
Teaching software engineering at the undergraduate
level is an exciting and challenging undertaking. Students
come to software engineering with a variety of technical
and sift skills which have to be strengthened, honed and
channeled to produce desirable results. This paper reports
on the development of a restaurant management system as
part of a first course in software engineering. Results and
lessons learned are presented.
1. Introduction
At the undergraduate level, software engineering is taught
as both one-semester and two-semester course sequences.
In either format, teams of students create software with a
level of complexity commensurate with the course
sequence format. A familiar strategy to aid the teaching
and learning process is to have students develop software
in application domains to which can relate or are familiar.
Restaurant management is one such domain.
In the experience of the authors, some restaurant
management software while having reasonable utility
features geared towards tracking money and profits, seem
to have a significant lack where intuitiveness and usability
are concerned. Some restaurant management software
has weak or non-existent security, and in some cases,
functionality needed for day to day operations are only
available to managers. This results in the undesirable
situation where access to manager-level functions are
granted to lower-level employees. These problems may
have resulted from the designer’s lack of domain
knowledge, or from a lack of user involvement in the
design process.
This paper reports on the design of a restaurant
management software created as a team project in an
undergraduate software engineering course. The overall
goal of the project was to create an application where both
utility and usability are addressed. In particular, the
software should be easy to navigate and use while
providing basic restaurant management and security
features. In addition, the software should grant each
employee a level of access that is commensurate with the
duties and responsibilities required in performing duties.
When deployed, the application will serve as a single
working “point of management” system that acts as both a
terminal for taking orders and a terminal for generating
reports and managing changes to employee records.
2. Project Plan
The main focus of the project was to create a single
working “point of management” restaurant system that
acts as both a terminal for taking orders and a terminal for
generating reports and making changes to employees or
items on the menu. Project planning was done to define
the scope of the project, assess risks, and estimate and
schedule project activities and thereby lay the foundation
for the execution, monitoring and control of the project.
System
Manager
Server
Employee
Sign In
Manage Order
Manage Employee
Manage Inventory
Database Admin
Generate Report
Access Database
Figure 1: Use Case Diagram
2.1. Project Scope
2.2. The overall scope of the software is reflected in
the use case diagram shown in Figure 1. Major
software functions of the restaurant management
system include managing orders, inventory, and
employee records, and generating reports.
Order management includes creating and deleting orders,
adding and removing items from an order and closing
orders. Orders should also be stored in the database to be

2. used to calculate total sales. Inventory management
includes adding new products, deleting products and
updating products and resources.
The software is responsible for a number of other
functions. Our software must be able to add employees,
edit their information, and remove employees from the
employee database. Menu items must be added, edited,
and deleted from the menu item database. Items that can
be ordered must be able to be added and removed from an
order. All employees must be able to clock in and clock
out. Servers must be able to do what all employees do as
well as take orders. Managers should be able to do what
all employees do and be able to edit item and employee
information and generate reports. Reports that should be
generated include sales reports showing sales by food
category and the total sales from the start of the day.
Orders should also be stored in the database to be used to
calculate total sales. For a complete look at desired
functionality see page six.
The non-functional requirements of the project included
creating an intuitive, simple application that performs
consistently. To achieve these goals the project should
make menus effortlessly navigable and group user
interface (UI) components in a manner that makes them
easy to find. In addition, it was the opinion of the
development team that giving each employee the
appropriate level of access to resources was imperative
for usability and security.
2.3. Risk Plan
Table 1 shows three risks that were identified for the
project. The first of these risks is that of losing a member
of the development team. This risk has a higher
probability of occurring during the first weeks of the
semester and diminishes as the semester progresses. The
other two risks are more likely to occur and may occur at
any time. As such, risk prevention strategies were
developed and enacted. For example, soft copies of all
documents were stored by all members of the
development team to mitigate against loss of project
artifacts.
2.4. Project Estimates and Schedule
Estimates for time and resources were calculated based on
a developed work breakdown structure (WBS) for the
project. The first two layers of the WBS is shown in
Figure 2. Based on the WBS, tasks were assigned to
members of the development team as shown in Table 2.
The table identifies the persons who had primary
responsibility for the development of a specific artifact or
the management of a project task. However, all the
members were given opportunity to modify and perfect
artifacts and tasks assigned to other team members.
A schedule of tasks for the project was developed. The
result is shown in Figure 3. The chart shows that
implementation, testing and software design were the
major project tasks, with implementation and testing
consuming slightly more time than design.
Risk Prob. Impact Priority Actions
Losing a
project
member
2 9 10 Make sure
every team
member has
updated
copies of
work done by
all team
members.
Hardware
breaking
down
4 2 10 Make sure
every team
member has
updated
copies of
work done by
all team
members.
Task
takes
longer
than
expected
3 3 2 Trey will be
free for
helping other
members once
the initial
setup of the
database is
complete.
Table 1: Risk Assessment
Project
Management
Requirements
System
Design
Implement
ation
Testing/
Deployment
Monitor
Progress
Estimate
Resources
Asses
Risks
Evaluate
Results
Analyze
Functional
Requirements
Analyze
non-
functional
requirement
s
User
Interface
Database
Work Breakdown Structure
(The First 2 Layers)
Restaurant
Management
Project
Figure 2: Work Breakdown Structure

3. The project team was compromised of a group of
individuals with diverse programming and technical
backgrounds. Most had experience programming in
JAVA and .NET and most team members had a good
grasp on the problem domain as many of them had
worked in the restaurant industry at some point in their
lives. Management was partially done via electronic
means such as email and phone calls since many of the
members have different and often conflicting schedules.
The project manager scheduled one meeting per week for
face-to-face communication and to verify the project
status gain consensus and review completed individual
tasks.
Task Herbert Kyle Jacob Wesley
Project Planning
Resource List X
Work Breakdown
Structure
X
Resource
Estimation
X
GANTT Chart X
PERT Chart X
Responsibility
Matrix
X
Risk Plan X
Control
Mechanisms
X
Requirements
Analysis
Use Case Design X
Activity
Diagrams
X
Class Model X
Requirements
Dictionary
X
Limitations X
Non-functional
requirements
X
Software Design
Accept Payment X
Taking Orders X
Modify Orders X
Canceling Orders X
Sales Reports X
Labor Report X
Inventory Report X
Implementation
Database X
Check In/Out
System
X
Sales System X
Reporting System X
Software
Configuration
X
Table 2: Responsibility Matrix
ID Task Name Start Finish Duration
1 1.4w
1/15/2009
1/7/2009
Group Formation and Project Selection
Report Due
2 3.4w
2/9/2009
1/16/2009
Requirements Engineering Report Due
4 7w
3/27/2009
2/9/2009
Software Design Report Due
10 6.2w
4/27/2009
3/16/2009
Software Implementation and Testing
Report Due
9 3.2w
4/27/2009
4/6/2009
Testing
6 2.8w
3/24/2009
3/5/2009
Prototyping
7 2.2w
3/30/2009
3/16/2009
Implement Sales
8 1.2w
3/23/2009
3/16/2009
Implement Manager Functions
3
5 1.2w
3/9/2009
3/2/2009
Create Program Database
3.4w
3/3/2009
2/9/2009
Create Use Cases and Models
Figure 3: Schedule of Activities
3. Software Design
While it is acknowledged that design is not always
rational [8] and while we do not expect any silver bullet
[3], in our experience, software design becomes better
with practice and experience. For this project, the design
of the software included both architectural and subsystem
design. The architecture of software defines the major
software subsystems and the dependencies and
interrelationships among subsystems [1,2,4,6,7,10].
Architectural styles define a vocabulary for different
classes of architectures [5,9]. Examples of well known
architectural styles include pipe-and-filter, shared
repository and event driven. In this course, each software
development team was required to design the software
using two architectural. The architectural styles chosen by
the restaurant management team were the three-tiered
layered architectural style and the shared-repository style.
Database
CheckIn-CheckOut
Employees
Orders
Inventory
Items
Figure 4: Shared Repository Architecture

4. The shared repository architectural style is shown in
Figure 4. The design shows five major subsystems
interacting with a shared data store. While this design is
ideal for data driven applications that share a common
database schema, it constraints the evolution of the data
base as well as the data formats on the individual
subsystems. A layered architecture is shown in Figure 5.
Items
CheckIn-CheckOut
Employees
Orders
Inventory
Items
User Interface
Database Management
Employees
Orders
Figure 5: Layered 3-Tier Architecture
Employe SignIn Order
MainSystem OrderManagement
Clock DatabaseManagement
Item
Inventory
*
1..*
*
1
1
1
1
1
1 1
1..*
Figure 6: Class Diagram
alt
Login Menu
Management
Menu
Item Database
Edit Item Menu
Login()
SelectItemAndHitEditbutton()
loop [Done=false]
EnterChangesAndPressOK()
OK()
Done()
Cancel()
[Choice=cancel]
[Choice=enter]
Figure 7: Edit item Sequence Diagram
3.1. User Interface Design
Because of the nature of our project, an intuitive graphical
user interface was required. The user interface design in
Figure 8 is the JAVA Swing equivalent of the earlier
design. There are a few alterations that had to be made.
The buttons on the far right side on each screen have been
removed and put onto a single menu accessible after
login. On the first screen visible to the user we have
removed all buttons except the sign in button. The
functionality that was originally on this particular screen
has been moved to subsequent menus and screens. In
addition, we have added the clock functionality to every
screen in the program so that no matter which screen an
employee is viewing, he or she will be able to keep track
of time.
Figure 8: First user screen
The next screen (Figure 9) is where the employee can
choose which tasks he or she wants to do. Options that
appear grayed out are not available for the user that has
logged in. Managers have all options, servers have all
options except the management button, and finally normal
employee are only granted access to system to log in and
log out. All orders that are currently “owned” by this
particular employee are listed in the list above the “add”
and “edit” buttons. Below are three screenshots that show
this (Figures 10, 11, & 12).

5. Figure 9: Employee Task Menu
Management menu functions include the ability to add
and remove employees as well as items. Although our
group did not implement report generation, report
generation would be completed from the management
menu. Below are screenshots of the management menu
and the various submenus for editing employees and
items.
Figure 10: Ordering menu
Figure 11: Edit Item Menu
Figure 12: Item Type Selection
The ordering screen allows a server or manager to create
an order by selecting from four lists that represent the four
types of food: beverage, appetizer, entrée, or dessert.
When the item is selected, pressing the add button below
the list adds the item to a fifth list which is the actual
customer order. When the screen is exited, the
information is stored in the database. All the screens are
periodically updated with the current contents of the
database. The figure below is the ordering screen.

6. 3.2. Test Planning
Three goals were identified for the test plan: reliability,
security, and usability. Reliability and security testing
was accommodated by constructing test cases and
comparing expected and actual results. Usability testing,
however, is completely different. Usability testing would
require some domain experts to use the software and
perhaps even deploy the software in a restaurant
environment. Due to the time constraints of the project we
were unable to perform any formal usability testing using
persons external to the development team.
Test cases were created to test adding, deleting, and
editing both items and employees. Specifically these test
cases make certain that employee and items are stored and
retrieved from the database correctly. Test cases were
also generated to perform boundary testing on how many
entries could be successfully added or updated. In
addition, test cases where created to verify the function of
the compare class, which is used to validate input. The
table of test cases listed on the following page shows what
kinds of tests were performed on the “add new employee”
function, the intended results, and the actual results.
Test
Case #
Description Intended
result
Actual
result
1 Add new
employee (0,
Devon,
Simmonds,
12.35, 3245)
Employee(1
, Devon,
Simmonds,
12.35,
3245)
MANAGER
Employee(1,
Devon,
Simmonds,
12.35, 3245)
MANAGER
2 Add new
employee (0,
John, Smith,
21.55, 1245)
Employee(2
,John,
Smith,
21.55,
1245)
SERVER
Employee(2,
John, Smith,
21.55, 1245)
SERVER
3 Add new
employee (0,
Dan, Rather,
14.35, 378)
Employee(3
, Dan,
Rather,
14.35, 378)
NORMAL
Employee(3,
Dan, Rather,
14.35, 378)
NORMAL
4 Add new
employee(0,
45, 54, 23.12,
234)
Error Employee(0,
45, 54,
23.12, 234)
NORMAL
5 Add new
employee(0,
Hugh, Laurie, -
13.45, 546)
Error Error
6 Add new
employee(0,
William,
Error Error
Shatner,
27.68, -1532)
7 Add new
employee(0,
Hernan,
Cortez, 5.68,
10)
Error Employee(0,
Hernan,
Cortez, 5.68,
10)
Table 3: Sample Test Cases
4. Discussion and Lessons Learned
Students had some difficulty translating the architectures
into design. As Parnas has noted [8], design rationality
evolves as designers gain greater visibility into the artifact
being designed and greater experience. This is especially
true of novice designers who have little grasp of core
design principles. One way to address this problem for
institutions with only one software engineering
undergraduate course is to introduce architectural
concepts in the programming courses that precede
software engineering. A second approach would be to
introduce architectures very early in the software
engineering course using problems and solutions from the
earlier courses.
Students reported that their biggest challenge was time
constraints. Implementation takes an extraordinary
amount of time and a large amount of coordination.
Scheduling project meetings around individual group
member’s schedules creates many difficulties. Many of
the group members were unable to devote the amount of
focus that the implementation stage required. Both the
former and the latter problem may be more of an issue in
the academic environment where priorities of the different
group members are skewed in a variety of directions.
Another issue that cropped up was knowledge of the Java
programming language. At least two of the four group
members were unfamiliar with Java’s Swing API, which
is Java’s primary user interface package
The team identified the responsibility matrix as the
management construct most useful for managing the
project, coordinating activities and tracking continuous
improvement and overall success. All team members were
assigned tasks, and everyone was held accountable for the
completion of their assigned tasks. The responsibility
matrix also allowed the team to track tasks that need to be
done.

7. References
1. On Architecture. Booch, Grady. 2006, IEEE Computer
Society.
2. Bass, Len, Clements, Paul and Kazman, Rick.
Software Architecture in Practice (Second Edition). s.l. :
Addison-Wesley, 2008.
3. No Silver Bullet Essence and Accidents of Software
Engineering. Frederick P. Brooks, Jr. Los Alamitos, CA,
USA : IEEE Computer Society Press , 1987. 0018-9162 .
4. Software Architecture: a Roadmap. Garlan, David.
2000, ACM, pp. 91-101.
5. Garlan, David and Shaw, Mary. An Introduction to
Software Architecture.
[http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_so
ftarch.pdf] Pittsburgh, PA : Carnegie Mellon University,
1994. CMU-CS-94-166.
6. Architectual Blueprints -- The "4+1" View Model of
Software Architecture. Kruchten, Philippe. 1995, IEEE
SOftware 12, pp. 42-50.
7. Parnas, D. L. On the criteria to be used in
decomposing systems into modules. [DOI= http://0-
doi.acm.org.uncclc.coast.uncwil.edu/10.1145/361598.361
623]. s.l. : Commun. ACM, Dec 1972. Vol. 15, 12. 1053-
1058.
8. L. Parnas and P C Clements, “A rational design
process: how and why to fake it,” IEEE Transactions on
Software Engineering, 12(2):251-257, IEEE Press 1986.
9. Shaw, M., Garlan, D. Software Architecture -
Perspective on an Emerging Dicipline. s.l. : Prentice-Hall
Inc., 1996.
10. The Coming-of-Age of Software Architecture
Research. Shaw, Mary. 2001, IEEE , p. 656664.