1.
CSC 4350
Spring 2015
MegaMart Management
Nick Birger
Sam Brice
Hamza Jamil
Jinsoo Kim
Chung Peng

2. 1
Table of Contents:
Introduction (topic description)
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
p. 2
Requirements Elicitation ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 2
Requirement Traceability Matrix
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
p. 9
Use cases ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 16
Sequence Diagrams ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 49
Category Interaction Diagram ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 66
Object Design ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 67
Test cases ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 68
Rationale
Topic Choice ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 70
Use Cases ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 71
Object Design ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 73
Test Cases ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 75
Cost Analysis
Function Point Cost Analysis ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 76
COCOMO ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 77
Comparison and Conclusions ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 78
Prototype ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 79
Project Legacy ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 82
Work Schedule Diagram ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 83
Gantt Chart ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 84
Dictionary ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 85
Group Member Resumes
Sam Brice ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 86
Jinsoo Kim ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 87
Hamza Jamil ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 88
Nick Birger ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 89
Chung Peng ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 90
User Guide ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 91
Source Code ​­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ p. 97

3. 2
MegaMart Management System
1.0) ​Introduction:
MegaMart Management System(MMMS) is an application that will be used to
manage a mega mart retail store. The store’s size will be similar to
Wal-Mart’s in that it will have several departments, each with distinct
employees, inventories and services to be monitored. Information will be
stored on local, location-specific servers. Store’s inventory will be accessible
by MMMS of other Mega Mart stores.
2.0) ​Departments:
The departments are: Grocery, Electronics, Sporting/Recreation, Clothing,
Home/Office, and Management.
2.1) ​General:
There shall be 5 general departments. Each shall have one Manager
and some General Employees.
2.2) ​Management:
There shall be 3 sub-departments.
2.2.1) ​Accounting:
This department shall manage payroll. It shall aggregate data from the
transaction database to form reports for executives responsible for
financial decisions. The pay rate shall be stored for all types of
employees in a separate table.

4. 3
2.2.2) ​Human Resources (People Management):
Employees shall be assigned positions based on Human Resources
management department. The department shall contain max of 4
HR employees. Each store shall have a store manager, a Store supervisor, and
a number of general employees (cashiers, baggers, greeters).The Human
Resource department shall deal with management of employees including
hiring, firing, and scheduling.
2.2.3) ​Customer Service:
The Customer Service department shall process returns. It shall open
customer service cases. Customer service cases shall be dealt with externally
by customer service employees.
3.0) ​Data:
All data accessed by the software shall be stored in a local, relational, store-specific
database.
3.1) ​Employee:
Shall be a table of EMPLOYEES which contains first and middle initial, last
name, age, social security number, address, banking information (billing address,
account number, routing number), generated user-id, user-created password, and
email. Clock-in, clock-out and total time worked shall be stored with the employee
entry in the database as well. Employees will be able to send send messages to
other employees.
­ Employee-ID shall be unique 8 digit decimal number that serves as a
franchise wide identifier for the employee.
­ Username shall be a store-unique identifier, and shall be automatically
generated upon addition of employee to database. It shall be composed of
first initial, last name, and the first available integer incrementing from
one (all one word, all lower-case).
­ The total time worked field will be a running total of the total time
worked which is calculated based on their clock-in and clock-out values
on a daily basis.
3.2) ​Inventory:

5. 4
Shall store each item’s UPC, name, department, quantity on hand, target
quantity, wholesale price per unit and sale price per unit.
Each inventory data request. A barcode can be scanned by a Barcode Scanner, the
item’s UPC shall be sent to the system as an alpha-numeric string. The ordering of
inventory supply shall not be done though this software, but rather an external
system.
3.3) ​Transaction:
Shall be composed of a unique transaction-id which shall be an 12 digit
positive integer made up of 4 digits for year, 2 digits month, 2 digits for day,
and a 4 digit number to be incremented with each transaction added to the database
(to be reset daily), products’ UPC, quantity(purchase or return). All transactions
shall be immediately stored in a queue which shall be processed every five minutes,
updating the inventory based on the transaction’s type(purchase or return). Each
transaction shall be stored in its respective table (purchase or return). Type shall be
0 for purchase and 1 for return and stored in a queue which is processed every 5
minutes , derived total
4.0) ​User Interface (UI):
The user interface will be intuitive and easy to navigate, as well as efficiently laid out
to accomplish tasks quickly.
4.1) ​General Layout Description:
The software’s interface shall be organized based on department. There shall
be a department selection drop-down menu, in which a user will select the
department they wish to access. Each department’s interface shall allow the user to
intuitively access all necessary functions applicable to that department.
4.1.1) ​General Department Interface:
General departments shall share a similar interface. This interface
shall allow the user to access and view all of the inventory associated
with that department. This view of inventory will be intuitively laid out to
show what is in stock, the price of the item, and when any out of stock item is
expected to be available. The list of inventory items can be sorted by name,
UPC, quantity in stock. The user will be able to search for a specific item by
name or UPC. General department interfaces shall also allow users to view
the staff of that department and send messages/notifications to the
management within that department.

6. 5
4.1.2) ​Management:
The interface for the management department shall be broken down
into 3 sub-pages/interfaces each representing one of the sub-departments
described in section 2.2.
Accounting:
This page shall allow the user to generate reports based
on transactions. Accounting employees shall be able to view the hours
worked by each employee, and calculate the amount to pay them. All
the payroll information shall be pushed out to a file where the
information, including banking information and amounts for each
employee, is parsed by an external system to print checks or be sent
electronically. Employee total hours worked shall be reset after each
paycheck is sent out. Payroll shall be processed and sent out every 2
weeks.
Human Resources:
This page shall allow the user to manage all
employee positions. There shall be the option to view all
employees in a list and sort them by various attributes. The user shall
be able to add or remove an employee from the database through the
Human Resources interface as well. When adding an employee a
popup window will appear with all the relevant fields. This page will
have the option to display the employee work schedule, which will be
generated externally by a Human Resources employee. This schedule
will be visible to all employees regardless of position within the store.
A Human Resources employee shall be able to manually reset and
modify the clock-in, clock-out and total hours worked fields in an
employee record.
Customer Service:
This page shall allow the user to search for
search past transactions over the past 30 days, to create a new
customer service case, to access old/open customer service cases. To
process returns the user shall select a past transaction to reverse and
a new transaction will be created.
4.2) ​Privileges / Restrictions:
Upon accessing the software the user shall be required to enter their login
information, i.e. their username and password. After entering valid login
information the user shall be signed in and have access to pages that they

7. 6
have the privilege to view or interact with. The privileges are as follows:
Store Manager:
The store manager shall have access to all functionality offered by the
software, they can assign employees to all positions within the store.
Store Supervisor:
The store supervisor shall have access to all functionality offered by the
software, they can assign employees to all positions below their own.
Management:
​Managers shall have access to all functionality within their assigned
department, and have limited access to functionality within the management
department. They have no administrative privledges.
General Employee:
General employees shall only have basic access to the software. They shall be
able to view inventory, send messages/notifications to managers, and modify
basic information about themselves. If an employee is assigned to a more
specific job, such as customer service, they shall have access to the
functionality associated with that job. All general employees shall access
their employee page and clock-in when they begin work, and clock out when
they leave.
A user shall have the option to sign out when they have completed their use
of the software, if they let the system sit idle for 10 minutes they shall
automatically be signed out.
4.3) ​Notifications / Messages:
Every 30 minutes the inventory shall be checked for low levels of stock. If an
item’s stock level in inventory is below 30% of the desired stock level (target
stock level), a warning message shall be sent to the managers. The listing
for a low stock item will appear red in the inventory list. Users will be able to
manually flag an item if it has less than 30% stock.
Employees shall be able to send messages to managers within their own
department, managers shall be able to view these messages. When an employee
sends a message it shall also send their name, employee ID, and the date sent, to the
manager message inbox.
There shall be a popup notification when a user has been inactive for 9 minutes, if
the user does not interact with this popup by clicking its button the system shall

8. 7
assume the user is still in active and proceed to log the user out at the 10 minute
mark.
4.4) ​Errors / Exception Handling:
If the user should enter invalid information in the login entry fields, the
program shall return “ You have entered an invalid username/password.”
When a user clocks-in it the system shall store the time in the clock-in field of
their employee record, and when they clock-out the time is stored in the clock-out
field. The time worked is calculated and added to total time worked. The values for
clock-in and clock-out are cleared after a full cycle of clock-in and clock-out occur. If
the user does not clock-out at the end of the day, and tries to clock-in on the next
day, an error will be displayed, and they will be prompted to contact a
manager/Human Resource employee.
If the user enter invalid data entry, such as: invalid SSN, address, and banking
information, the program shall return, “Invalid (SSN, Address, and
Banking information)”.
The program shall display a message, “No data found”, if there are no datas
in the table requested.
5.0) ​Backup​:
Every day at 11:59pm the new transactions for that day shall be appended to
a log file, which acts as a backup of transactions. At the same time transactions older
than 30 days will be removed from the database.
Every 7 days, the other data in the database will be backed up to log files, this
includes employees, messages, inventory, etc...
All views of the database content will have the option to export the visible data to a
log file. The software will allow the importing of log files to be parsed and replace or
append to the current data in the database.
6.0) ​Administration:
The store manager shall have the ability to access all of the program. The
store managers login shall have root access to the software, thus have the
privileges to access the administrative functions of the software. A System
Administrator has this access as well. The administrative functions shall include:

9. 8
Manual backup of databases:
Databases can be manually backed up, by duplicating the .sqlite file
and renaming for backup.
Manual restoration of databases:
The database backup file can be restored to act as the current
database.
Modify the network paths to database servers:
Shall Have the ability to modify the paths to access the local
database and any relevant files.

10. 9
Requirement Traceability Matrix:
Entry#
Para
# System Specification Text Type Build Use Case Name Category
1 2.1 There shall be 5 general
departments
SWC
2 2.1 Each department shall have 1
manager and some general
employees
SWC
3 2.2 Management shall have 3
sub­departments
SWC
4 2.2.1 Accounting shall manage payroll SW
5 2.2.1 Accounting shall aggregate data
from the transaction database to
form reports
SW 1.0 UC05_Create_Finacial_Report
Interface
Controller
6 2.2.1 The pay rate shall be stored for all
types of employees in a separate
table.
SW
7 2.2.2 Employees shall be assigned
positions based on Human
Resources
management department
SW 1.0 UC07_Assign_Employee_Position
Interface
Controller
8 2.2.2 The HR department shall contain
max of 4 HR employees
SWC
9 2.2.2 Each store shall have a store
manager, a Store supervisor, and a
number of general employees
(cashiers, baggers, greeters)
SWC 1.0 UC09_Add_Employee,
UC10_Remove_Employee
Interface
Controller
10 2.2.2 The Human Resource department
shall deal with management of
employees including hiring, firing,
and scheduling.
SW
UC09, UC10
11 2.2.3 Customer Service shall open
customer service cases.
SW 1.0 UC11_Create_Customer_Service_Case
UC12_Load_Customer_Service_Case
Interface
Controller
Database
12 2.2.3 The Customer Service department
shall process returns.
SW
UC27
13 2.2.3 Customer service cases shall be
dealt with externally by customer
service employees.
1.0
UC13_Remove_Customer_Service_Case
Interface
Controller
14 3.0 All data shall be stored in a local
and store­specific database
SWC,
HW
15 3.1 Employee table shall contain first
name, middle initial, last name,
age, SSN, address, banking
information, generated user­id,
user­created password, and e­mail.
SWC

11. 10
16 3.1 Clock­in, clock­out and total time
worked shall be stored with the
employee entry in the database
SW,S
WC
17 3.1 Employees will be able to send
schedule requests to management
SW
18 3.1 The total number of personal days
and personal days already taken
shall be stored in separate fields in
an employee record.
SW
19 3.1 Employee­ID shall be unique 8 digit
decimal number that serves as a
franchise wide identifier for the
employee.
SW
20 3.1 Username shall be generated with
first initial, last name, and the first
available integer.
SW
21 3.1 The total time will be calculated
based on Clock­in and Clock­out
values on daily basis
SW 1.0 UC21_Clock_In,
UC22_Clock_Out Interface
Controller
22 3.2 A barcode can be scanned by a
Barcode Scanner, the item’s UPC
shall be sent to the system as an
alpha­numeric string.
SW,
HW
23 3.2 Inventory table shall store item's
UPC, name, department, quantity
on hand, target quantity, wholesale
price per unit, and sale price per
unit.
SW 1.0 UC23_Add_Inventory_Item,
UC24_Remove_Inventory_Item,
UC25_Modify_Inventory_Item
Interface
Controller
24 3.2 The ordering of inventory supply
shall not be done though this
software
SWC
25 3.3 Transaction table shall store unique
transaction ID, product's UPC,
product's price and product's
quanitity.
SW
UC27
26 3.3 Transaction ID shall be unique 12
digit ID, which is composed of year,
months, days, and 4 digit number
that increments with each
transaction.
SWC
27 3.3 All transaction shall be immediately
stored in queue to update inventory
depending on purchase or return.
SW 1.0 UC27_Create_Transaction
Interface
Controller
28 3.3 The transaction queue shall be
processed every 5 minutes.
SW,
SWC
1.0 UC28_Process_Transaction_Queue Object
Classes
29 3.3 The purchase and return shall be
differentiated by number type. (0
being purchase and 1 being return)
SW,
SWC
UC27
30 4.0 The user interface will be intuituve
and easy to navigate, as well as
SWC

12. 11
efficiently laid out to accomplish
tasks quickly.
31 4.1 The software's interface shall be
organized based on department.
SW
32 4.1 There shall be a deparment
selection drop­down menu, in which
a user will select the department
they wish to access.
SW 1.0 UC32_Select_Department
Page
Navigator
33 4.1 Each department's interface shall
allow the user to intuitvely access
all necessary functions applicable
to that department
SW
UC32
34 4.1.1 General departments shall share a
similar interface.
SW
35 4.1.1 This interface shall allow the user to
access and view all of the inventory
associated with that department.
SW 1.0 UC35_Load_Department_Inventory
Database
36 4.1.1 This view of inventory will be
intuitively laid out to show what is in
stock, the price of the item, and
when any out of stock item is
expected to be available.
SW
37 4.1.1 The user will be able to search for a
specific item by name or UPC.
SW 1.0 UC37_Search_Inventory Interface
Controller
38 4.1.1 General department interfaces shall
also allow users to view the staff of
that department and send
messages/ notifications to the
management within that
department.
SW 1.0 UC38_Load_Employees,
UC39_Search_Employees
Interface
Controller
Database
39 4.1.2 The interface for the management
department shall be broken down
into 3 sub­pages/interfaces each
representing one of the
sub­departments described in
section 2.2
SW
40 4.1.2 The accounting page shall allow the
user to generate reports based
on transactions.
SW
UC05
41 4.1.2 Accounting employees shall be
able to view the hours worked by
each employee, and calculate the
amount to pay them.
SW 1.0 UC41_Process_Paychecks
Interface
Controller
42 4.1.2 All the payroll information shall be
pushed out to a file where the
information, including banking
information and amounts for each
employee, is parsed by an external
system to print checks or be sent
electronically.
SW
UC41

13. 12
43 4.1.2 Employee total hours worked shall
be reset after each paycheck is
sent out.
SW
UC41
44 4.1.2 Payroll shall be processed and sent
out every 2 weeks.
SW,
SWC
45 4.1.2 The human resources page shall
allow the user to manage all
employee positions.
SW
UC07
46 4.1.2 There shall be the option to view all
employees in a list and sort them
by various attributes.
SW
UC38
47 4.1.2 When adding an employee a popup
window will appear with all the
relevant fields.
SW
UC09
48 4.1.2 This page will have the option to
display the employee work
schedule, which will be generated
externally by a Human Resources
employee.
SW
49 4.1.2 This schedule will be visible to all
employees regardless of position
within the store.
SW
50 4.1.2 A Human Resources employee
shall be able to manually reset and
modify the clock­in, clock­out and
total hours worked fields in an
employee record.
SW 1.0 UC50_Modify_Employee_Data
Interface
Controller
51 4.1.2 The customer service page shall
allow the user to search for
search past transactions over the
past 30 days, to create a new
customer service case, to access
old/open customer service cases.
SW 1.0 UC51_Load_Transactions,
UC52_Search_Transactions
Interface
Controller
Database
52 4.1.2 To process returns the user shall
select a past transaction to reverse
and a new transaction will be
created.
SW
UC27
53 4.2 Upon accessing the software the
user shall be required to enter their
login information, i.e. their
username and password.
SW 1.0 UC53_Log_In
Interface
Controller
54 4.2 After entering valid login
information the user shall be signed
in and have access to pages that
they have the privilege to view or
interact with.
SW
UC53
55 4.2 The store manager shall have
access to all functionality
offered by the software, they can
assign employees to all positions
within the store.
SW

14. 13
56 4.2 The store supervisor shall have
access to all functionality
offered by the software, they can
assign employees to all positions
below their own.
SW
57 4.2 Managers shall have access to all
functionality within their
assigned department, and have
limited access to functionality within
the management department.
SW
58 4.2 Management will be able to access
notifications sent by employees to
management.
SW
59 4.2 General employees shall be able to
view inventory, and send
messages/notifications to
managers.
SW
60 4.2 If an employee is assigned to a
more specific job, such as customer
service, they shall have access to
the functionality associated with
that job.
SW
61 4.2 All general employees shall access
their employee page and clock­in
when they begin work, and clock
out when they leave.
SW
UC21, UC22
62 4.2 A user shall have the option to sign
out when they have completed their
use of the software.
SW 1.0 UC62_Log_Out
Interface
Controller
63 4.2 If a user lets the system sit idle for
10 minutes, they shall automatically
be signed out.
SW,
SWC
UC62
64 4.3.1 Every 30 minutes the inventory
shall be checked for stock levels.
SW,
SWC
65 4.3.2 If stock level on an item is below
30% of the desired (target) stock
level, it shall produce a notification
and update the notifications panel.
SW,S
WC
66 4.3.3 Items with low stock level (below
30% of the target) will be colored in
red in inventory list
SW
67 4.3.4 User will be able to flag an item if
the item is under 30% threshold
SW
68 4.3.5 Employees shall be able to send
messages to managers within their
own department
SW 1.0 UC68_Create_Message
Interface
Controller
69 4.3.6 Manage shall be able to view the
message sent by employees in
their respective department.
SW 1.0 UC69_View_Message
Interface
Controller

15. 14
70 4.3.7 When an employee sends a
message it shall also send the
message with their information and
date
SW
UC68
71 4.3.8 User shall be warned if they're
inactive for 9 minutes. (Inactivity is
determined by clicks)
SW
72 4.3.9 The software will log itself out when
the user is inactive for 10 minutes.
SW
UC62
73 4.4 Every day at 11:59pm transactions
older than 30 days will be removed
from the database.
SW,S
WC
UC80
74 4.4.1 If the user should enter invalid
information in the login entry fields,
the
program shall return “ You have
entered an invalid
username/password.”
SW
UC53
75 4.4.2 When a user clocks­in it the system
shall store the time in the clock­in
field of their employee record, and
when they clock­out the time is
stored in the clock­out field.
SW
UC21, UC22
76 4.4.3 If the user does not clock­out at the
end of the day, and tries to clock­in
on the next day, an error will be
displayed, and they will be
prompted to contact a
manager/Human Resource
employee.
SW
UC21
77 4.4.4 If the user enter invalid data entry,
such as: invalid SSN, address, and
banking information, the program
shall return, “Invalid (SSN, Address,
and Banking information)”.
SW
UC09, UC11, UC23, UC25, UC27,
UC50, UC53, UC68, UC88
78 4.4.5 The program shall display a
message, “No data found”, if there
are no datas in the table requested.
SW
79 5.0 Every day at 11:59pm the new
transactions for that day shall be
appended to a log file
SW 1.0 UC79_Back_Transactions
Object
Classes
80 5.0 Every day at 11:59pm transactions
older than 30 days will be removed
from the database.
SW 1.0 UC80_Remove_Old_Transactions
Interface
Controller
81 5.0 Every 7 days, the other data in the
database will be backed up to log
files, this includes employees,
messages, inventory, etc...
SW
UC82
82 5.0 The software shall allow the
database .SQLite file to be
duplicated and backed­up
SW 1.0 UC82_Backup_Database_Table
Object
Classes

16. 15
83 5.0 The software will allow the restoring
of a backup database .SQLite file
SW 1.0 UC83_Restore_Database_Table Interface
Controller
84 6.0 The store manager shall have the
ability to access all of the program
SW
85 6.0 The store managers login shall
have root access to the software,
thus have the privileges to access
the administrative functions of the
software
SW
86 6.0 The administrative functions shall
include: Manual backup of
databases
SW
UC82
87 6.0 The administrative functions shall
include: Manual restoration of
databases
SW
UC83
88 6.0 The administrative functions shall
include: Modify the network/local
paths to database servers and log
files
SW 1.0 UC88_Modity_Data_Path
Interface
Controller
89 3.3 There shall be a cash register view
which allows the user to create a
transaction to be added to the
transaction queue.
SW
UC27

17. 16
Use Cases:
Use Case 5: Create Financial Report
Overview:
Pull data from database tables and calculates financial values and organizes them in a report
which is stored as a separate file.
Preconditions:
1. The database is accessible.
2. All database tables must be populated.
3. Accounting page is displayed.
4. User is logged into an account with appropriate authorization.
Scenario:
Action Software Reaction
1.User browses for a location to save
the report, via system directory
chooser.
1. System gets path and checks if it is valid.
2. User clicks Generate Report
button on the accounting page
2. Report is generated and saved.Appropriate
Label is set to visible to notify the user the
generation was successful.
Scenario Notes:
None
Postconditions:
The created report file is saved to the location defined by the user.
Exceptions:
1. DB cannot be accessed
2. DB is not populated
Required GUI:
1.Accounting View
Use Case Utilized:
1.UC35
2.UC51 ​Timing Constraints: ​None

18. 17
Use Case 7: Assign Employee Position
Overview:
Select the employee, select the position from a drop­down menu, click Assign Position button.
Preconditions:
1. The database is accessible.
2. The employee table within the database is accessible.
3. There is an employee record to assign the position.
4. The user must be an employee in the Human Resources department or a manager.
5. The user is viewing the employee positions page under Human Resources.
Scenario:
Action Software Reaction
1. The user selects an
employee from a list.
1. The name of the employee will be highlighted, and a
drop­down menu will appear.
2. The user selects a
position from a
drop­down menu and
clicks Assign Position.
2. Employee’s position is updated in the table and saved, the
employee’s name will no longer be highlighted.
Scenario Notes:​ None
Postconditions:
1. The cell in the employee table is changed to the designated value.
Exceptions:
1. The database is inaccessible and the system alerts the user and does not modify the
position.
2. The table is inaccessible and the system alerts the user and does not modify the position.
3. The employee record is inaccessible and the system alerts the user and does not modify
the position.
Required GUI:​ 1. Employee Positions page within the human resource tab
Use Case Utilized:​ 1. UC38 2. UC50
Timing Constraints: ​None

19. 18
Use Case 9: Add Employee
Overview:
This use case allows the user to add a new employee to the employee database.
Preconditions:
1. The database is accessible.
2. The user is viewing the employee page under Human Resources.
Scenario:
Action Software Reaction
1. User clicks on the Add
Employee button.
1. The Add_Employee_Edit_Page appears.
2. User enters employee
information. And clicks Ok
button
2. System checks the information to make sure it is acceptable format. If there is
an error the field is highlighted red. Else the Add_Employee_Edit_Page closes,
and a new employee record is added to the database.
3. User modifies incorrectly
formatted information, and
clicks Ok button.
3. If information is correctly formatted, Add_Emplpoyee_Edit_Page closes and a
new employee record is added to the database.
4. User clicks cancel button. 4. Add_Employee_Edit_Page closes, no changes are made to the employee
database
Scenario Notes:
­ Employee information consists of: First Name, Middle Initial, Last Name, Birthday, SSN, Address, Banking
Information (Name on Account, Account Number, Routing Number),Username, Password, Email and Position.
­ Username will be generated based on employee name.
­ Employee information can be entered in any order.
­ Actions 2 / 3 and 4 are exclusive.
Postconditions:
1. An employee record will be added to the database.
Exceptions:
1. Information entered in an incorrect format. System does not complete the use case until the user corrects the error.
2. Database is not accessable. System alerts user and does not add employee.
3. If the employee to be added is a repeat of a pre­existing employee, the system will alert the user and not add the
employee.
Required GUI:
1. Employee management page of Human Resources interface
2. Add_Employee_Edit_Page
Use Case Utilized:​ ​UC39​ ​Timing Constraints:​ ​None

20. 19
Use Case 10: Remove Employee
Overview:
Allows user to select and remove an employee after displaying Employee_Table.
Preconditions:
1.Database is accessible.
2.The employee table must be populated
3.Employee table must be displayed.
4.Employee must be selected.
Scenario:
Action Software Reaction
1.User clicks on desired
employee.
1.The employee is selected and is highlighted.
2.User clicks Remove_Button 2.The employee is removed from the table, then the table
updated to reflect removal.
Scenario Notes:
None
Postconditions:
1.The employee is removed from the employee table.
2.Employee table must be displayed.
Exceptions:
1.DB is not accessible.
2. No employee is selected
Required GUI:
1.Employee_Table
2.Rmoved_Employee_Pop_Up
Use Case Utilized:
1.UC38

21. 20
Timing Constraints: ​None
Use Case 11: Create Customer Service Case
Overview:
Creates a customer service case for employees to deal with.
Preconditions:
1. The database is accessible.
2. The Customer Service Cases page must be displayed.
Scenario:
Action Software Reaction
1. User clicks on the Add
Employee button.
1. The Create_Case_Interface appears.
2. User enters the case
information. And clicks Ok
button
2. System checks the information to make sure it is acceptable format. If there is
an error the field is highlighted red. Else the Create_Case_Interface closes, and a
new customer service case is added to the database.
3. User modifies incorrectly
formatted information, and
clicks Ok button.
3. If information is correctly formatted, Create_Case_Interface closes and a new
customer service case is added to the database.
4. User clicks cancel button. 4. Create_Case_Interface closes, no changes are made to the employee
database
Scenario Notes:
­ Information from customer service cases include: customer name, customer contact information, and a description
of the case.
Postconditions:
1. Customer service case is created.
Exceptions:
1.The database is not accessible and the system alerts the user.
2. The Customer_Service_Case_Table is not accessible and the system alerts the user about this information.
3. Information entered in an incorrect format. System does not complete the use case until the user corrects the error.
Required GUI:
1.Customer_Service_Page
2.Customer_Service_Case_Table
Use Case Utilized:
None​ ​Timing Constraints:​ ​None

22. 21
Use Case 12: Load Customer Service Case
Overview:
Pulls Customer_Service_Case_Table from the database and displays it.
Preconditions:
1.Database is accessible.
2.Customer_Service_Page must be displayed.
3. User has privilege to access the page.
Scenario:
Action Software Reaction
1.User clicks on
Display_Customer_Service_Case_Butt
on on Customer_Service_Page
1.Displays Customer_Service_Case_Table
Scenario Notes:
None
Postconditions:
1.Customer_Service_Case_Table is displayed
Exceptions:
1.DB is not accessible.
2.Customer_Service_Case_Table is not accessible
Required GUI:
1.Customer_Service_Page
2.Customer_Service_Case_Table
Use Case Utilized:
None
Timing Constraints:
None

23. 22
Use Case 13: ​Remove Customer Service Case
Overview:
Enables user to remove existing customer service case.
Preconditions:
1.Database is accessible.
2.Customer_Service_Case_Table must be displayed.
3.Customer_Service_Case_Table must be populated.
4.Customer service case must be selected.
Scenario:
Action Software Reaction
1.User clicks on one of
the existing cases.
1.The customer service case is selected and highlighted.
2.User clicks on
Remove_Customer_Ser
vice_Case.
2.The case is removed, then
Removed_Customer_Service_Case_Pop_Up is displayed.
3.User clicks OK 3.Removed_Customer_Service_Case_Pop_Up is closed.
Scenario Notes:
None
Postconditions:
1.The customer service case is removed.
Exceptions:
1.DB is not accessible.
2.No case is selected.
Required GUI:
1.Customer_Service_Case_Table
2.Removed_Customer_Service_Case_Pop_Up
Use Case Utilized:
1.UC12 ​Timing Constraints:​ None

24. 23
Use Case 21: Clock In
Overview:
This Use Case enables the user to clock in. The clock in time will be used (along with the
clock out time) to calculate the number of hours the user has worked.
Preconditions:
1. User is logged into the MMMS.
2. User is clocked out.
3.The database is accessible.
4. User profile is displayed.
Scenario:
Action Software Reaction
1. User clicks on the
Clock_In button on the
User Profile page.
1. The Clock_In_Confirmation text is displayed, the DB is
updated.
Scenario Notes:
Postconditions:
1. The Clock In value is updated in the DB.
2. The user is clocked in.
Exceptions:
1. The DB cannot be accessed.
Required GUI:
1. Clock_In_Clock_Out_View
Use Case Utilized:
None
Timing Constraints:
None

25. 24
Use Case 22: Clock Out
Overview:
This Use Case enables the user to clock out. The clock out time will be used (along with the
clock in time) to calculate the number of hours the user has worked.
Preconditions:
1. User is logged into the MMMS.
2. User is clocked in.
3.The database is accessible.
4. Clock_In_Clock_Out_View is displayed.
Scenario:
Action Software Reaction
1. User clicks on the
Clock_Out button on
the User Profile page.
1. The clock in text disappears, Clock_Out_Confirmation text is
displayed, the DB is updated. Hours work is updated.
Scenario Notes:
none
Postconditions:
1. The Clock In value is updated in the DB.
2. The user is clocked in.
Exceptions:
1. The DB cannot be accessed.
Required GUI:
1. Clock_In_Clock_Out_View
Use Case Utilized:
None
Timing Constraints:
None

26. 25
Use Case 23: Add Inventory Item
Overview:
New inventory item is entered into the department’s Inventory_Table.
Preconditions:
1. User must be manager or above.
2. Database is accessible.
3. Inventory_Table is displayed.
4. UPC to be entered must not already exist in Inventory_Table.
Scenario:
Action Software Reaction
1. User clicks on the Add
Inventory button.
1. The Add_Inventory_Item_view appears.
2. User enters item
information and clicks OK.
2. The System checks the information to make sure it is acceptable format. If
there is an error the field is highlighted red. Else the Add_Inventory_Item_view
closes, and a new inventory record is added to the Inventory_Table.
3. User modifies incorrectly
formatted information, and
clicks OK button.
3. If information is correctly formatted, Add_Iventory_Item_view closes and a
new inventory record is added to the Inventory_Table.
4. User clicks CANCEL
button.
4. Add_Inventory_Item_view closes, no changes are made to the
Inventory_Table
Scenario Notes:
­ Item information consists of: UPC, Quantity
­ Item information can be entered in any order.
­ Actions 2 / 3 and 4 are exclusive.
Postconditions:
1. An inventory record will be added to Inventory_Table.
Exceptions:
­ Information entered in an incorrect format. System does not complete the use case until the user corrects the error.
­ Database is not accessable. System alerts user and does not add inventory record.
­ Item UPC to be added already exists in Inventory_Table. System alerts user and does not add inventory record.
Required GUI:
1. Department view page of appropriate department
2. Add_Inventory_Item_Pop_Up
Use Case Utilized:
UC37
Timing Constraints:​ ​None

27. 26
Use Case 24: Remove Inventory Item
Overview:
Pulls Inventory table from the database and enables user to select an item, then remove it.
Preconditions:
1.DB is accessible.
2.Inventory_Table is displayed.
3.Inventory_Table is populated.
4.An item must be selected.
Scenario:
Action Software Reaction
1.User clicks on an
item.
1.Item is selected and highlighted.
2.User clicks
Remove_Item
2.Item is removed.
3.User clicks OK 3. Inventory table is updated.
Scenario Notes:
None
Postconditions:
1.Item is removed from the table
2.Inventory_Table is displayed.
Exceptions:
1.DB is not accessible.
2.No item is selected.
Required GUI:
1.Inventory_Table
2.Removed_Item_Pop_Up
Use Case Utilized:
1.UC35
Timing Constraints: ​None

28. 27
Use Case 25: Modify Inventory Item
Overview:
Pulls Inventory_Table from the database. Enables user to modify selected item. View will appear with item
information and the user will be able to modify the item information on the view.
Preconditions:
1.DB is accessible.
2.Inventory_Table is displayed.
3.Inventory_Table is populated.
4.An item must be selected.
Scenario:
Action Software Reaction
1.User clicks on an item. 1.Item is selected and highlighted.
2.User clicks on Modify_Item 2.Modify_Item_view is displayed with all the information about the selected item.
3.User clicks on Save 3.Any information that are edited about the item is modified and
Modify_item_view is closed. Item is no longer selected.
4.User clicks Cancel 4.Any information edited will not saved and Modify_item_viewp is closed. Item is
no longer selected.
Scenario Notes:
Action 3 and 4 cannot happen at the same time. Either the item will be modified or kept the same.
Modify_Item_view allows you to modify store item’s UPC, name, department, quantity on hand, target quantity,
wholesale price per unit, and sale price per unit.
Postconditions:
1.Item is modified or kept the same.
2.Item is no longer selected.
3.Inventory_Table is displayed.
Exceptions:
1.DB is not accessible
2.No item is selected.
Required GUI:
1.Modify_item_View
2.Inventory_Table
Use Case Utilized:
1.UC35
Timing Constraints ​None
Use Case 27: Create Transaction

29. 28
Overview:
Enables user to create a transaction on the Transaction_Table.
Preconditions:
1. Database is accessible
2.Transaction_Table is displayed
3.Necessary information about the transaction must be filled out on Add_Transaction_View.
Scenario:
Action Software Reaction
1.User clicks
Add_Transaction_Butto
n
1.Add_Transaction_View is displayed that allows user to input
all the necessary information.
2.User clicks Save 2.All the information typed is saved and new data is formed on
Transaction_Table. Add_Transaction_View is closed.
3.User clicks Cancel. 3.Add_Transaction_View is closed.
Scenario Notes:
Action 2 and 3 cannot happen at once. Add_Transaction_View allows user to enter
transaction ID, product’s UPC, and product’s quantity.
Postconditions:
1.New data is created or nothing happens
2.Transaction_Table is displayed.
Exceptions:
1.DB is not accessible.
2.Necessary informations are not filled.
3.Informations are in incorrect format.
Required GUI:
1.Transaction_Table
2.Add_Transaction_View
Use Case Utilized:
UC51
Timing Constraints:​ None

30. 29
Use Case 28: Process Transaction Queue
Overview:
New transaction will enter transaction queue. Automatically pulls data from transaction queue
and stores the information in the transaction table every 5 minutes.
Preconditions:
1.Transaction_Queue is populated.
Scenario:
Action Software Reaction
1.New transaction
occurs
1.The new transaction will enter transaction queue.
2.5 minute timer
triggers
2.All the transactions in the queue will be transferred to
transaction table.
Scenario Notes:
Action 2 will not occur when queue is not empty.
Postconditions:
1.Transaction queue is emptied.
2.Transaction table is filled with new information from the queue
Exceptions:
None
Required GUI:
None
Use Case Utilized:
None
Timing Constraints:
Action 2 is done automatically every 5 minutes.

31. 30
Use Case 32: Select Department
Overview:
Transfers the user to the desired department page.
Preconditions:
1. The user must be logged in.
Scenario:
Action Software Reaction
1. The user clicks on
the department
drop­down menu
1. A list of departments that eh user has access to will
appear.
2. The user selects
the department.
2. The user will be transported to the correct department
page. The page will be loaded in the content area of the
window.
Scenario Notes:
1. If the user does not have the correct privileges certain options will not appear in the menu.
Postconditions:
1. You will be sent to the correct department page.
Exceptions:
1. Could not load the information
Required GUI:
1. Main page of each department.
2. Main Window GUI and controller
Use Case Utilized:
1. UC35
Timing Constraints:
None

32. 31
Use Case 35: Load Department Inventory
Overview:
All records in a department’s Inventory_Table are fetched from the store’s database and
displayed.
Preconditions:
1. Database is accessible
1. User selects one of the 5 general departments from the Department_Drop_Down_Menu.
Scenario:
Action Software Reaction
1. User clicks on
Inventory_Tab on
selected department’s
Department_View
screen.
2. All records in the selected department’s Inventory_Table
are fetched from the store’s database and displayed on the
selected department’s Department_View screen.
Scenario Notes:
Postconditions:
1. All records in the selected department’s Inventory_Table are displayed on the selected
department’s Department_View screen.
Exceptions:
­ Database is not accessable. System alerts user and does not display inventory.
Required GUI:
­ Inventory_Tab
Use Case Utilized:
None
Timing Constraints:
None

33. 32
Use Case 37: Search Inventory
Overview:
This use case enables user to search through the inventory using keywords. This allows the
user to navigate through the inventory table with ease.
Preconditions:
1. DB is accessible.
2.Inventory_Table is displayed
Scenario:
Action Software Reaction
1.User clicks on
Seach_Inventory_Button
1.The table will display all the item that contains the typed
keyword.
Scenario Notes:
For action 1, if the text field is empty, then the table will display everything.
Postconditions:
1.Table will display items that contains the typed keyword.
2.Inventory_Table is displayed.
Exceptions:
1.No items contains the keyword.
Required GUI:
1.Inventory_Table
Use Case Utilized:
UC35
Timing Constraints:
None

34. 33
Use Case 38: Load Employees
Overview:
Pulls Employee_Table from the database and displays it.
Preconditions:
1.Database is accessible.
2.Human Resources page in management department must be displayed.
Scenario:
Action Software Reaction
1.User clicks on
employee page within
customer service tab.
1. Table of employees is loaded from database and
displayed.
Scenario Notes:
None​.
Postconditions:
1. List of employees appear in employees page.
Exceptions:
1.DB is not accessible.
2.Employee_Table is not accessible
Required GUI:
1. Employee page within Human Resources tab.
Use Case Utilized:
None.
Timing Constraints:
None​.

35. 34
Use Case 39: Search Employee
Overview:
This use case enables user to search through the employee using keywords. This allows the
user to navigate through the employee table with ease.
Preconditions:
1. DB is accessible.
2.Employee_Table is displayed
Scenario:
Action Software Reaction
1.User clicks on
Seach_Employee_Butto
n
1.The table will display all the item that contains the typed
keyword.
Scenario Notes:
For action 1, if the text field is empty, then the table will display everything.
Postconditions:
1.Table will display items that contains the typed keyword.
2.Inventory_Table is displayed.
Exceptions:
1.No items contains the keyword.
Required GUI:
1.Employee_Table
Use Case Utilized:
UC38
Timing Constraints:
None

36. 35
Use Case 41: Process Paychecks
Overview:
This use case enables user to click a button to calculate amount of money that employee
needs to be paid.
Preconditions:
1. The database is accessible.
2. All database tables must be populated.
3. Accounting page is displayed.
Scenario:
Action Software Reaction
1. User clicks browse button, and
selects a directory to save file to using
the choose directory prompt.
1. System stores the path and checks if it is
valid, it sets the textField to that value.
2.User clicks
Process_Paycheck_Button
2.The software will calculate the amount of
money with the given information in the
database and output it for the user.
Scenario Notes:
Output of action 1 will be calculated based on hours worked by employees and hourly wage
for the corresponding employee.
Postconditions:
1.The software will output amount of money for paycheck.
2.Accounting page is displayed.
Exceptions:
1.Database is not accessible.
Required GUI:
1.Accounting Page
Use Case Utilized:
UC38

37. 36
Timing Constraints: ​None
Use Case 50: Modify Employee Data
Overview:
Pulls Employee_Table from the database. Enables user to modify selected Employee. Pop­up will appear
with employee information and the user will be able to modify the employee information on the pop­up.
Preconditions:
1.DB is accessible.
2.Employee_Table is displayed.
3.Employee_Table is populated.
Scenario:
Action Software Reaction
1.User clicks on an
employee.
1.Employee is selected and highlighted.
2.User clicks on
Modify_Employee
2.Modify_Employee_View is displayed with all the information about the
selected employee.
3.User clicks on Save 3.Any information that is edited about the employee is modified and
Modify_Employee_View is destroyed. Employee is no longer selected.
4.User clicks Cancel 4.Any information edited will not saved and Modify_Employee_View is
closed. Employee is no longer selected.
Scenario Notes:
­ Action 3 and 4 cannot happen at the same time. Either the item will be modified or kept the same.
­ Modify_Employee_View allows you to modify the employee’s First Name, Middle Initial, Last Name,
Birthday, SSN, Address, Banking Information (Name on Account, Account Number, Routing
Number),Username, Password, Email and Position.
Postconditions:
1.Employee is modified or kept the same.
2.Employee is no longer selected.
3.Employee_Table is displayed.
Exceptions: Use Case Utilized:
1.DB is not accessible 1.UC38
2.No item is selected.
Required GUI: Timing Constraints:
1.Modify_Employee_View None
2.Employee_Table

38. 37
Use Case 51: Load Transactions
Overview:
Pulls Transaction_Table from the database and displays it.
Preconditions:
1.Database is accessible.
2.Transaction page in customer service tab must be displayed.
Scenario:
Action Software Reaction
1.User clicks on transactions page
within customer service tab.
1. Table of transactions is loaded from database
and displayed.
Scenario Notes:
None​.
Postconditions:
1. List of transactions appear in transactions page.
Exceptions:
1.DB is not accessible.
2.Transaction_Table is not accessible
Required GUI:
1. Transaction page within Customer Service tab.
Use Case Utilized:
None.
Timing Constraints:
None​.

39. 38
Use Case 52: Search Transactions
Overview:
Enables user to search through the inventory using a Transaction ID. This allows the user to
find the correct transaction.
Preconditions:
1. DB is accessible.
2.Transactions_Table is displayed
Scenario:
Action Software Reaction
1.User clicks on
Seach_Transaction_Butt
on
1.The table will display the transaction relevant to the given
ID.
Scenario Notes:
For action 1, if the text field is empty, then the table will display everything.
Postconditions:
1.Table will display items that contains the typed keyword.
2.Transactions_Table is displayed.
Exceptions:
1. The ID cannot be found.
Required GUI:
1.Transactions_Table
Use Case Utilized:
1. UC51
Timing Constraints:
None

40. 39
Use Case 53: Log In
Overview:
This Use Case enables the User to log into the MMMS.
Preconditions:
1. The user is logged out of the MMMS.
2.The database is accessible.
3. Log_In_Log_Out View is displayed.
Scenario:
Action Software Reaction
1. The user enters username
and password and clicks the
log_in button.
1. The DB is accessed to see if a record exists with the
provided username and password.
MMMS_Desktop_View is displayed if the record is
found.
Scenario Notes:
Postconditions:
1. The MMMS_Desktop_View is displayed.
Exceptions:
1. The DB cannot be accessed.
Required GUI:
1. Log_In_Log_Out_View
Use Case Utilized:
1. UC39_Search_Employees
Timing Constraints:
None

41. 40
Use Case 62: Log Out
Overview:
This Use Case enables the user to log out of the MMMS.
Preconditions:
1. The user is logged into the MMMS.
2.The database is accessible.
3. Log_In_Log_Out View is displayed.
Scenario:
Action Software Reaction
1. The user clicks on
the log_out button on
the
MMMS_Desktop_View
.
1. Log_In_Log_Out_View appears.
Scenario Notes:
Postconditions:
1. The user is not logged in.
2. The user does not have access t
Exceptions:
1. The user is not logged in.
Required GUI:
1. MMMS_Desktop_View.
2. Log_In_Log_View
Use Case Utilized:
None

42. 41
Timing Constraints:
None
Use Case 65: Inventory Alert
Overview:
Every 30 minutes, inventory is checked for low stock levels. If stock level for an item is below
the target level, this use case would allow the system to produce an inventory alert and send
it to the notification panel for the managers to check.
Preconditions:
1. The database is accessible.
2. Stock level of one or more inventory item(s) is below the target level.
Scenario:
Action Software Reaction
1. Stock levels are
checked.
1. Text of the Notifications button in the MMMS_Desktop_View
increments by 1. An alert is produced with names and stock levels
of the items with low stock levels. Notification table in the DB is
updated with this new alert.
Scenario Notes:
Postconditions:
1. Notification_Panel_View is updated.
2. Text of Notification_Button is incremented by 1.
3. The database is updated with the new alert.
Exceptions:
1. The database cannot be accessed.
Required GUI:
1. MMMS_Desktop_View
2. Notification_Button
Use Case Utilized:
UC68_Create_Message
Timing Constraints:

43. 42
None
Use Case 68: Create Message
Overview:
Allows user to send a message to their corresponding department manager. The message is
user typed and user information and date are automatically attached to the message.
Preconditions:
1.Send_Message_Page must be displayed.
2.Message text box must be filled.
Scenario:
Action Software Reaction
1.User clicks
Send_Message_Button
1.The message is saved into Message_Table in the database for
the manager to view. Message_Sent_Pop_Up is displayed
2.User clicks OK. 2.Message_Sent_Pop_Up is closed and the user is sent back to
the main page.
Scenario Notes:
When action 1 occurs, the message is saved into the database along with user information
and the date it was written.
Postconditions:
1.Message_Table is updated with the new message.
2.Main department page is displayed.
Exceptions:
1.Message text field is empty.
Required GUI:
1.Send_Message_Page
2.Message_Sent_Pop_Up
3.Main_Page
Use Case Utilized:

44. 43
Timing Constraints:
None
Use Case 69: View Messages
Overview:
Allows the user(managers) to access the Message_Table and view the message written by
other employees.
Preconditions:
1.Database is accessible.
2.Message_Table is populated.
3.Message_Table is displayed.
Scenario:
Action Software Reaction
1.User clicks on a
message
1.Message is selected and highlighted.
2.User clicks on
Display_Message
2.Display_Message_Pop_Up will be displayed that
contains the employee information and the message.
3.User clicks OK 3.Display_Message_Pop_Up is closed.
Scenario Notes:
None
Postconditions:
1.Message_Table is displayed.
2.Message in the table will be marked as read.
Exceptions:
None
Required GUI:
1.Message_Table
2.Display_Message_Pop_Up
Use Case Utilized:
None

45. 44
Timing Constraints:​None
Use Case 71: Inactivity Alert
Overview:
After 9 consecutive minutes of inactivity, the logged­in user is warned of an auto log­out. If
inactivity persists for an additional minute, an auto log­out is carried out.
Preconditions:
1. User must be logged in
Scenario:
Action Software Reaction
1. User remains idle
(no mouse clicks) for 9
consecutive minutes
1. The Inactivity_Alert_Pop_Up appears
2. User clicks OK 2. The Inactivity_Alert_Pop_Up is destroyed without logging the
user off.
3. User remains idle
(no mouse clicks) for
an additional minute
3. The user is automatically logged out, the
Inactivity_Alert_Pop_Up is destroyed, and Log_In_Log_Out_View
is displayed
Scenario Notes:
­ Actions 2 / 3 are exclusive.
Postconditions:
1. The user remains logged in (Action 2)
2. The user is logged out (Action 3)
Exceptions:
None.
Required GUI:
Inactivity_Alert_Pop_Up
Log_In_Log_Out_View
Use Case Utilized:
UC62_Log_Out

46. 45
Timing Constraints:​None
Use Case 80: Remove Old Transactions
Overview:
The software will automatically search through the transaction table daily at a fixed time and
search for transactions that are 30 days old or older. The searched transactions will be
deleted.
Preconditions:
1.Transaction_Table is populated.
2.Transaction is 30 days old.
Scenario:
Action Software Reaction
1.The software does a search
through the table.
1.The searched transactions will be deleted from the
database.
Scenario Notes:
Postconditions:
1.Transaction is removed.
Exceptions:
None
Required GUI:
None
Use Case Utilized:
UC51
Timing Constraints:
The action 1 occurs daily at a fixed time of 11:59PM.

47. 46
Use Case 82: Backup Database Table
Overview:
This Use Case allows the user to manually backup all records of a desired table to a log file.
Preconditions:
1. A database is selected from the DB_Drop_Down_Menu_Button
Scenario:
Action Software Reaction
1. Backup_Database_Button is
pressed.
1. A copy of the database is created and is
backed up.
Scenario Notes:
Postconditions:
1. Selected database is backed up.
Exceptions:
1. The database is not selected.
Required GUI:
1. Backup_Database_View
Use Case Utilized:
None
Timing Constraints:
None

48. 47
Use Case 83: Restore Database Table
Overview:
This use case allows a user to load information from a log file, and replace existing
information or append to the existing information in the database’s corresponding table.
Preconditions:
1. User is viewing the administrative backup / restore page.
2. The database is accessible.
Scenario:
Action Software Reaction
1. The user clicks browse 1. system file browser pop up appears.
2. The user selects a database
backup file
2. System check if file is acceptable.
3. User clicks restore button 3. System replaces the database file with the
selected file.
Scenario Notes: None
Postconditions:
1. The selected database table will be modified with the log data in the specified manner.
Exceptions:
1. The log file is not readable, the system will inform the user with a notification.
Required GUI:
1. Backup / Restore tab within the administrative department.
Use Case Utilized:
None.
Timing Constraints:
None.

49. 48
Use Case 88: Modify Data Path
Overview:
Changes the path where database is stored.
Preconditions:
1. User must be the administrative.
2. User must be on the Administration page.
3. User must be under the System Setup tab on Administration page.
Scenario:
Action Software Reaction
1. User clicks Browse_Button 1. Browse Window appears for user to select the
database.
2. User clicks open in browse
window
2. Browse Window is closed and database path is set.
3. User clicks cancel in browse
window
3. Browse WIndow is closed and database path value is
unchanged.
4. User clicks
Save_Data_Path_Button
4. System.properties file is updated.
5. User clicks Cancel_Button 3. The data path is not changed and user stays on
System Setup tab.
Scenario Notes:
Postconditions:
1. System information page displayed
2. Data path is changed, or not.
Exceptions:
1. Path is not accessable
Required GUI:
1. Administrative Page
2. System Setup

50. 49
Use Case Utilized:
None ​Timing Constraints: ​None
Sequence Diagrams:

51. 50
UC09

52. 51

53. 52

54. 53

55. 54

56. 55

57. 56
UC28

58. 57
UC32
UC35

59. 58
UC37
UC38

60. 59
UC39
UC41

61. 60
UC50
UC51

62. 61
UC52
UC53

63. 62
UC62
UC68

64. 63
UC69
UC71

65. 64
UC80

66. 65
UC82

67. 66
UC88

68. 67
Category Interaction Diagram

69. 68
Object Design:
Software Architecture:​ Model View Controller (MVC)
Model ​­ Much of the functionality in the model portion of the software relate to database
access and data manipulation, we have contained this portion in just a few classes.
View ​­ We are using JavaFX, therefore our view will primarily be defined in .fxml files to
properly adhere to a MVC architecture. We have broken down our interface into many
small elements and “pages” within the software, and each element/page has its own
controller.
Controller ​­ We have elected to break down our interface controllers into small focused
controllers which only operate on a specific page/view of the program. This allows for
better overall organization of the program’s structure. The controller for each interface
element will handle events that occur in the page/view.
Our General Object/Class design contains the following groups:
Object Classes (ex: Employee or Inventory Item)
- Represent records from database tables.
- Used to manipulate data in the software after loading from database.
- Sent to database class to store values representing table records.
Controller Classes (ex: Employee View or Employee Edit)
- Handle events from the corresponding FXML defined interface.
- Event handlers contain the majority of the logic for each event that can occur.
- Each controller contains variables and event handlers that directly manipulate
data and the interface that the user sees.
Helper Classes (ex: Database or Page Navigator)
- Program wide accessible methods and variables.
- Database Functions provides static functions which allow access to the database.
- Page Navigator aids in navigating the user around the interface, by acting as the
hub for page switching across all classes of the program.

70. 69
Test Cases:
Test Case: Login
Type: Black­box, Number of Tests: 6 (5 for Input 1, and 1 for Input 2)
Attributes Descriptions
Name Login
Location /<Project Root Folder>/src/MegaMartMS/Controllers/LoginScreenController.java
Input Input 1) A username and password combination that exists in the database is
entered, and login clicked.
Input 2) A username and password combination that does not exist in the database is
entered, and login clicked.
Oracle Oracle 1) The corresponding user should be logged in and the department menu has
the user's accessible departments added to it, and the user menu has the
users name displayed and drop down is populated.
Oracle 2) The program should not log the user in and should print out a message
informing the user they entered incorrect information into the username
and/or password field.
Log Log 1) The two menus are correctly populated and user has access to rest of program.
Log 2) The program tells the user they entered invalid info, and the login screen
remains displayed.
Test Case: Page Navigation
Type: White­box, Number of Tests: 13 (All pages that are loadable)
Attributes Descriptions
Name Page Navigation
Location /<Project Root Folder>/src/MegaMartMS/Objects/PageNavigator.java
Input Input 1) Clicking interface items that will load/navigate to a different page. For example:
selecting a department from the drop down menu, selecting a tab within a page, or
clicking the add employee button.
Oracle Oracle 1) The destination page should correctly load and be displayed, if any data needs to
be passed to the new page it should do so by passing it to the page's correct
controller instance.
Log Log 1) The correct page page is loaded and necessary information is passed. For example
when modifying an employee the selected employee object from the table view is
passed to the employee edit page.

71. 70
Test Case: Search Employee
Type: Black­box, Number of Tests: 9 (One for each type of possible search type)
Attributes Descriptions
Name Search Employee
Location /<Project Root Folder>/src/MegaMartMS/Controllers/EmployeeViewController.java
Input Input 1) User inputs a spaceless string into the search field and clicks search.
Input 2) User inputs a number into the search field and clicks search.
Input 3) User inputs a string that contains one white space in the middle into the search field
and clicks search.
Input 4) User inputs a blank string or a string composed of only white space into the search
field and clicks search.
Oracle Oracle 1) The table view should be updated to display employee records that have a
matching attribute to the search string.
Oracle 2) The table view should be updated to display employee records that have a
matching employeeID or phone number to the search string.
Oracle 3) The table view should be updated to display employee records that have a
matching first and last name to the words separated by the white space in the
search string.
Oracle 4) The table should be updated to display all employee records in the database.
Log Log 1) The table view updates to display employee records in which an attribute entirely
matches the search string.
Log 2) The table view updates to display employee records in which the number entirely
matches either the employeeID or the phone number the search string.
Log 3) The table view updates to display employee records in which the first and last name
match the two word in the search field in any order.
Log 4) The table updates to display all employee records in the database.
Test Case: Logout
Type: White­box, Number of Tests: 1 (Only one way to logout, via profile menu)
Attributes Descriptions
Name Logout
Location /<Project Root Folder>/src/MegaMartMS/Controllers/MainWindowController.java
Input Input 1) While the user is logged in, they select the "Logout" button from the profile drop
down menu.
Oracle Oracle 1) Current user and department should be set to null, login screen should be loaded,
and all options should be removed from both the department menu and the profile
menu.
Log Log 1) The login screen is displayed, and both the menus are cleared.

72. 71
Topic Choice Rational:
Out of two desired topics of: 1. Game of Life and Death 2. Management System for a
retail store, we chose the second one because of the following reasons:
1. It is practical and realistic in a sense that it is very close to a real world
application. The experience that we will gain through building this application can
be easily used to build an application for a company.
2. It is easy to expand this project into even a larger scale project by making it a
franchise, for example.
3. Neither it is trivial nor it is a very large scale project. This project can be finished
within the given time frame (about 4 months).
A computer system, on which MMMS will be installed, is required to have:
1. Software
a. Java 8 (Our software uses JavaFX 8)
2. Hardware
a. 4 GB (or more) RAM
b. Networked to adequately sized database
An interface for cashiers, self checkout systems and customer service systems, which
will communicate with the main interface with MMMS, must have:
1. Software
a. Java 7 or above
2. Hardware
a. 4 GB (or more) RAM
b. A barcode scanner may be used, assuming it simulates keypresses
as its form of input.

73. 72
Use Cases Rationale:
The use of use cases most definitely aided in our development of the software.
By using use cases we were able to distil the core requirements that our software had
into clear cut functionalities. After constructing a requirement traceability matrix via
extracting shall and will statements from our problem statement, we quickly saw
common program requirements. Many of the functional requirements were representing
the exact same software functionality, thus we were able to define a use case which
represented the functionality described by the requirement statements.
We found that through the use of use cases we were able to explicitly define our
software’s functional requirements. After having defined all of our use cases we
examined each closely and were able to break down all of the possible steps during a
user's interaction with the software. A prime example use case of how breaking down all
of the possible user/software interactions was helpful is UC09_Add_Employee.
In UC09 we went through every possible state that the user and system might
face when interacting, as can be seen below in the scenario.
Action Software Reaction
1. User clicks on the
Add Employee button.
1. The Add_Employee_Edit_Page appears.
2. User enters
employee information.
And clicks Ok button
2. System checks the information to make sure it is
acceptable format. If there is an error the field is highlighted
red. Else the Add_Employee_Edit_Page closes, and a new
employee record is added to the database.
3. User modifies
incorrectly formatted
information, and clicks
Ok button.
3. If information is correctly formatted,
Add_Emplpoyee_Edit_Page closes and a new employee
record is added to the database.
4. User clicks cancel
button.
4. Add_Employee_Edit_Page closes, no changes are made
to the employee database
Through this process of walking through the user’s interaction, we were able to
break down all of the possibilities that we as developers needed to account for when
actually programming this portion of the software. We referred to this scenario diagram

74. 73
during the process of implementing UC09_Add_Employee to check and make sure we
had correctly defined the softwares response to all possible user input.
This example among many others allowed us to seriously examine the details of
our software before we were in the process of dealing with code. Resulting in a better
understanding of what needed to be done, and how to do it when it actually came time
to implement the use cases.
After defining and examining each use case we were able to represent them as
sequence diagrams which ultimately aided in the development of our class and object
structure.
So overall the use of use cases allowed for explicitly defined functionalities of our
software which we were able to break down and analyze prior to actually delving into
the programming aspects; therefore, allowing us to be better prepared when it came
time to actually implement. They were extremely useful to us even when our project
scope was small (relatively speaking), so we clearly see how they would play an
essential role in the development of a larger scale application.

75. 74
Class and Object Design Rationale:
When designing classes and objects, the goal is that they would “fall out” of the
sequence diagrams. we found, however, that this is only somewhat the case. The use
of sequence diagrams most definitely gave us a direction to head in when designing our
classes and objects but we found as we began actual development of the software that
there were many classes that we were unable to foresee needing from the sequence
diagrams.
What we did find the sequence diagrams useful for was determining what exactly
our our boundary and control objects would be. Due to our planned use of JavaFX and
our intended software architecture, that being Model­View­Control, we already knew
that we were going to be defining our boundary objects in FXML files and our control
objects as controller objects, one for each FXML defined boundary object. Going into
object design with this pre­determined structure allowed us to easily extract our exact
boundary and control objects that we needed to create in order to comprehensively
create our interfaces and controller classes for our application. An example of this can
be seen in the sequence diagram below:
As can be seen in the sequence diagram above, when the user encounters the
login use case they must be interacting with a login screen, we determined that the login
screen would be the boundary object. We could then easily determine that we needed a

76. 75
controller for the login screen to deal with the logic of logging in. This is what is labeled
as “log_in/out_view” above. Despite our lack of quality naming in our sequence diagram
we easily extracted the correct object designs from this sequence diagram.
We tended to find that our entity objects were more readily designed based on
the database schema, that we developed from our RTM, than they were from our
sequence diagrams. This is most likely a shortcoming on our part in the actual creation
of our sequence diagrams than it is in the utility of them if done properly before object
design. Each object that we derived from our database schema directly represents a
record in a corresponding database table.
Our limited project scope allowed us to proceed with this method of object
design. Were it a real world application or a larger scale project, we are quite aware that
this methodology of object design is simply not feasible. Therefore, we see the intrinsic
value that sequence diagrams have during object design, and are well aware that our
somewhat unorthodox form of object design the incorrect approach. Ultimately we have
concluded that sequence diagrams are extremely useful and necessary, especially
when done properly. But when dealing with a limited project size, there are other ways
to go about designing objects that might work just as well, albeit unorthodox in nature.

77. 76
Test Case Rationale:
Login Rationale​: To correctly allocate user's access to software functionalities based
on position within the store, we needed to test the software to make sure that the
appropriate pages are accessible to the employee that logs in. We also needed to test
the database access by searching employee based login credentials and return the
appropriate employee object based on the database records.
Page Navigation Rationale​: To access all the functionalities of the software, we
needed to test the back­end for loading FXML files and correctly storing their controller
instance when necessary. This allows for fluid software navigation and allow user to
access pages that they need for various software functionalities.
Search Employee Rationale​: It's important for the user to narrow down the list of
employees displayed in the table view. Because we programmatically search only likely
matching attributes of the employee record to the search field, we needed to test all the
possible search format, that is why we needed to have extensive testing.
Logout Rationale​: Because we're allowing the user to access only what they're allowed
to, we need to be able to revoke all access until another user uses the software. This
ensures that user doesn't have unauthorized access to software functionalities when
they are not personally logged in. By clearing current user/department and clearing drop
down menus, we are able to disable access to any software page other than the log in
screen.

78. 77
Function Point Cost Analysis:
Weighting Factor Estimation:
Measurement Parameter Count Simple
User Inputs 11 * 3 = 33
User Outputs 7 * 4 = 28
User Inquiries 17 * 3 = 51
Number of Files 2 * 7 = 14
External Interfaces 2 * 5 = 10
Total: 136
For the 14 points, we had plus the complexity adjustment factor we had:
Factor Value
Backup and Recovery 5
Data Communications 4
Distributed Processing 0
Performance Critical 3
Existing operating environment 3
Online data entry 0
On­line input transactions over multiple screens 0
Master files updated online 0
Inputs, outputs, files, inquiries complex 1
Internal processing complex 0
Code designed for reuse 3
Conversion/installation in design 2
Multiple installations 1
Change and ease of use 5
Complexity adjustment factor 1.17
∑F15: 28.17
FP = x * (0.65 + (0.01 * ΣF15))
FP = 136 * (0.65 + (0.01 * 28.17)) = 126.71
If we have the following assumptions:
1.The organization produces an average of 7 function points per month
2.The labor costs is $8000.00 per month
We can estimate that the cost per function point is ($8000/7) or approximately $1140
For 126.71 FP the project will cost $(1140 x 126.71). Which is $144,449.40

79. 78
Constructive Cost Model (COCOMO):
The effort multipliers for this project are:
Multiplier Rationale Value
Reliability Small network scope; Backup options implemented; Consistent architecture .88
Database 64 KB .94
Complexity Basic Processing .7
Timing Computations are not processor­intensive 1
Storage Does not use much RAM 1
Machine Stable; can be commercially available .87
Turnaround Interactive software: users’ actions will be processed and completed almost
instantaneously as they are entered.
.87
Analysts Experienced software analysts 1
Programmers Experienced programmers .86
Experience No experience in management 1.42
Experience No time spent on the micro 1.21
Experience 3 years of experience with the language 1
Practices Almost 3 years of experience in modern practices .82
Tools Very basic micro software 1.24
Schedule Nominal scheduled completion time 1
E = a​b ​* (KLOC)​b​
* b = 2.4 * 6.5^1.05 = 17.13 Programmer Months
Effort Adjustment Factor(EAF) = 0.658
When Applied to the nominal estimate the effort adjustment factor produces an estimate of:
11.3 programmer months
The estimation of Development time is:
D = c​b​ * E​d​
* b = 2.5*11.3**.38 = 6.3 months
Assuming that the programmers and analysts cost $8,000 per person month, the total cost is:
Dollars = 11.3 PM * 8000/PM = $90,400.

80. 79
Cost Analysis Comparison and Conclusion:
During development, we found our initial Function Point Analysis to be somewhat
imprecise. We believe that this is due to the fact that we ended up making some
modifications to sections of the software that are used to calculate the Function Point
Cost during the development of the software.
An example of this is the number of User Inquiries, before actually diving into
development of the software we anticipated we would be accessing the database far
more often than we actually are. We still access the database quite often due to the
nature of our application but initially we did not have an accurate estimate of how often
we would. Through the actual development of our application we found that we access
the database in approximately 17 different places; this is far lower than our initial
estimate which was in the 30’s.
These values that were updated during development brought our Function Point
cost estimate to a more reasonable value. It went from ~$300,000 down to ~$145,000.
This was a far more realistic estimate, especially when compared to our Constructive
Cost Model estimate, which is ~$90,400.
Given our final software, we feel as if these two cost analysis estimates each
serve their purpose, and would accurately represent the total cost of our software were
it to be developed in a real world development scenario. We feel this is the case due to
the experience we have had during development including but not limited to: the time
requirement to fully develop, final number of inputs and outputs and our experience or
lack thereof. Therefore we found it a useful exercise to analyze the potential cost of our
software using both the Function Point Analysis and The Constructive Cost Model.

81. 80
Horizontal Prototype:
Login:
Menu Structure:

82. 81
General Department:
Management:

83. 82
Administration:

84. 83
Project Legacy:
Expectations:
­ Going into the project we anticipated our database access class would be the
most difficult portion of our software to develop.
­ We knew our project scope was large, and we anticipated spending quite a bit of
time to get all of our project implemented and working bug free.
­ We thought page navigation would be as simple as replacing the current page
with the new one. And did not think about dealing with persistent menus or UI
elements.
­ We thought that using cloud storage (Google Drive) for project storage will allow
for shared access to updated code.
Realizations during development:
­ It turns out that developing our page navigation was more complicated than
expected. This is due to the fact that we embed interfaces within other interfaces,
this requires maintaining instances of high level interface controllers, which are
accessible program wide.
­ The project scope is massive and we have found many things that we needed to
add to the software, such as a cash register view for creating transactions, the
Page Navigator class for switching between embedded interfaces.
­ In the end we had to slightly modify some of our initial requirements to be able to
complete the project on time. An example of this is our database backup, initially
we planned to create a formatted log files storing each of our tables, but during
development we found this to be far more time consuming than anticipated,
therefore we went with entire database file backups instead, which results in
similar functionality but less required development time.
­ Multiple members accessing and saving code at the same time has resulted in
many duplicate/conflicting file errors and at times entire project corruption, which
required manually transporting our code into a new project file.

85. 84
Work Schedule Diagram:

86. 85
Gantt Chart goes hereee