RED AI Prototype Requirements – version 2
CS411W
Patrick R. Bourque
Janet Brunelle
March 05, 2008
Bourque 03/05/2008
Table Of Contents
Table Of Contents ....................................................................................................................................... ii
List Of Figures ............................................................................................................................................ ii
List Of Tables ............................................................................................................................................. ii
RED AI Prototype Requirements................................................................................................................ 1
1
Introduction ......................................................................................................................................... 1
1.1
Purpose........................................................................................................................................ 2
1.2
Scope ........................................................................................................................................... 4
1.3
Definitions, Acronyms, and Abbreviations ................................................................................ 5
1.4
References ................................................................................................................................... 7
1.5
Overview ..................................................................................................................................... 8
2
General Description ............................................................................................................................ 8
2.1
Prototype Architecture Description ............................................................................................ 9
2.2
Prototype Functional Description ............................................................................................. 10
2.3
External Interfaces .................................................................................................................... 14
3
Specific Requirements ...................................................................................................................... 16
3.1
Functional Requirements .......................................................................................................... 16
3.2
Performance Requirements ....................................................................................................... 20
3.3
Assumptions and Constraints .................................................................................................... 22
3.4
Non-Functional Requirements .................................................................................................. 22
Appendix 1 Requirements Checklist .................................................................................................... 24
Appendix 2 Requirements Traceability Matrix .................................................................................... 28
Appendix 3 Formal Resource Request Form........................................................................................ 29
List Of Figures
Figure 1. Least Common Denominators of Profit ..................................................................................... 2
Figure 2. Software Major Functional Component Diagram ...................................................................... 3
Figure 3. Sample Service Deficiency......................................................................................................... 4
Figure 4. Prototype Major Functional Component Diagram ................................................................... 10
Figure 5. Login Process Flow .................................................................................................................. 11
Figure 6. Settings Tab Process Flow ....................................................................................................... 12
Figure 7. Input Tab Process Flow ............................................................................................................ 13
Figure 8. Edit Tab Process Flow .............................................................................................................. 13
Figure 9. Output Tab Process Flow ......................................................................................................... 14
Figure 10. Sample Suggestion List ........................................................................................................... 18
Figure 11. Database Schema ..................................................................................................................... 19
List Of Tables
Table 1. Feature Comparison between RED AI and Prototype ................................................................. 9
Table 2: Effects of Assumptions, Dependencies, and Constraints on Requirements ............................... 22
ii
Bourque 03/05/2008
RED AI Prototype Requirements
1
Introduction
In 2007, approximately sixty-thousand new restaurants opened their doors for business in
the United States, with startup costs averaging $400,000 apiece. Accounting for $350 billion per
year, the food service industry employs nearly 13 million people in over 900,000 establishments.
Historically, sixty percent of new restaurants fail within the first three years (NRA, 2008). The
result is 14 billion unrecoverable dollars, 520,000 unemployed workers, and 36,000 defunct
businesses each year. The primary cause of these failures is most commonly attributed to
inefficiency, tracable to manager difficulty in obtaining and maintaining a clear understanding of
the dynamics governing the key profit factors of their restaurant (GEC, 2007; Parsons, 2005).
When owners become aware of downward trends, the response tends towards either
replacing middle or upper management, or seeking the advice of an efficiency consultant. With
the turnover of management, hindsight often identifies this as a poor option. Replacements, as
often as not, struggle as much in understanding the dynamics of their restaurant’s profit factors
as the replaced, while their confusion is compounded by lack of experience. Typically, replacing
management does little to spare the restaurant from failure (Parsons, 2005). Contracting an
efficiency consultant can often be identified as the deciding factor in whether a restaurant
survives the three year mark; indeed, most restaurants hire at least one effiency consultant during
their operational lifetime. Unlike replacing one manager’s paycheck with another, however,
efficiency consultant fees are typically in the $1,000 per day range. Restaurant efficiency
consultants understand a restaurant’s four key profit factors are staffing, customer flow and
ordering trends, the menu arrangement, and inventory plan. When commissioned, they spend
Bourque 03/05/2008
Figure 1. Least Common Denominators of Profit
their time studying and understanding the efficiency relationships between a given restaurant’s
key profit factors (Mullins, 2006). The profit factors and their efficiency relationships are
illustrated in Figure 1. RED AI proposes to develop a system to store this wide variety of data,
effectively modeling a restaurant’s key profit factors. The data will be analyzed and suggestions
to improve restaurant efficiency will be generated and presented to the manager or owner.
1.1 Purpose
For owners of struggling restaurants, it is too often that the cost of a private efficiency
consultant is simply out of reach. There is no denying the value of such finely tuned advice, but
even well established businesses may consider the costs impractical. So, too, manager
replacement rarely yields positive results. The ability to obtain and maintain a continuous
understanding of one’s own restaurant’s profit factor dynamic should prove profitable for any
business in the industry. To preempt the need for expensive private consulting and allow
continuous monitoring of a restaurant’s key profit factors, an all-software restaurant efficiency
consultant will be produced. The Major Functional Component Diagram (MFCD) for the
complete system is shown in Figure 2.
2
Bourque 03/05/2008
Upon implemention, RED AI will act as a clearinghouse for restaurant data. Whether
recorded by hand and manually entered, or imported from a preexisting system in the restaurant,
methods will exist for obtaining all pertinent profit factor data. This data will be stored in the
database. Rule sets will be provided and will effectively supply the best available knowledge of
restaurant experts to the efficiency engines. Following a sufficient period of recording, RED AI
Figure 2. Software Major Functional Component Diagram
efficiency engines will begin to determine the relationships between a restaurant’s key profit
factors and profit. By identifying profit factor trends and applying the rule sets, RED AI will be
able to highlight problem areas in the controllable profit factors. An example of this problem is
shown in Figure 3: Sample Service Deficiency.
3
Bourque 03/05/2008
Figure 3. Sample Service Deficiency
1.2 Scope
There are five main functional objectives of the RED AI prototype. First, it will provide
a fully functional graphical user interface (GUI). The GUI will provide all necessary means of
data input, information retrieval, and system controls. Second, it will include a database
designed to store summary data regarding a restaurant’s profit factors. For demonstration
purposes, several preseeded databases and an empty database will be included. Third, updatable
rule sets will be provided. Before executing a rule set update, only rules reflecting the most
commonly accepted restaurant truths will be included, allowing appreciation by the most diverse
audience. Fourth, the efficiency engine’s rule application methodology must be sound. That is,
when analyzing some arbitrary time frame of restaurant history according to some arbitrary
collection of rules, the same set of suggestions should be returned each time. By the same token,
any significant change to the history or rule set should yield a different set of suggestions. Fifth,
great care will be taken to ensure all reported suggestions are easy to understand. While they
may only be referring to simulated data, suggestions written in science will likely prove less
useful than those well translated into hospitality. By incorporating these five elements into the
4
Bourque 03/05/2008
RED AI prototype, the potential of the final RED AI system can be demonstrated. Each of these
objectives is covered in greater detail in section 3.1.
1.3 Definitions, Acronyms, and Abbreviations
ADO.NET: A collection of software available with Microsoft’s Visual Studio .NET
development suite that allows for easy access to data sources.
AI: Artificial Intelligence; 1. The ability of a computer or other machine to perform those
activities that are normally thought to require intelligence. 2. The branch of computer science
concerned with the development of machines having this ability.
Algorithm: A step-by-step problem-solving procedure, especially an established, recursive
computation procedure for solving a problem in a finite number of steps.
Artificial Intelligence Engine: see inference engine
Backwards chaining: An algorithm for proving a goal by recursively breaking it down into subgoals and trying to prove these until facts are reached. Facts are goals with no sub-goals which
are therefore always true.
Back end employee: An employee for the restaurant that is involved with inventory, food,
preparation, and other discrete operations not directly interacting with a customer.
C++: An object oriented programming language.
Database Importer: A software tool that allows for the importation of data from a database into
a computer program.
DB: Database; A structured collection of records that can be queried to retrieve and organize
information.
DB importer: Database importer; A translation application that reads one database structure and
formats the data for another database structure.
Dependent Variable: A variable whose value is dependent on the value of another variable.
Direct mail: Physical mailing address designated by location on a public road.
Efficiency: The ratio of output to input of any system.
Expert system: Also known as a knowledge based system, is a computer program that contains
the knowledge and analytical skills of one or more human experts, related to a specific subject
5
Bourque 03/05/2008
Factor Analysis: The process of determining which predictive variables in a data set are
independent of one another in their predictive capacity.
Firewall: A networking hardware designed to protect a network against unwanted traffic.
Front door: The line that connects an intranet with the internet.
Front end employee: An employee for the restaurant that is involved with hosting, taking
orders, receiving tips, and other operations directly interacting with a customer.
Garbage data: Erroneous or unwanted data inserted into a database.
GUI: Graphical User Interface; Offers a graphical representation of processes rather than a
textual interface.
Inference Engine: A program that makes logical inferences given a set of rules.
Key server: Dedicated server that stores product registration information and can be utilized in
authentication processes of software applications.
Linearly independent: A collection of two or more functions that do not contain a subset of
another’s values.
Microsoft .NET Framework: A software component of Microsoft Windows that encompasses a
wide range of pre-coded solutions to common program requirements.
Microsoft Access: A database program that is a part of the Microsoft Office suite.
Microsoft Visual Basic .NET: An object oriented computer programming language
implemented on the Microsoft .NET Framework.
Multiple Regression: Statistical tool that allows the prediction of a dependent variable’s value
from a set of independent variables.
Pearson Product Moment Correlation: A number between zero and one that quantifies the
degree to which two sets of data are related.
POS: Point of sales; The computer used for receiving and recording sales.
RED AI: Restaurant Efficiency Decision Artificial Intelligence; An application designed to
improve efficiency and profitability of a restaurant based on taking in data and making relevant
suggestions to restaurant managers.
ROI: Return on investment; The percentage of profit received from an investment in equipment
or capital.
6
Bourque 03/05/2008
Reverse Polish Notation: An input scheme developed by Hewitt Packard scientists whereby
both operands are entered before the operator. For example, while a regular calculator takes input
such as “2 + 2 =”, a Reverse Polish Notation calculator would require the same input to be
entered as “2 enter 2 +”.
Rule Set: A collection of conditions along with what it means if a certain condition is true.
Server: A high-end computer that stores information.
Stack: A structure that exists in the computer’s memory. It is a list of elements that can only be
retrieved in the reverse of the order the elements were inserted into the structure.
Token: In philosophy, computational linguistics, and information retrieval, a token is an instance
of a type. The type versus token distinction is a distinction that separates an abstract concept
from the objects which are particular instances of the concept. In logic specifically, the token is
used to clarify the meaning of symbols of formal languages..
User type: A value associated to a user to determine access privileges within an application.
1.4 References
Clarke, R. (1988, February). Knowledge-Based Expert Systems . Retrieved March 26, 2008, from
Department of Computer Science, Australian National University: http://www.anu.edu.au
/people/Roger.Clarke/SOS/KBT.html.
Mullins, S. (2006, October 30). Running a Restaurant: Start up costs. Retrieved January 30,
2008, from AllExperts: http://en.allexperts.com/q/Running-Restaurant-2285/Startcosts.htm.
National Restaurant Association. (n.d.). Research. Retrieved January 29, 2008, from
restaurant.org: http://www.restaurant.org.
Parsa, H., & T., J. (2005, August). Management. Retrieved January 21, 2008, from Cornell Hotel
& Restaurant Administration Quarterly: http://www.hotelschool.cornell.edu/research/chr/
pubs/quarterly.
RED AI. (2008). Lab 1 - Product Description. Norfolk: ODU CS – CPI.
7
Bourque 03/05/2008
1.5 Overview
The remainder of this document provides the specifications for the RED AI Phase I
prototype. Section 2 offers general descriptions of the prototype’s architecture, it’s particular
functionality, and the various hardware, software, and user interfaces it will employ. Section 3
details requirements which must be met to confirm the prototype functionality is sufficient to
demonstrate the innovative fetaures and potential power of RED AI.
2
General Description
The RED AI Phase I prototype will be available online for download and install. It is
designed to showcase the RED AI development team’s pertinent abilities. First, due to its selfexplanatory nature, prototype users will quickly become familiar with navigating and interacting
with the various GUI screens. The prototype interface will prove the development team’s ability
to create intuitive user interfaces that can be easily mastered by users with all but the most
limited computer experience. Second, the prototype database will appropriately model a
restaurant’s key profit factors, whether static or dynamic, controllable or uncontrollable. Here,
the development team’s ability to design, create, manage, and maintain a relatively complex
relational database will be shown. Third, rules will address readily apparent restaurant efficiency
issues. Fourth, effeciency engines will dependably analyze data according to the rule set. Fifth,
suggestions will make sense to restaurant managers and owners. These five together will stand
as proof that the development team can produce the core of the RED AI system. A comparison
of features between RED AI and the Phase I prototype is given in Table 1.
8
Bourque 03/05/2008
Table 1. Feature Comparison between RED AI and Prototype
Feature
RED AI
Phase I Prototype
Real World
Real world data
Simulated data
GUI
Intuitive user interface
Intuitive user interface
Database(s)
Raw data – imported or manually entered
Summary data – compiled from raw data
Summary data – pre-seeded or
manually entered
Rule Set
Full-scale rule set
Small-scale rule set
Efficiency Engine
Apply rules to summary data
Apply rules to summary data
Clearly, there is little difference between the implementation of RED AI and the
prototype. While the prototype may release with a limited rule set and deal only in summary
data, raw data can easily be summarized and entered by hand, and the ability to update rule sets
will be provided. As there are no foreseeable modifications required for the efficiency engine
algorithms between the Phase I prototype and RED AI, the prototype should be considered
highly representative of RED AI.
2.1 Prototype Architecture Description
The prototype will consist of three main software components. The graphical user
interface will allow access to the rest of the system and various controls to manage the
demonstration of the prototype. A database will receive data from the GUI and store it for
analysis. The efficiency engine and rule sets will analyze the data in the database and return
suggestions to the GUI.
9
Bourque 03/05/2008
Figure 4. Prototype Major Functional Component Diagram
2.2 Prototype Functional Description
The RED AI prototype will allow users to log in to and interact with a restaurant database
and the efficiency engine. Users will be provided various levels of control based on their user
type. The system will take the data via input and edit screens. A relational database will store
restaurant data. Several restaurant models can exist on a single system with the ability to swap
database content. When prompted, the efficiency engine will perform efficiency analyses on the
active database according to the current rule set and provide users with suggestions on improving
the efficiency of the current restaurant model. Combined, the GUI, database, and efficiency
engine will constitute the RED AI prototype.
10
Bourque 03/05/2008
Figure 5. Login Process Flow
The GUI will act as the sole interface for prototype users. Included in the GUI are the
login screen and the various tabbed interfaces in the main screen. The login screen, main screen,
and the tabbed interfaces are detailed in the following sections. Upon startup, the user will be
presented with a login screen. A correct username and password combination will allow access
to the RED AI prototype main screen. Each username will be assigned a certain user type, which
will determine the enabled level of access for a given user.
The login process flow is shown in
figure 5. The main screen will present a basic Windows program look and feel. It will also act
as a container for the tabbed interfaces. Login screen and main screen requirements, including a
description of user types, are given in section 3.1.5.
(This space intentionally left blank.)
11
Bourque 03/05/2008
Figure 6. Settings Tab Process Flow
A settings tab will be provided. This tab will offer options to add, modify, and delete
uwer accounts. From this tab, databases can be archived for future analysis, or activated for
manipulation and analysis. At any given time there will be only one active database, hereafter
referred to as “the database” unless otherwise specified. The ability to select alternate rule sets
will also be made available from the settings tab. Only administrator user types will have access
to the settings tab. The settings tab process flow is shown in figure 6. Specific requirements for
the settings tab are given in section 3.1.6.
(This space intentionally left blank.)
12
Bourque 03/05/2008
Figure 7. Input Tab Process Flow
To enter data in the database, input and edit tabs will be provided in the main screen.
Input screens will include customer data, staff schedule data, order data, and inventory data.
Input tab buttons will be restricted based on user type. The edit tab will offer the edit menu
screen in addition to an edit screen for each type of data already entered from the input tab.
Specific requirements for input and edit tabs are given in section 3.1.7.
Figure 8. Edit Tab Process Flow
13
Bourque 03/05/2008
The third tabbed interface will allow for efficiency engine interface. Each output screen
will display suggestions generated in accordance with the current rule set as applied to the active
database regarding the particular type of efficiency. Each output screen will allow scrollable
viewing of suggestions, a “save to file” button, and a “done” button. When selecting an output
screen, the process flow will proceed as shown in Figure 8. Output screen access will be
restricted to Admin and Manager types.
Figure 9. Output Tab Process Flow
2.3 External Interfaces
While the RED AI prototype will demonstrate considerable computational power, it can
not exist in a vacuum. The prototype demonstration will rely on external hardware and software.
Communication and advanced display interfaces will allow the most thorough display of RED
AI’s capabilities.
14
Bourque 03/05/2008
2.3.1 Hardware Interfaces
The RED AI team will build no custom hardware for the prototype. An Old Dominion
University computer capable of supporting the .NET 3.5 framework will be required for
demonstration of the RED AI prototype. This computer will host the demonstration installation
of the RED AI prototype.
2.3.2 Software Interfaces
When installed, RED AI will require only a Windows XP Service Pack 2 operating
system with the .NET 3.5 framework installed. The GUI and Efficiency engines will be
developed in Microsoft Visual Basic .NET 2008. The database will be created with Microsoft
Access 2003. The database connection will be accomplished via the Object Linking and
Embedding Database services for Microsoft Jet DB.
2.3.3 User Interfaces
The RED AI prototype will require standard keyboard and mouse peripherals to provide
input to the system. A monitor capable of VGA at a minimum will display the prototype GUI
screens. Due to the common usage of these devices, the prototype will have the potential for
widespread use.
2.3.4 Communication Protocols and Interfaces
RED AI will need to have an active Internet connection for deployment and connection to
the website. This Internet connection will provide automatic updates. The Internet connection
will also allow the RED AI to show online help to the user when requested.
15
Bourque 03/05/2008
3
Specific Requirements
The RED AI product prototype will meet a variety of specific requirements. Functional
requirements describe what the product must do in order to meet the previously discussed goals
and objectives of the project. Performance requirements constrain some of the functional
requirements to act within certain parameters. Each functional and performance requirement
references a subset of the Requirements Checklist, included as Appendix 2 with requirement
numbers beginning with the letter R. A summary of necessary assumptions and constraints is
included to further describe the anticipated prototype operating environment. Non-functional
requirements complete the parameters for development of the RED AI product prototype.
3.1 Functional Requirements
Herein are given detailed descriptions of the RED AI prototype’s various functional
requirements. These functional requirements must be accomplished for successful
demonstration of the prototype. If any one falls short of these specifications, the prototype
demonstration can not proceed as intended.
3.1.1 Ability to use rules from rulesets
The RED AI prototype demonstration depends almost completely on the prototype’s
ability to shw real time analysis of data according to a given set of rules. To this end, the ability
to have rules and to effectively use them must be provided. The prescribed rule format for a rule
is as follows:
Table_Name[ tokens ] => short_text, long_text, (token), [tokens]
and can be roughly interpreted as:
16
Bourque 03/05/2008
rule_condition => rule, explanation, violators, solution
Table_Name gives the name of the table or view in the database from which to draw data.
Tokens consist of all common arithmetic and logical operators, as well as column names from
the table or view identified by Table_Name. The “left hand side” of this equation is the rule
condition. If the data drawn from the database indicates this rule has been violated, a suggestion
will be generated. The short_text will summarize the nature of the rule in a few words. For each
row whose data indicates a violation of a given rule, the value from the column indicated by the
token in parenthesis on the right hand side will be added to the list of violators. For each rulebreaking row, another calculation may be performed according to the arrangement of the tokens
in square brackets on the right hand side. The solution will be described within the long_text for
each violator. Rules will be contained in rule sets for each type of efficiency. They will be
stored in ASCII format, one rule per line, each line ending with a semicolon. Rule and rule set
requirements are listed in R1.1.
3.1.2 Massage the Data
The efficiency engine will parse the rules, analyze the data, and populate the suggestion
list. The selected efficiency type and table name indicated by the given rule will guide database
access. The database access is discussed in section 3.1.3. When data is retrieved and analyzed
according to the conditions and solutions of the given rule, the suggestions must be generated
and returned to the user. To help manage the potentially large list of suggestions, they should be
arranged in a pivot-table style display. An example of this is given in figure 10. The upper left
section will contain the list of short_texts of broken rules. When a short_text is selected on the
left, the upper right will show the list of that rule’s violators. When a violator is selected on the
right, the lower section will show the long_text containing the calculated solution for that
17
Bourque 03/05/2008
violtaor. The rule parsing and suggestion list populating functions are constrained by
performance requirements given in section 3.2.1. The functional requirements are listed in R1.2.
Figure 10. Sample Suggestion List
3.1.3 Efficiency Engine control of DB
The efficiency engine and database must be designed in consideration of one another.
The efficiency engine will require rapid repeated access of the database. The efficiency engine
will require access to all tables and views within the database. The efficiency engine-database
interface has associated performance requirements given in section 3.2.2. Functional
requiremetns for efficiency engine control of the database are given in R1.3.
3.1.4 Database
The prototype database will be designed to contain the minimal set of data to support the
functionality of the efficiency engine. The required schema for this database is given in figure
10. To analyze data according to the rules, views across appropriate tables must be constructed.
18
Bourque 03/05/2008
The database content must be exchangeable to allow several restaurant models to be used on the
same system. All database requirements are detailed in R2.
Figure 11. Database Schema
3.1.5 GUI, Login, and Main Screen
There are several screens included in the RED AI prototype GUI. First, among GUI
features, are the login screen and the main screen. The login screen will act as the primary
means of user access control, providing username and password entry fields. A correct username
and password pair will allow access to elements of the main screen according to a user type
associated with the provided user name. Login screen requirements, including the access control
summary, are listed in R3.1. The main screen will exhibit a standard Windows program look
and feel, with a menu bar and a tabbed interface. Main screen tabs will be enabled based on the
user type associated with the current user. Main screen requirements are listed in R3.2.
19
Bourque 03/05/2008
3.1.6 Settings Tab
The settings tab will offer administrative features. Each of these is detailed within R3.3.
First, an edit user screen will be available. The edit user screen will allow administrators to add,
delete, and edit authorized users. Each authorized user will be assigned a username, password,
and user type. The significance of user types is given in R3.1. Second, the ability to change the
active rule set must be provided. Rules and rule sets are described in more detail in section 3.1.1.
Third, administrators must be allowed to change the active database. Database requirements are
described in more detail in section 3.1.4.
3.1.7 Take the Data
Two main screen tabs will be designated for the taking of restaurant data into the active
database. The input tab will provide the means of access to the required input screens. Each
input screen will only allow for addition of new data to the active database. The required input
screens and input screen requirements are listed in R3.4. The edit tab will provide the means of
access to the required edit screens. Each edit screen will allow editing of data in the active
database. Editing, here, consists of adding, removing, and changing. The various edit screens
and edit screen requirements are listed in R3.5. Access control for both input and edit tabs are
given in R3.1.
3.2 Performance Requirements
Herein are given detailed descriptions of the RED AI prototype’s various performance
requirements. Once functional requirements are achieved, the RED AI prototype must operate
within these parameters. If any one falls short of these specifications, the prototype
demonstration can not proceed as intended.
20
Bourque 03/05/2008
3.2.1 Efficiency Engine Process
To ensure RED AI prototype demonstration can complete in a timely manner, the
efficiency engine must be constrained in the amount of time it takes to complete its analysis.
The most complex of rules would require data from each of the most distantly related tables for
some given efficiency. The worst case analysis of this rule would require retrieving each entry
from the first table as many times as there are entries in the second table. This gives a machineindependent worst case (d*m*n) number of multiply/add operations where d is the distance
between the first and second table, m is the extent of the first table, and n is the extent of the
second. Including the time required for data retrieval, the efficiency engine must be able to
process each of these (dmn) operations in under 0.5ms on the least powerful machine meeting
all the external hardware and software interface requirements. Further detail on this requirement
is given in R1.2. Another potentially complex process will be the population of the suggestion
list. For each broken rule, the generated suggestion must be prepared for display. The
population of the suggestion list should proceed at a rate of 0.1 ms per suggestion on the least
powerful machine meeting all the external hardware and software interface requirements.
3.2.2 Database Capability
To support the efficiency engine process, and ensure RED AI prototype demonstration
can complete in a timely manner, the database must be constrained in the amount of time it takes
to process requests from the efficiency engine. For any given database query, the database
should respond in less than one milisecond. Again, this must take into account the least powerful
machine meeting all the external hardware and software interface requirements. Further detail
on this requirement is given in R1.3.
21
Bourque 03/05/2008
3.3 Assumptions and Constraints
RED AI prototype is a scaled down version of the full production version. The major
scaling factors are listed in Table 2. They include constraints, assumptions, and dependencies.
Constraints are external factors that influence the project. Assumptions are things that are
assumed to be true and if shown to be false will impact the project. Dependencies are factors
that are required for proper operation of the project.
Table 2: Effects of Assumptions, Dependencies, and Constraints on Requirements
Condition
Type
Effect
Time for prototype
demonstration is limited
Constraint
Pre-seeded databases will be provided
Complexity of complete
system
Constraint
Reduction of database coverage – summary data only,
instead of raw data and summary data
The amount of data required
for a whole day
Constraint
Reduction in analyzed time frame – prototype will analyze
a limited data set based on days instead of months, and
small time blocks instead of hours
Limited involvement of
restaurant experts
Constraint
Reduction in rule set size – only the most obvious
restaurant truths will be addressed in efficiency analysis
The database sufficiently
models restaurant data
Assumption
ODU systems can host
prototype
Dependency If not, personal hardware will be required
Available internet
connection
Dependency Will not be able to demonstrate full functionality
3.4 Non-Functional Requirements
Non-functional requirements are things that are required of the prototype but not directly
needed to show its innovative aspect. Items that fall under the category of security,
maintainability, and reliability are listed as non-functional.
22
Bourque 03/05/2008
3.3.1 Security
There will be a secure login. This login will prevent unauthorized accesses to the
program and database. This is mainly to prevent bad data from getting into the database. If a
certain type of low level user only can add data (not edit or delete) they will be careful when they
enter it because the manager will have to correct their mistakes which will make them look bad.
Also there is always the clients need to keep their restaurant’s secrets secret.
3.3.2 Maintainability
The project will check for updates and download them as necessary. The rule set and
database will be able to be switched and updated also. This updateability is due to the nature of
the prototype being almost production version. The prototype will allow itself to be updated to
the full version (production ruleset and production database).
3.3.3 Reliability
The project will be able to reproduce the suggestions made with the same data and rule
sets. This is important for the prototype because it will show that the ruleset is finite and acting
on the data. Also RED AI will be completely tested and debugged before the presentation.
23
Bourque 03/05/2008
Appendix 1 Requirements Checklist
Requirements Checklist
1.
Efficiency Engine
1. Ability to use rules from rulesets
1. rule format: tblName[ tokens ]  short, long(target,soln), [targettokens][soln-tokens]
2. rule-set format: rule; \n rule; \n …
2. Process
1. Parse / Run the rules
1. parse rules from active ruleset, and apply to data
2. O(d*m*n) … 0.5ms each, where m is extent of 1st table, n is extent
of 2nd, d is distance between tables
2. Populate Suggestion List
1. for each broken rule, provide short text; for each violator, provide
name; for each name, provide long(target[i],soln[i])
2. O(nSuggestions)… 0.1ms each, where nSuggestions is the total
number of suggestions generated.
3. Query DB
1. Must be able to access any view or table in the database as might be
required by the rules.
2. select stmt takes < 1ms
2.
Database
1. A relational database will be designed according to the provided schema
2. Views across the given tables are required to parse rules relating to each
efficiency
1. Service Efficiency View
1. Jobs table
2. Staff table
3. Time table
4. Customer table
24
Bourque 03/05/2008
2. Menu Efficiency
1. Customer table
2. Time table
3. Menu Event table
4. Menu Base table
3. Inventory Efficiency
1. Menu Base table
2. Recipe table
3. Inventory table
3. The development software must support swapping of database content
3.
GUI
1. Login
1. There must be a login screen with the following features:
1. User name entry field
2. Password entry field
3. Login button
4. Cancel button
2. Must interface with user table in DB
3. Unsuccessful logins will allow retries
4. Successful logins will advance program flow to Main Screen
5. Permissions enabled as follows:
25
Bourque 03/05/2008
2. Main
1. Will provide basic Windows program look and feel
2. Will have the following tabbed interfaces:
1. Input
2. Edit
3. Output
4. Settings
3. Settings Tab
1. Edit Users
1. Add user accounts
2. Edit user accounts
3. Delete user accounts
2. Change Rule Set
1. Browse local machine for rule sets
2. Change rule set to selected rule set
3. Change Database
1. Save active database
2. Select new database
3. Set new database as active database
4. Input Tab
1. The following input screens will be created:
1. Customer Input
2. Order Input
3. Inventory Input
4. Staffing Input
26
Bourque 03/05/2008
2. Each input screen will have the following features:
1. Input controls for fields related to the table(s) in question
2. Submit button
3. Cancel button
5. Edit Tab
1. The following edit screens will be created:
1. Edit Customer
2. Edit Orders
3. Edit Inventory
4. Edit Staff
5. Edit Menu
2. Each edit GUI screen will have the following features:
1. Edit controls for fields related to the table(s) in question
2. Save and close button
3. Cancel button
6. Output Tab
1. Each output screen will perform the following functions:
1. Run the efficiency engine according to selected efficiency type
2. Display suggestions provided by the efficiency engine
2. The following output screens will be created:
1. Service Efficiency
2. Menu Efficiency
3. Inventory Efficiency
27
Bourque 03/05/2008
Appendix 2 Requirements Traceability Matrix
Traceability Matrix: Lab 2 => Requirements Checklist
Prototype Requirements, section 3
Requirements Checklist
1 Use Rules from Rulesets
R1.1
Rule format, rule set format
R1.2
Efficiency Engine Process
R3.6
Output Tab
3 Efficiency Engine control of DB
R1.3
Efficiency Engine control of DB
4 Database
R2.*
Database
R3.1
Login
R3.2
Main Screen
R3.3
Settings Tab
R3.4
Input Tab
R3.5
Edit Tab
1 Efficiency Engine Process
R1.2
Efficiency Engine process
2 DB Access
R1.3
DB access speeds
2 Massaging the Data
1 Functional
3 Requirements
5 Login & Main Screen
6 Settings Tab
7 Taking the Data
2 Performance
28
Bourque 03/05/2008
Appendix 3 Formal Resource Request Form
Team: RED AI (CS411 Red Team)
Project Manager: Alex Caulkins, acaulkin@cs.odu.edu
The following resources are required to be purchased for the prototype development and
demonstration of the RED AI product:
Hardware Purchase (list all items required for purchase):
a. None
Software Purchase (list all items required for purchase):
a. None
The following University resources are required to support the prototype development and
demonstration:
• A computer in the CPI Lab NOT held together with scotch tape for the red team
because if the computer case comes undone, the computer turns off immediately and
we lose all our work.
o Required as soon as conveniently possible
• Remote Desktop access to the Red team’s computer in the CPI lab for all members
in our group so we can work on software from home
o Required as soon as conveniently possible
o Will need to be set up again after delivery of new
computer (see above)
• Access to CS Dept. Virtual Server currently in development to assist with
developing our prototype
o We are willing to assist in testing virtual server
environment
o Needed as soon as virtual server is ready for
testing
• Software being used by us: Microsoft Visual Studio
2008, Microsoft Access 2003
o already installed on CS computers by default
29
Bourque 03/05/2008
o no action by Systems is needed
•CVS access for everyone in the group to a folder on the
CS Dept. UNIX server for codeand version control
O Doing this on the cs411red accounts ok
O Required assoon as conveniently possible
•ACL’s set for everybody in group to cs411red account
oRequired assoon as conveniently possible
•Systems group staffmember familiar with E&CS Conference Roommultimedia
setup with us on demonstration day to assist with any technical issues
oDate needed: Prototypedemonstration tentatively set for April 23 and May 5, please
confer with Professor Brunelle closer to these dates to confirm
•The following UNIX/CSNET users are in our group:
O
O
O
O
O
O
mjanda
mcrainer
bterribi
acaulkin
dharri
pbourque
30