!

!
!
!
!
!
!
!
!
!
!
!
!
Boba Gett
Final Report
Created by Systems, Inc. for Beautea, LLC
Group 3
Varqa Azimi (vxa132630)
Joshua Chang (jxc130930)
Joshua Garcia (rtg130030)
Chidambara Vinayagam (cpv130130)
ITSS 4330.001
Professor Narasimhan
University of Texas at Dallas

Table of Contents
Executive Summary...... 1
System Proposal and Problem Statement
Background & Justification 2
Objectives... 2
Scope... 3
Expected Value... 3
Constraints.. 3
Requirements
Functional... 4
Non-functional 4
Structural Model
Class Diagram. 5
Behavioral Models
Use Case Diagram... 6
Use Case Descriptions 7
Dynamic Models
Sequence Diagrams. 8
Design Documents
User Interface Design. 9
Software Design.... 12
Testing
Strategy. 15
Test Cases. 15
Project Management Documents
Meeting Minutes... 17
Lessons Learned.. 19
!
!
!
!
!

Executive Summary
In order to help increase profits, Boba Gett was designed by the IT professionals from
Systems, Inc. Boba Gett is a user-generated operating system that will revolutionize the way
Beautea, LLC handles customer orders, allowing for cost minimization, efficiency, and higher
quality products. The system itself is a kiosk that user will be able to step up to and custom-order
their drinks any way they want it and pay for the order. The order will be sent into the kitchen,
where it will be prepared and then distributed. This system will allow for fewer mistakes and
faster distribution of customer orders.
The following system proposal outlines the justification, objectives, project scope, and
value added benefits of Boba Gett for your company. The project schedule will further outline
the activities that will be performed by the Systems, Inc. team, through use of a work-breakdown
structure agenda. These additional two documents will allow for more in-depth information
about how Boba Gett can be seamlessly integrated into your business processes.
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!

System Proposal
Project Name: Boba Gett
Company Name: Beautea
Design Company: Systems, Inc.
IT Team: Varqa Azimi, Joshua Chang, Joshua Garcia, Chidambara Vinayagam
Background & Justification
Currently, there are errors in drink orders with hand written labels for making drinks.
This is causing inefficiency through the whole ordering process. With employees handling cash
registers and making drinks simultaneously, efficiency is sacrificed. Also, these inefficiencies
lead to a slower order processing and backing up of lines in Boba Gett. The lack of a systems
also means less to no options to display customizability for consumers. Besides the interaction
between the consumer and the front end of the restaurant. Management can benefit from having
stronger monitoring tools that will help make the decision making process easier.
Objectives
The goal of the project is primarily to improve customer service through quicker order
processing times. Through this goal, other objectives will be achieved as well. With faster and
more accurate service with a kiosk, the system will help reduce costs by reducing the amount of
errors in processing orders. Also, with better preparedness, better quality of drinks can be
created. Customers can then customize drinks for higher satisfaction. The self-ordering system
will also alleviate rush hour periods to help improve customer satisfaction. Outside of the
customer interaction objective, the system will also improve inventory management through realtime monitoring of products selected and update the inventory accordingly. The growth in profit
from the system will lead to higher quality and better efficiency for the store.

Scope
The new system will address the above problems by providing an order-processing
system that is equipped to handle customer interactions. It will support inventory tracking,
payment transactions, and order customization in order help business operations be more
efficient and effective in transmitting information. The user-interface will be simple and elegant
while providing customers the information necessary to create an order that is uniquely their
own.
Expected Value
The system expects to increase Boba Gett revenue by approximately $15k quarterly. It
will also allow for better customer experience and satisfaction through less wait and more
customization and accuracy. The system will also advertise itself, once implemented, as a
revolutionary process system within the bubble tea industry. Last of all, this system will make
expanding the company a simpler process.
Constraints
The estimate cost of creating the system will be around $10k. Also, there will be a time
frame for implementation and coding system requirements of around 6 months. Additional
development portions may require extra research. The system will also need continued
maintenance after the project is implemented, though the maintenance is not significant. Last of
all, there will be a time period for which customers learn to use the product. It is estimated to be
around 3 to 5 months. During this time period, the system will not be performing at its best level
since customers will still be learning to use the kiosk. After the 3 to 5 month period, the system
will then be fully integrated into the ordering process.

Requirements
The following are the functional and non-functional requirements for the Boba Gett system,
designed by Systems, Inc. for Beautea, LLC.
Functional:
1.! Display Menu: system should be able to display the menu, so that the customers and
baristas are able to view the menu options, and the store manager is able to view and
update menu options
2.! Accept Payment: system should be able to accept the payment method of the customer,
who have the choices of cash and card payment
3.! Interactive Menu: system should be a touch screen menu that is responsive to customer
interaction, as well as actions taken by the barista and store manager
4.! Store Records: system will store the records of customers, payments, inventory, and
menu options
5.! Retrieve Records: system will have a back-end interface for the store manager to access
stored records for use in profit analysis and inventory management
6.! Retrieve Information: customer will be able to access their store profile stored on the
system, while the barista will be able to access recipes for the menu items as well as their
stored information
7.! Register Information: customer, barista, and store manager will be able to register
pertinent information that can be accessed for future retrieval, especially with repeat
customers
8.! Change Information: customer will have access to change personal information, while
store manager will be able to change any information related to menu updates, inventory
management, and barista/staff information
Nonfunctional:
1.! Response Time: system will be periodically updated with the menu offerings and
inventory availability
2.! Effectiveness and Efficiency: system will have a process for redoing wrong orders
before they are sent to the barista, resulting in a quicker preparation time and less
mistakes in the preparation of order
3.! Usability: very simple elegant user interface and admin interface for easier accessibility
for documentation of all information regarding menu, inventory, and information
4.! Reliability: system should be able to handle multiple orders at one time and process them
sequentially without malfunctioning
5.! Security: all payment information kept confidential within the system, erased after
approval if bank involvement necessary
6.! Maintainability: system maintenance will occur every year for updates or whenever
necessary for trouble shooting
7.! Fault Tolerance: system will not be functional as a result of malfunction, as a result,
backup procedure may be necessary to implement
8.! Accessibility: system will be easily accessible by customers, baristas, and store managers
for each of the respective persons functions

Class Diagram
The following is a class diagram depicting the Boba Gett system.

Use Case Diagram

The following is a use case diagram depicting the use cases for the Boba Gett system.

Use Case Descriptions

The following are descriptions of 3 use cases found in the use case diagram for Boba Gett.
Use Case Name:
Primary Actor:
Brief Description:
Stakeholders:
Trigger:
Normal flow of events:

Subflows:
Alternate/Exception flow:
Use Case Name:
Primary Actor:
Brief Description:
Stakeholders:
Trigger:
Normal flow of events:
Subflows:
Alternate/Exception flow:
Use Case Name:
Primary Actor:
Brief Description:
Stakeholders:
Trigger:
Normal flow of events:
Subflows:
Alternate/Exception flow:

Order Drink from Automated Kiosk

Customer
Customer will walk into Store to view menu/order off of the
Automated Kiosk in Boba Gett
Beautea, LLC owners
Customer walks into store
Customer will enter store to pick menu item from automated kiosk.
The Customer will be given an ID to pay and pick up order from
Barista. Customer will be given options to customize drink. Once
customer has drink they will submit and it will be sent to Barista.
Customer will then pay for drink either by cash or Card.
Choose selections for drink
If Customer pays with Card, the Bank will be notified and then either
approve the transaction or not.
Bank Checking
Bank
To verify card transactions from Boba Gett
Beautea, LLC owners
Swiping of card with system
If Customer pays with Card, Bank will be notified and will need to
verify payment. If payment is approved they will send confirmation.
They will send a billing statement to the customer.
Verify customer information and identity
If Card does not work they will notify a failure to kiosk and
customer.
Preparation of Drinks
Barista
Will Receive order and prepare drink. Once completed they will give
drink to matching customer ID holder.
Beautea, LLC owners
Receipt of order received in kitchen
Once order is received and paid for Barista will begin creating the
drink. After Barista has completed the drink they will give it to the
customer.
Acquisition of Ingredients
If transaction is not accepted if customer pays with card, they will
not receive drink

Sequence Diagrams
The following are sequence diagrams for the use case scenarios within the Boba Gett system.

User Interface Design

The following represent the prototype of the windows used in the Boba Gett application by the customers of
Beautea, LLC.
Screen 1: Sign-in Screen for returning customers
that allows access to past drink orders, favorite
drinks, and rewards; this screen can also be
accessed after payment

!
!
!
!
!
!
!
!
!
!
!

Screen 2: Sign-up Screen for new customers to start

earning loyalty rewards and save their orders for
easier retrieval on next visit; this screen can also be
accessed after payment

Screen 3: Drink menu for customers to start their

drink order
!
!
!
!

Screen 4: Options menu for customer to add extra

ingredients and customize sugar and ice level of
drink
!

!
!
!

!
!
!
!
!
!
!
!
!
!
!
!

10

Screen 5: Payment Screen for customers to pay for

their drink order; screen shows the order
information and the total amount, along with
options to choose the payment method, going to
their customer account, or editing their drink option.
!
!

!
!
!
!
!
!
!
!
!
!
!
!
!
!

!
!
!
!
!

11

Software Design
The following represents three methods from our system and information concerning implementation and
operation responsibilities.
!
1.! !
Method Name: Order Drink Class Name: Customer
Description of responsibilities:
Implement the necessary behavior to create a drink order for the customer. The
information must be sent to the barista in a timely and accurate manner.
Arguments Received:
anOrder
Return Value:
sendDrinkInfo()

Data Type:
Order Object
Data Type:
String

Message and Example:

orderDrink(name, type, customization, ice) : String
sendDrinkInfo(): Boolean
Algorithm Specification:
If order is not null
sendDrinkInfo(): to barista and return true for complete
insertDrinkOrder into the database
updateInventory accordingly
request payment type from customer
Else
Return false and request more information from customer

!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
12

2.! !
Method Name: Menu
Class Name: Store Manager
Update
Description of responsibilities:
Implement the necessary behavior to allow the store manager to update and change the
menu according to the inventory and customer suggestions.
Arguments Received:

Data Type:

aDrink
deleteDrink
updateDrink

drinkObject
Boolean
String

Return Value:

Data Type:

updateMenu()

String

Message and Example:

aDrink(drinkID, name, type): String
deleteDrink(drinkID): Boolean
updateDrink(drinkID, name, type): String
Algorithm Specification:
If drink does not exist
aDrink object is created and added into the database menu
Else
Display the specified drink object
If store manager selects deleteDrink();
aDrink specified is removed from the system
Menu is updated accordingly
Else
Display the specified drink object
If store manager selects updateDrink();
aDrink specifications can be modified
Update menu accordingly
Else
Display the specified drink object

!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
13

3.! !
Method Name: Update
Class Name: Store Manager
Inventory
Description of responsibilities:
Implement the necessary processes to allow the store manager to update the inventory
based on new shipments of products or changes in supplies.
Arguments Received:
newInventory
updateInventory\
searchInventory
Return Value:
inventoryUpdate
displayInventory

Data Type:
Inventory Object
integer
String
Data Type:
Boolean
Array

Message and Example:

newInventory (productID, name, quantity, vendor): String/Int
updateInventory(productID, name, quantity, ventor): String
displayInventory(name, quantity, vendor): Array list
Algorithm Specification:
If store manager selects newInventory()
Add a new inventory item within the database
Update the database accordingly
Display new inventory information to store manager
Else
Return false = no action to be completed
If store manager selects updateInventory()
Display current inventory status and product information
Allow store manager to search inventory based on ID or name or product
Display product information
Update/Change product information
Display updated inventory information
Else
Return false = no action to be completed

!
!
!
!
!
!
!
!
!
!
!

14

Testing
The project being implemented is Boba Gett, an automated bubble tea search, select and payment kiosk. The
kiosk will make it easier for customers to order, specialize and pay for drinks. In addition, it will help lower
administration cost, by reducing the amount of errors and employees, for Beautea, LLC. The kiosk will have a
variety of functions therefore different types of testing will be required.
The first functions are the login function and payment function. Both will require confidential information,
therefore security testing will be mandatory. The second functions are the search and view functions. Within
this function, performance and functional testing will be required. Since the user has the most flexibility within
these functions, it is necessary to make sure it is up to the users standards. Though microscopically, there are
specific types of testing that will be focused on within each functions, macroscopically, every function within
the kiosk will preferably want to utilize all test case from reliability, security, performance and functionally.
This concept, along with a proper implementation of the Agile process, will ensure the project is both effective
and efficient.
The following are test cases for the three methods that were chosen to represent the Boba Gett system.
1.!
Test Case Title: Order Drink
Description: To order drinks from the kiosk to send to Barista
Purpose: Implement the necessary behavior to create a drink order for the customer. The information must be sent to the
barista in a timely and accurate manner.
Prereq: Assumption that a customer reward ID is not given. This will prompt to sign up for rewards program.
Test Data: customerID = {Valid customerID, invalid customerID, valid email, invalid email, empty}
password = {valid, invalid, empty}
sendDrinkInfo = {valid Drink, Invalid Drink, Incomplete Drink}
updateInventory = {Valid Inventory, Invalid Inventory}
updatePayment = {Valid Payment, Invalid Payment}
Steps: Steps to carry out the test:
1.! visit LoginPage
2.! enter customerID (enter valid customer id, enter invalid customer id, enter blank customer id)
3.! enter password (enter valid password, enter invalid password, enter blank password)
4.! click login
5.! see the terms of use page
6.! click agree radio button at page bottom
7.! click submit button
8.! see MenuPage
9.! verify that welcome message is correct username
10.! Send Drink Info (enter Valid Drink, enter Invalid Drink or enter empty drink)
11.! Update Inventory (
12.! Send Payment Info (Enter Valid Payment, enter Invalid Payment)

15

2.!
Test Case Title: Menu Update
Description: Store Manager updates menu for Customers
Purpose: Implement the necessary behavior to allow the store manager to update and change the menu according to the
inventory and customer suggestions.
Prereq: The customer has an ID and is able to order a drink from the Menu at Kiosk.
Test Data: aDrink = {Valid DrinkID, invalid drinkId}
deleteDrink = {valid, invalid, empty}
updateDrink = {drinkID, Valid Name, Invalid name, Valid type, Invalid Type}
Steps: Steps to carry out the test:
1.!
2.!
3.!
4.!

Visit Menu
enter aDrink (enter valid drink id, enter invalid drink id, enter blank drinkID)
Delete Drink from Menu (Valid Drink, Invalid Drink)
Update Drink (Update DrinkID, Update Name, Update, Drink type)

3.!
Test Case Title: Update Inventory
Description: To show Store Manager Inventory for Reordering
Purpose: Implement the necessary processes to allow the store manager to update the inventory based on new shipments of
products or changes in supplies.
Prereq: That a drink has been ordered from the menu. This will change Inventory and whether a drink needs to be
updated.
Test Data: newInventory = {Enter Valid productID, Enter Name, Enter Quantity, Enter Vendor}
updateInventory = {Update Product ID, Update Name, Update Quantity, Update Vendor}
displayInventory = {Enter Name, Enter Quantity, Enter Vendor}
Steps: Steps to carry out the test:
1.!
2.!
3.!
4.!
5.!

Store Manager will select new Inventory(enter newInventory)

Update Database (Valid updateInventory, Invalid updateInventory)
Select Inventory to update(Valid displayInventory, Invalid displayInventory)
Search Inventory (updateInventory, changeInventory)
Display updated Inventory

!
!
!
!
!
!
!
!
!
!
!
!
!
!
16

Meeting Minutes
Group Milestone 1
January 21, 2016: 2:15pm to 3:00pm
-! All members present
-! Discussed possible ideas for project
-! Chose idea for project: bubble tea ordering system
-! Made outline for memo notice with information discussed
-! Action Items: Chidambara will compile outline information into memorandum format
and submit document
All other communication was conducted via email and instant group messaging throughout the
week of January 20 January 27.
Group Milestone 2
February 29, 2016: 11:15am to 11:30am
!! All members present
!! Discussed possible meeting times for discussion of project
!! Action Items: schedule meeting time for following week
March 7, 2016: 11:15am to 1:00pm
!! All members present
!! Discussed requirements necessary for each component of project (executive summary,
systems proposal, and project schedule WBS)
!! Action Items: Chidambara will write executive summary, Josh C. will write systems
proposal, Josh G. will write a list of tasks for project scheduled to be put into a WBS by
Varqa
March 21, 2016: 11:15am to 11:30pm
!! All members present
!! Discussed compilation of components for project milestone
!! Action Items: Chidambara will compile all parts of the deliverable
All other communication was conducted via email and instant group messaging throughout the
week of March 8 March 20.
"

17

Group Milestone 3
March 21, 2016: 11:15am to 12:00pm
!! All members present
!! Discussed distribution of work between members
!! Discussed requirements needed for completion of assignment parts
!! Action Items: schedule meeting time for following week, assignment parts Chidambara
will do requirements, Josh C. will do sequence and class diagrams, Josh G. will create
use case diagram, Varqa will write use case descriptions
March 28, 2016: 11:15am to 11:30am
!! All members present
!! Discussed any updates needed to be made to assignment parts after further discussion and
analysis
!! Action Items: update all parts by March 29
March 29, 2016: 9:45am to 10:00am
!! All members present
!! Discussed compilation of components for project milestone
!! Action Items: Chidambara will compile all parts of the deliverable
All other communication was conducted via email and instant group messaging throughout the
weeks of March 21 March 29.
Group Milestone 4
March 30, 2016: 11:15am to 11:30am
!! All members present
!! Discussed distribution of work between members
!! Discussed requirements needed for completion of assignment parts
!! Action Items: schedule meeting time for following week, assignment parts Chidambara
will do user interface, Josh C. will do software design, Josh G. will create test cases,
Varqa will write test case descriptions
April 4, 2016: 9:00am to 10:00am, 11:00am to 11:15am
!! All members present
!! Discussed any updates needed to be made to assignment parts after further discussion and
analysis
!! Action Items: update all parts by April 5, 2016, send to Chidambara for compilation
April 7, 2016: 9:00am to 10:00am
!! All members present
!! Discussed the components that needed to be fixed
!! Action Items: everyone fixes necessary parts, Chidambara will compile all final parts for
deliverable and submit document
All other communication was conducted via email and instant group messaging throughout the
weeks of March 30 April 7.

18

Lessons Learned
Varqa Azimi
1.! Learned that the best way to start the project was to start early.
2.! The team were all stakeholders and wanted to make sure that we received a good grade so
we all made sure we made a quality product.
3.! We all collaborated and consulted which helped the vision of the group.
4.! Having a a team leader to put everything together helped with the fluidity of the project.
5.! Making sure each of our parts were verified for quality by each other helped with getting
them done on a timely and quality manner.
Joshua Chang
1.! Learned about the 5 project management groups and that the executing process takes
the longest amount of time while the planning process takes the second longest.
2.! Learned about the different components of dynamic modeling: behavioral, structural,
and temporal.
3.! Learned about the different design strategies and when to implement the strategies
depending on the need of the project within the company.
4.! Learned about the importance of quality management since cost tend to increase as
project reach completion. This includes different tools to help assess the process that
lead to issues that can further be fixed.
Joshua Garcia
1.! Learned about the different deliverables correlated to each phase of the systems
development life cycle.
2.! Learned about the process and order required in each phase such as how one project task
leads to another.
3.! Learned, saw and experienced the importance of the triple constraint within our project,
specifically with time and scope. This was replicated through the due dates and the
mandatory requirements of the project.
4.! Learned about how essential teamwork and communication are especially with each
project member's busy schedule.
Chidambara Vinayagam
1.! Always set a final deadline before the final deadline to account for any unforeseen
circumstances.
2.! Make sure all communication is written down somewhere; do not just rely on verbal
communication because group members may forget specifics discussed.
3.! Utilize group messaging apps, such as GroupMe, for simpler communication.
4.! Formatting documents may take more time than what you initially plan for, so allocate
time accordingly.
5.! Always keep back-ups of your work for when your computer decides to stop working
properly.
6.! Implementation of class concepts into project allows for the theory to be understandable
in practice.

19