Running head:
VIPS: LAB 2 – PROTOTYPE PRODUCT SPECIFICATION
Lab II – Prototype Product Specification
VIPS Inc.
CS411
Janet Brunelle
March 24, 2009
VIPS: Lab II – Prototype Product Specification
Table of Contents
1
INTRODUCTION ...................................................................................................................3
1.1
1.2
1.3
1.4
1.5
2
Purpose ....................................................................................................................... 4
Scope .......................................................................................................................... 8
Definitions, Acronyms, and Abbreviations .................................................................. 10
References ................................................................................................................ 11
Overview ................................................................................................................... 12
GENERAL DESCRIPTION ..................................................................................................12
2.1
2.2
2.3
Prototype Architecture Description............................................................................. 13
Prototype Functional Description ............................................................................... 15
External Interfaces ..................................................................................................... 19
2.3.1
Hardware Interfaces .................................................................................................20
2.3.2
Software Interfaces ..................................................................................................20
2.3.4
Communication Protocols and Interfaces ................................................................22
4 APPENDIX .................................................................................................................................22
List of Figures
Figure 1. Real World Product Major Functional Component Diagram ............................ 6
Figure 2. Prototype Major Functional Component Diagram .......................................... 13
Figure 3. VIPS Website Process Flow........................................................................... 17
Figure 4. VIPS Prototype Database/Website Process Flow .......................................... 18
Figure 5. VIPS Barcode Algorithm ................................................................................ 19
Figure 6. VIPS User Interface Map................................................................................ 22
List of Tables
Table 1. Feature comparison between real world product and prototype ..................... 15
2
VIPS: Lab II – Prototype Product Specification
1
INTRODUCTION
According to the US census (GIS Lounge, 2001), urban population densities are steadily
increasing. Parking in these areas has become a great burden. The effects of the population
growth are felt everywhere. One particular place parking is a burden is on urban universities. The
amount of incoming students and faculty place a big toll on limited parking resources. The
university parking offices must manage all parking patrons. These patrons vary greatly and
include students, staff, faculty, and visitors. The university subscription parkers demand a high
level of service, and the universities have developed a reasonable solution for their subscription
patrons. However, many universities have left out their visiting patrons. Visitor Interface for
Parking Services (VIPS) will solve the visitor element in this complicated parking equation.
Visitor parking is difficult to manage in a subscription-based environment, resulting in
visitor frustration and loss of revenue. Current visitor parking systems on university campuses
are complicated and ineffective at managing visitors. The current process at Old Dominion
University involves a customer finding a parking space close to the parking office. The customer
must then physically walk into the parking office to obtain a visitor pass. The evolution finally
ends with the customer walking back to their car and attempting to find parking close to their
destination. The visitor parking process is difficult and results in frustration by the visitor and the
university attempting to use an outdated process to handle modern visitor demands. James Long,
ODU Parking Services Director, stated ODU fields 15,000 visitor requests per year (J. Long,
personal communication, September 11, 2001). The demand for visitors is high, and the process
currently does not effectively manage the demand.
VIPS Inc. has a solution for these visitor woes. VIPS has designed a solution that will
seamlessly integrate into the universities current parking solution and provide the much needed
3
VIPS: Lab II – Prototype Product Specification
service to visitors. The VIPS solution will solve the current problems of managing visitors and
streamlining the process. Visitor Interface for Parking Services will provide an integrated system
to manage visitor parking for large organizations that utilize a subscription based parking
environment.
1.1
Purpose
VIPS will be a customizable add-on that integrates with whatever current parking
solution is in place at the university. The VIPS product is designed to manage the university's
visitor demands. VIPS will do this by integrating with the university's current technology. The
VIPS system will allow visitors to register online and obtain a visitor pass to the university. The
visitor pass will allow the visitor to enter the parking garages through authenticated barcode
access. The VIPS product will also provide a means of faculty to register their guests. The VIPS
system stores all of the visitor data, which will allow for the development of visitor trend
analysis. VIPS will allow the university to effectively and efficiently manage visitors without
placing added stress on subscribers.
VIPS will offer the university's visitors the ability to reserve parking online. Since VIPS
allows the visitor to register online, there is no need for the visitor to waste trips going to the
parking office. The VIPS system will allow visitors to choose a garage they want to reserve a
parking space in. VIPS will not guarantee a specific parking space. The VIPS guarantee is there
will be an available space in the applicable garage. The methodology VIPS uses to reserve
spaces is an algorithm that calculates spaces available and spaces reserved. The university will
be allowed to limit the amount of visitors the garage can accommodate.
VIPS Inc. will use a gated garage for access control. The visitor pass will have a printed
barcode. The barcode will be scanned at the entrance of a gated garage to grant the visitor access.
4
VIPS: Lab II – Prototype Product Specification
Once a visitor is granted access, the database is updated and a current status of the garage is
available. The VIPS system will also integrate with the current technology in place, which will
ensure every time a car enters or leaves the garage a database is updated. The updated database
will ensure an accurate real-time status of the garage and ensure space reservations can be
accommodated. The database will also provide the university with the ability to use VIPS to
develop visitor trend analysis, to help predicate parking situations.
The VIPS system will also provide the university faculty with the ability to pre-register
their guests. This will lift the burden off of visitors and ensure a smooth interaction with
university guests. The VIPS website will have several authenticated user levels. The user levels
will allow for a standard user, faculty user, and an administrator. The website will also verify
with the database to ensure that the users are valid. VIPS dedication to information security will
ensure all users are authenticated and permitted the proper access into the system.
Figure 1 illustrates the major functional components of VIPS. The light blue boxes
indicate hardware, and the dark blue boxes indicate software. The grey box indicates assumed
customer hardware, and the black box indicates assumed customer software. VIPS will tailor a
solution for any hardware configuration a customer has in place. However, for the purpose of
clarity, only the RFID solution will be discussed.
[This space intentionally left blank]
5
VIPS: Lab II – Prototype Product Specification
Figure 1. Real World Product Major Functional Component Diagram
The VIPS hardware will be comprised of garage components and servers. The garage
hardware will be used to ensure visitor access to the garage. The VIPS garage components will
be a barcode scanner and an intercom. The barcode scanner will be placed at the garage entrance
and exit. The visitor will scan the barcode on the visitor pass upon entry and exit to the garage.
The intercom is in place in case a situation exists where the visitor needs to speak with
somebody at the parking office. The assumed customer hardware is the hardware infrastructure
and the customer database. The hardware infrastructure is in place in the garage to facilitate the
customers handling of their subscription users. In this example, the hardware infrastructure will
include traffic counters, access gates, display boards, and a RFID system. VIPS will also require
6
VIPS: Lab II – Prototype Product Specification
several servers. VIPS will require three servers to run its product. The VIPS engine will run on a
server, and a separate server will be required to run the VIPS website. VIPS will also require a
server to run the VIPS database. There also must be a customer database server. This customer
server will be used to generate user authentication. If a customer database does not exist, VIPS
will develop a database table to perform the authentication. The client computer is used to
represent any computer that is able to access the Internet. The Client computer must have a web
browser and an internet connection. The Client computer will be used to access the VIPS website
and is only shown for completeness.
VIPS will require a significant amount of software to function. The dark blue boxes in
figure 1 denote the software that VIPS Inc. will generate. VIPS has three major software
components; VIPS engine, VIPS website, and VIPS database.
The VIPS engine will be responsible for scheduling the visitors; this is a redundant
feature shared with the VIPS website. This is to ensure there is space available and ensure that
the garages have an accurate count. The VIPS engine will also be responsible for generating all
data reports and developing trend analysis. The major role of the VIPS website is scheduling
visitors and accepting reservations. The website will also be capable of handling the payment for
visitor passes. The website will be responsible for generating the unique barcode, to allow the
visitor garage access. The next major software component will be the VIPS database. The VIPS
database will be designed using Oracle. The database must store all visitor data and current
garage data. The database must also allow both the VIPS engine and website access.
The last software elements that VIPS Inc. will develop are the communication channels
between all of the components. There are several interfaces that must be developed to ensure the
smooth flow of data. The communication channels are represented by the arrows in figure 1. The
7
VIPS: Lab II – Prototype Product Specification
arrow heads indicate the direction of information flow. The main communication points that
need to be addressed are between the VIPS engine and the VIPS database, the VIPS website and
the VIPS database, the VIPS engine and the customer database, the VIPS website and the
customer database, and the VIPS engine and garage hardware. VIPS will use TCP/IP to ensure
the effective communication between these components.
1.2
Scope
VIPS Inc. will prove the VIPS product is feasible by providing an effective, functional
demonstration with a lab prototype. There are many objectives that must be met to achieve the
goal of VIPS Inc. The objectives for the VIPS prototype are interface with RFID technology,
barcode based access to garage, Internet based registration with secure account access control, a
simplified database for visitor reservation management, prevent abuse by validating users against
a blacklist, create a printable pass for use at garage entrance, simulate the parking garage
environment, simulate the arrival and departure of parking patrons, provide a test harness, and
demonstrate historical trends. The objectives will be met by producing an effective prototype.
The key to meeting these objectives will be developing the functional website, database, and the
engine.
The VIPS prototype website will have to be built to satisfy several objectives. The
website will be designed and built with controlled access levels. The website will be secured by
only allowing the authorized users the appropriate amount of access. The website will have
several access levels to include visitor, faculty, department, and administrator. The main
functional objective of the website will be to allow visitors a means of registration. The website
will provide a visitor the ability to pre-register a visit and obtain a parking pass. The parking pass
8
VIPS: Lab II – Prototype Product Specification
will have a printable barcode. The barcode will grant the user access to the garage on the day
they scheduled their visit. The website will interface with the database to ensure the security and
availability of visitor space in a garage.
The database will ensure the smooth operation of the system. The database will have to
store the barcodes and visitor data associated with each barcode. The database will also have to
keep track of all RFID subscription users. The ability of the garage to not be overbooked and
allow the visitor to be guaranteed a space relies heavily on the database. The database must keep
track of all transactions occurring on the website and in the engine. The database will ensure it
knows an accurate state of the garage at all times. It is imperative the database keeps track of the
garage state in order to effectively manage incoming reservations. The database will also be able
to produce a history report. The history report will be the primary means of showing the ability
to develop trend analysis. The trend analysis will be used to help the university more efficiently
handle visitors.
The VIPS engine will be entrusted to handle all incoming and outgoing garage traffic.
The engine will process each access request to ensure that the vehicle either has an authorized
RFID pass or scans an authorized barcode. The engine will be used to ensure this process is
quick and as seamless as possible. The engine will also be responsible for managing
communication between the garage simulation and the database. The amount of data and format
will be controlled with the engine.
There are also several interfaces that will need to be built. These interfaces will ensure
interoperability between the major components. VIPS Inc. believes with the successful
demonstration of a prototype the objectives can and will be met. Therefore, the goal of VIPS, to
9
VIPS: Lab II – Prototype Product Specification
provide an integrated system to manage visitor parking for large organizations that utilize a
subscription based parking environment, will be proven feasible.
1.3
Definitions, Acronyms, and Abbreviations
Barcode – A pictorial representation of numeric or alphanumeric characters that can be
interpreted by a barcode scanner. Barcodes will be used to identify visitors in the VIPS garage
simulation
Client Computer – Any computer capable of accessing the Internet; this is the computer
used to access the VIPS website
Customer – The organization or company purchasing the VIPS product, usually a
university
Display board – A device with three digital panels to display the number of available spaces.
The device is attached to the entrance of each garage and interfaces with the VIPS engine to keep
track of the current number of faculty, students, and visitors
Garage – A building designed to house vehicles consisting of multiple tiers and ramps, which
transition from one tier to another
Hardware Infrastructure – The existing hardware used to support the customer’s parking
solution (i.e. Gates, Pneumatic Sensor, Display Board, etc.)
Interface – A communication channel between two programs or applications
Lot: A single level paved area used for parking cars
Oracle – A database application which stores structured data and accepts Structured Query
Language for retrieval of pertinent information
Parking environment – A large scale business or university that has several different
10
VIPS: Lab II – Prototype Product Specification
garages and lots that are used to handle several types of customers
PHP Hypertext Pre-processor – PHP is a recursive acronym (where a letter in the
acronym is the acronym itself). It is a structured language used in website development
for its ability to dynamically create HTML documents based on differing inputs
Programming Language / Structured Query Language (PL/SQL) – A modification of SQL
to include functionalities of many modern programming languages
Radio Frequency Identification (RFID) – An automatic identification system that uses
radio frequency to identify an item from a distance; in this case, a car has an RFID pass
and it can be read just by the car driving under an RFID reader
Structured Query Language (SQL) – A language that uses English key words, which are
interpreted by a database for the purpose of returning pertinent information
Subscription User – Any person who pays a fee to be able to regularly use a customer’s
available parking spaces for a specified length of time
Terminal – A dedicated computer reserved for a specific input. In the case of VIPS, it will allow
access only to the custom VIPS website for the customer, to allow visitors who did not
preregister to register once they have arrived
Visitor – The end-user of VIPS product
1.4
References
Association for Automatic Identification and Mobility. (n.d.). RFID Glossary. Retrieved Feb 10,
2009, from http://www.aimglobal.org/technologies/rfid/rfid_Glossary.asp
VIPS. (2009). Lab 1 – VIPS Product Description. Norfolk, VA: Author.
11
VIPS: Lab II – Prototype Product Specification
GIS Lounge. (2001, April). U.S. Census 2000 - Population Trends Mapped. Retrieved Feb 10,
2009, from http://gislounge.com/us-census-2000-population-trends-mapped/
Greenwald, R. (2001, June). Introducing Oracle. In Developer.com. Retrieved Feb. 10, 2009,
from http://www.developer.com/db/article.php/1582621.
PC Mag. (n.d.). Definition of: bar code. Retrieved Feb 10, 2009, from http://www.pcmag.com
/encyclopedia_term/0,2542,t=bar+code&i=38421,00.asp#
1.5
Overview
This product specification document illustrates the requirements of the VIPS prototype.
This document will familiarize the reader with the hardware and software components that the
VIPS prototype uses. The VIPS prototype will be built by developing software components that
integrate effectively with the given VIPS hardware. VIPS must ensure these components operate
efficiently together. There are many interfaces that will be required in order to effectively deploy
the VIPS prototype. The interfaces VIPS will use are hardware, software, and user. The
components of the VIPS system will be developed using requirements. The requirements VIPS
has developed are guidelines used to ensure the prototype will be complete and show the VIPS
product is feasible.
2
GENERAL DESCRIPTION
The VIPS prototype will be built in order to show the feasibility of its visitor parking
management system. VIPS will prove the system works by showing the visitor reservation
management works, and the system can be integrated into a current parking environment with
little to no impact on subscription parkers. This section will show how this will be achieved by
describing the prototype architecture, major functional components, and the required interfaces.
12
VIPS: Lab II – Prototype Product Specification
2.1
Prototype Architecture Description
The major functional components of the VIPS prototype are illustrated in figure 2. The
prototype is a simplified version of the VIPS real world product; however, the prototype retains
the innovative functionality of visitor space reservation. In the prototype, the garage hardware
will be simulated and will accept the barcode scanner and RFID inputs. As in figure 1, the dark
blue boxes represent the software components, and the light blue boxes represent the hardware
components.
Figure 2. Prototype Major Functional Component Diagram
The hardware for the prototype will be scaled down from the real world product. The
VIPS engine server will be replaced by a gateway laptop; this replacement will not affect
13
VIPS: Lab II – Prototype Product Specification
functionality. The web server and the database server in the real world product will be replaced
by the ODU Computer Science (CS) department servers. The CS server will be used because it is
the best resource available to VIPS Inc. Finally, VIPS will use a CS department desktop
computer as a client computer. This will be used to test the VIPS website and registration
system.
The software in the VIPS prototype will also differ from the real world product The VIPS
engine will be required to handle the input/output from the garage simulation and be able to
access the database. The VIPS database will use Oracle. However, the database will be scaled
down and will only include the necessary fields to prove functionality. The VIPS database is
further detailed in section 3.1.3. The VIPS website will also be scaled down. The website will be
designed using PHP. The website will be secured with access control. The website will generate
a unique barcode pass, allow the pass to be emailed, and allow the user to create an account. The
website is further detailed in section 3.1.1. VIPS will develop a test harness capable of
manipulating data in order to provide a means of testing the system. Finally, the prototype will
have communication channels and interfaces developed to allow all of the components to
communicate properly. The prototype will attempt to emulate the real world product as much as
possible in the constrained lab environment. Table 1illustrates the differences between the real
world product and the prototype. The VIPS prototype will demonstrate the complete
functionality of the VIPS system, but it will do so at a scaled down level.
[This space intentionally left blank]
14
VIPS: Lab II – Prototype Product Specification
Features
Read World Product
Prototype
Hardware Implementation
Existing customer hardware
Garage Simulator
Barcode reader
Rugged outdoor barcode scanner USB Barcode scanner
RFID
Standard RFID 15ft range
Phidget RFID Kit
Intercom
2-way twisted pair
N/A
Router
Rugged outdoor router
Garage Simulator
VIPS Engine Server
Dell Power Edge Server
Gateway Laptop
VIPS Engine
Manages I/O between garage(s)
hardware and VIPS DB. Datamining
Manage I/O between Garage
Simulator and VIPS DB. DB
report.
VIPS Website
Registration of visitors and
reservation of garage space.
Manage payment info, validate
visitor eligibility with CDB.
Allow dept to reserve space for
visitors.
Register visitors, reserve garage
space, eligibility validation
VIPS Web Server
Dell Power Edge Server
Gateway Laptop
Visitor/Parking Office Computer Any web-enabled device
Gateway Laptop
VIPS DB
Oracle - large-scale multigarage, Full detail tables
Oracle 10g, Limited field,
Implements Customer DB table
Customer DB
Black list built from Parking
Services info on students,
faculty, etc
Implemented as table in VIPS
DB
Table 1. Feature comparison between real world product and prototype
2.2
Prototype Functional Description
The major functional components of the VIPS prototype are the VIPS website, the VIPS
database, and the VIPS engine. Those components ensure the preregistration process and the
ability for a visitor to reserve a space in a garage. The communication between the engine and
15
VIPS: Lab II – Prototype Product Specification
the database is a critical factor in the development of the VIPS prototype. The database must
always have an accurate account of the garage state in order for the visitor registration and
guarantee to be effective.
The VIPS website is the component responsible for allowing the visitor the ability to
preregister for a pass. The website is the user interface into the VIPS system. The website will be
secured through access control and will develop dynamic pages for each user based on that
access. This process is further described in section 3.1.1. The process flow for the website is
illustrated in figure 3. The website will let a new user create an account. The account information
will then be stored on the database. The website will initiate a connection in order to query the
database to authenticate the user. Once access is granted, the website will allow the user to
perform a number of functions based on their access; again, this will be further explained in
section 3.1.1. The communication between the website and the database is very important. The
website will have to query the database to authenticate login, validate user access, and check
reservation availability.
[This space intentionally left blank]
16
VIPS: Lab II – Prototype Product Specification
Figure 3. VIPS Website Process Flow
The VIPS database is another major component. The database is the primary link
between the website and the garage. The database must control access within the website in order
to provide information security. The process flow for the database/website interaction is
illustrated by figure 4. However, the database will be responsible for the access control of the
garages as well. This is because the database is where the barcode and RFID codes are
authenticated to authorized users. The database has to perform a query with the input from the
engine and return a valid or invalid response to the garage. The response the database returns is
ultimately what will allow a user to enter the garage. Therefore, the database is extremely critical
in the overall performance of the VIPS prototype. The database must also maintain an accurate
status of the garage. The status of the garage will be updated by the engine, but the database will
ultimately be responsible for the storage of the values. The database is also critical to developing
17
VIPS: Lab II – Prototype Product Specification
the trend analysis that will allow the customers to better manage the visitor flow.
Figure 4. VIPS Prototype Database/Website Process Flow
The final major component is the VIPS engine. The VIPS engine is responsible for the
flow of all the data between the garage simulation and the database. The engine will ultimately
be responsible for letting the vehicles enter a garage in the simulation. The engine will query the
database with either a barcode or a RFID code. The database will then process that code and
return a value of 1 or 0 to the engine. The engine will either allow or deny access to the garage.
The algorithm the engine uses for determining authorized access can be seen in figure 5. The
engine will also be responsible for updating the database at the start of the day and the end of the
day. The updates are to ensure the database has a current state of the garage and the visitors that
are preregistered have their spot decremented from the total amount of spaces available. The
18
VIPS: Lab II – Prototype Product Specification
engine will update the database with this information and populate the correct information to the
display board.
Figure 5. VIPS Barcode Algorithm
2.3
External Interfaces
This section identifies the logical and physical interfaces used within and by the VIPS
prototype. The interfaces included in this section are hardware, software, user interface, and
communication protocols. The major hardware interfaces are a laptop, CS department server, a
barcode reader, and a printer. The major software interfaces are Oracle, PHP, and Java. The user
19
VIPS: Lab II – Prototype Product Specification
interfaces for the VIPS prototype is provide by the VIPS website. The communication protocol
used is TCP/IP.
2.3.1 Hardware Interfaces
A laptop and a barcode reader will be used to implement the VIPS engine and the garage
simulation. The VIPS website and database will reside on CS department servers. The barcode
reader will be attached to the laptop where the garage simulation is running. Based on a test
range of 6 inches, the barcode reader will be used to read barcode inputs into the garage
simulation. The VIPS database will reside on the CS department database server. The VIPS
website will also be maintained on CS department servers. The servers will provide the speed
and maintainability to ensure the smooth accomplishment of a prototype. Finally, the VIPS
prototype will require a printer. The printer will be used to demonstrate the ability to register and
print a visitor pass. VIPS intends to use a printer live during the presentation. However, if a
printer can not be acquired, VIPS will use a CS network printer.
2.3.2 Software Interfaces
VIPS will require five applications to develop the VIPS prototype. The VIPS website
will be built using PHP. PHP is a robust web development language used to give VIPS the ability
to dynamically create user pages. The test harness VIPS will use to test the system will use PHP
as well. The VIPS database will be designed using Oracle. Oracle gives VIPS the ability to
perform the database functions needed to ensure success. The database is accessed with PL/SQL
based queries. Finally, the VIPS engine and the garage simulation will use Java. Java will be
used to give the simulation the realistic appeal and ensure accurate communication between the
20
VIPS: Lab II – Prototype Product Specification
components.
2.3.3 User Interfaces
The user interfaces in the VIPS prototype are provided by the website. There are six main
user interfaces: VIPS home page, login page, account creation page, pass registration page,
personal page, and account retrieval page. A graphical representation of this is provided in figure
6. The VIPS home page is a welcoming page and will provide the user the option to sign in,
register, or retrieve account information. The login page allows the user to log into the system
with an acceptable password/username pair. The account creation page allows the user to enter
their distinguishing data to create a user account. The personal page is retrieved after successful
login. The personal page allows the user to edit the personal information and access the pass
registration page. The pass registration page can be accessed once a user is logged on and allows
them to request a visitor pass. Once the request is accepted, the page will allow them to print the
generated user pass. Finally, the account retrieval page is used for a user who has forgotten their
password. The account retrieval page will allow the user to retrieve their password.
[This space intentionally left blank]
21
VIPS: Lab II – Prototype Product Specification
Figure 6. VIPS User Interface Map
2.3.4 Communication Protocols and Interfaces
The VIPS prototype will require a significant amount of interoperability in order to
deliver the objective set forth in section 1.2. The VIPS website will need to be accessed by any
client computer. The database must be able to communicate with the web server and the VIPS
engine. These inter-component communication channels must be established and be reliable. The
VIPS team has decided that using TCP/IP communication protocols is the most effective and
reliable way to guarantee inter-component communcation.TCP is a transmission protocol that
establishes a reliable link between computers. Internet protocol or IP refers to the sending of
packets of data across a network connection.
4 Appendix
Major components
A. Hardware
22
VIPS: Lab II – Prototype Product Specification
-Barcode Scanner
-Radio Frequency Identification (RFID) antennae
- RFID tags
- Database server
- VIPS engine server
- VIPS web server
- Intercom
- Client Computer
- Existing Customer Database
B. Software
- VIPS Engine (schedules and handles garage application, Data Mining, Report
generation)
- VIPS Website (schedules visitor reservations, handles payment)
- VIPS database (Oracle)
- Communication (VIPS database and VIPS engine)
- Communication (VIPS database and VIPS Web Server)
- Communication (garage HW and VIPS Engine)
- Communication (VIPS Engine/ VIPS Web Server and Customer Database)
[This Space Intentionally Left Blank]
23
VIPS: Lab II – Prototype Product Specification
Running head:
LAB 2 – VIPS REQUIREMENTS
Lab 2 – VIPS Prototype Requirements
VIPS Inc.
CS411
Janet Brunelle
April 13, 2009
24
VIPS: Lab II – Prototype Product Specification
Table of Contents
3
Specific Requirements .......................................................................................................... 27
3.1
Functional Requirements ............................................................................................27
3.1.1
VIPS Website .......................................................................................................... 27
3.1.2
VIPS Engine............................................................................................................ 32
3.1.3
VIPS Database ........................................................................................................ 35
3.1.4
RFID Tags and Barcodes ........................................................................................ 45
3.1.5
Garage Simulation .................................................................................................. 45
3.1.6
Admin Screen/Test Harness .................................................................................... 49
3.2
Performance Requirements ........................................................................................51
3.2.1
VIPS Website .......................................................................................................... 51
3.2.2
VIPS Database ........................................................................................................ 52
3.2.3
VIPS Engine............................................................................................................ 52
3.2.4
Garage Simulation .................................................................................................. 53
3.3
3.4
Assumptions and Constraints .....................................................................................53
Non-Functional Requirements ....................................................................................55
3.4.1
Security ................................................................................................................... 55
3.4.2
Maintainability ........................................................................................................ 56
3.4.3
Reliability................................................................................................................ 56
List of Figures
Figure 1. VIPS Website Layout ..................................................................................... 28
Figure 2. VIPS Engine Algorithms ................................................................................. 32
Figure 3. Start-of-Day Algorithm .................................................................................... 34
Figure 4. End-of-Day Algorithm ..................................................................................... 35
Figure 5. VIPS Database Tables ................................................................................... 36
Figure 6. Barcode Procedure Flow ................................................................................ 39
Figure 7. RFIDcheck Procedure Flow ........................................................................... 40
Figure 8. ChangeCount Procedure Flow ....................................................................... 42
Figure 9. ClearGarage Procedure Flow......................................................................... 44
List of Tables
Table 1. Comparison of VIPS Website Security Levels ................................................. 29
25
VIPS: Lab II – Prototype Product Specification
Table 2. Garage Simulation Message Format ............................................................... 49
Table 3. Assumptions, Dependencies, and Constraints on Prototype Requirements ... 55
26
VIPS: Lab II – Prototype Product Specification
3
Specific Requirements
The VIPS prototype must achieve several specific requirements. The initial requirements
placed on the VIPS prototype are the functional requirements. Functional requirements describe
what the VIPS prototype must do in order to achieve the goals of VIPS Inc. The performance
requirements are specifications VIPS must achieve in order to meet the functional requirements.
The assumptions and constraints section explains the limited environment in which the prototype
will operate. Finally, the non-functional requirements conclude the framework for the VIPS
prototype requirements.
3.1
Functional Requirements
The VIPS prototype's functional components consist of the VIPS Website, VIPS Engine,
VIPS Database, RFID tags and barcodes, Garage Simulation, and the VIPS Test Harness. Each
component has unique qualities that help shape the VIPS prototype. Although VIPS contains
many components, each is streamlined and designed to be advantageous to the parking services
staff and the visitor.
3.1.1 VIPS Website
The VIPS Website is the primary interface used by parking services staff and visitors to
the university. In order for both the staff member and the visitor to make efficient use of the
webpage, a well planned and well defined layout is necessary in order to create ease of use and
prevent confusion. The VIPS Website layout is illustrated in Figure 1.
[This space intentionally left blank]
27
VIPS: Lab II – Prototype Product Specification
Figure 7. VIPS Website Layout
1. Home Page - The home page acts as the main menu for the rest of the VIPS Website. The
contents of the home page depend on the user's security level (unregistered, visitor,
admin, faculty, or staff), with each level giving access to different options and features.
The various levels of security are shown in Table 1. The unregistered home page will
display the login page.
[This space intentionally left blank]
28
VIPS: Lab II – Prototype Product Specification
Table 2. Comparison of VIPS Website Security Levels
2. Login Page - The page an unregistered web user encounters upon reaching the VIPS
Website. From the login page, the user is able to navigate to the areas acceptable to their
security rating.
a. Allows the user to log into their respective accounts
b. Grants the user the proper access
c. Redirects the user to their personal page
d. The login page provides a link to register for a new account
3. Department - The page a list of faculty that fall under the department. The page allows a
department figurehead to enable the "invite a visitor" feature on user accounts which are
gathered from the VIPS Database. The Department page allows the Department access to
invite individuals to the university.
4. Personal Page - The Personal Page contains links to web pages that the individual has
been granted access.
a. Connects to the VIPSUsers, Visitors, and Dept tables from the VIPS Database
b. Displays the user's data from the VIPS Database
29
VIPS: Lab II – Prototype Product Specification
c. Allows the user's data to be modified. The tables that can be modified are:
VIPSUsers and Visitors. See Section 3.1.3 for the correlating columns/fields.
d. Asks if updates are correct, then saves them
5. Account History - This page displays the user's recent trip history. including the time,
date and car/license plate registered for the visit. For faculty and staff, the page can also
show recently a list of invited visitors. The following data is recorded:
a. Time
b. Date
c. License plate
d. Barcode (which is a unique visit number)
6. Account Creation/Verification - This page allows a user to create an account by
collecting the user's personal information. Account information is stored in the VIPS
Database. personal information gathered includes:
a. First name
b. Last name
c. License plate number
d. Username ( an email address)
e. Password
30
VIPS: Lab II – Prototype Product Specification
7. Pass Registration/Verification - This page is where a user goes when they want to register
a visit to the university. The user provides trip specific information such as date (drop
down), which car they will use (drop down), reason for visit (drop down), and which
parking garage they prefer (drop down). The collected information is then stored in the
Passes table from the VIPS Database. The user can also register to park in a specific
garage.
8. Pass Generation – Pass generation creates a visitor pass with a functioning barcode.
a. The pass gathers the user's information from the VIPSUsers, Visitors,
Subscribers, and Passes from the VIPS Database.
b. The visitor trip identification number is also grabbed from the VIPS Database and
is transfered into a barcode via the PHP-Barcode 0.3pl1 tool kit.
c. The pass is generated when the user information and barcode are turned into an
image file with the GD library.
9. Email – The Email page is similar to the Pass Generation page (Section 3.1.1.8), with an
extra option for sending the pass via email.
a. If a faculty or staff member wishes to invite a visitor, they can fill out a special
invitation form on the Pass Generation page.
b. The pass is then emailed to an invited visitor's email address.
c. The visitor then prints out the pass.
31
VIPS: Lab II – Prototype Product Specification
3.1.2 VIPS Engine
The VIPS Engine's purpose is to ensure the VIPS system maintains an accurate internal
representation of each garage’s available spaces and a history of each gate event. It does so by
acting as an interface between the Garage Simulation and the VIPS Database, performing the
parking space allocation and deallocation necessary to implement reservations, and updating the
Garage Simulation's display board whenever a garage's status changes. The algorithms used to
meet these responsibilities are depicted in Figure 2.
Figure 8. VIPS Engine Algorithms
32
VIPS: Lab II – Prototype Product Specification
As the interface between the Garage Simulation and the VIPS Database, the VIPS Engine
is required to:
1. Monitor messages sent from the Garage Simulation to the VIPS Engine. These messages
will be either sensor data from an RFID sensor or barcode scanner, or a command from
the VIPS Test Harness initiating start- or end-of-day algorithms.
2. Extract identifying information from the message, formatted as specified in Table 2, to
include:
3. Garage identification number
4. Gate identification number
5. Message type
6. The sensor's data
7. If the message is from an RFID sensor or a barcode scanner, the VIPS Engine calls the
appropriate VIPS Database procedure with the parameters extracted from the message.
The VIPS Database procedure returns a value representing the validity of the user and the
new status of the garage.
8. If valid, the VIPS Engine will send data to the VIPS Garage Simulation, formatted as
specified in Table 2, instructing the appropriate gate to open and updating the display
board with the new garage status. The VIPS Engine then returns to its waiting state.
9. If not, the VIPS Engine will send data to the VIPS Garage Simulation, formatted as
specified in Table 2, instructing the appropriate gate to reject the user. The VIPS
Engine then returns to its waiting state.
33
VIPS: Lab II – Prototype Product Specification
Reservations require the VIPS Engine to respond to time-based events in addition to
sensor events from the VIPS Garage Simulation. If a user makes a reservation the same day they
intend to use it, the VIPS Website can make the necessary allocation in the VIPS Database.
However, reservations made for a future date must be handled by the VIPS Engine at a
predefined start-of-day time. A similar situation occurs at the end-of-day time; since reserved
spaces are deallocated when the visitor leaves, any visitor who does not show up will not use
their space.
To manage these cases, the real world product must run reserved space allocation and
deallocation algorithms at a predefined start- and end-of-day time respectively. For the purposes
of the prototype, these algorithms will be initiated by a command from the VIPS Admin
Screen/Test Harness. The VIPS Engine will implement
10.The start-of-day algorithm, as shown in Figure 3.
Figure 9. Start-of-Day Algorithm
11.The end-of-day algorithm, as shown in Figure 4.
34
VIPS: Lab II – Prototype Product Specification
Figure 10. End-of-Day Algorithm
For the most part, the VIPS Engine will be the component that registers changes to the
garages' status and whenever such an event occurs, it will signal the appropriate Garage
Simulation display board to update its display with the new number of available spaces (the
garage’s status). However, because the VIPS Website can make reservations on behalf of a
visitor, it is possible for the VIPS Engine to assume an incorrect status. To prevent an inaccurate
display board, the VIPS Engine must
12.Query the VIPS Database table ‘GarageCount’ to determine the current number of
available spaces in all garages once every two seconds, and message the VIPS Garage
Simulation to update any garage’s display board that is not accurate.
3.1.3 VIPS Database
The VIPS Database is the central point in the VIPS parking management system. It will
be housing data for both the VIPS Engine and the VIPS Website. It will also hold configuration
information for the purpose of the demonstration. The VIPS Database tables are shown in Figure
5.
35
VIPS: Lab II – Prototype Product Specification
Figure 11. VIPS Database Tables
The VIPS Database will contain several stored procedures that will speed up processing
of requests from the VIPS Engine by reducing TCP/IP traffic. These functions will include:
1. Password check procedure – used when logging into the VIPS Website. It will accept or
reject based on:
a. An alphanumeric username
36
VIPS: Lab II – Prototype Product Specification
b. A corresponding alphanumeric password, at least 8 characters
Inputs: userID, password
Output: Char (1 or 0)
2. Barcode check procedure – used when the VIPS Engine needs validation of a barcode.
Once the procedure has determined if it will accept or reject, it must insert into the
history table the gid, tstamp, gateID, code, usertype, and accepted (1 or 0). After the
validity of the entry or exit has been determined, the procedure will call the update
display board procedure and finally return 1 or 0, as well as the display board values.
Figure 6 shows the procedure’s flow chart.
[This space intentionally left blank]
37
VIPS: Lab II – Prototype Product Specification
start
Open cursors
Valid := 0
Barcode found
on today’s
date?
1
Entrance gate?
0
Has entered?
1
1
Not Entered
before?
Not exited?
1
1
Changecount (v-1)
Changecount
(s+1)
0
Changcount
succeed?
0
0
Valid := 1;
Fetch garagecount
values
Insert into history
END
38
VIPS: Lab II – Prototype Product Specification
Figure 12. Barcode Procedure Flow
Inputs: gid, gateID, barcode
Output: Char (1 or 0), availfac, availvis, availstu
3. RFID check procedure – Similar to the barcode check, it will check the student/faculty
table to determine if the entry or exit is valid. The procedure will then check if there are
enough spaces available to accept entry and call the display board procedure. Finally, it
will return 1 or 0, as well as the current values for the display board. Figure 7 shows the
process flow of the procedure.
[This space intentionally left blank]
39
VIPS: Lab II – Prototype Product Specification
start
Open cursors
Found?
1
Student?
0
Entrance?
0
Changecount f+1
0
1
Entrance?
1
0
Changecount s+1
0
Insert history
Changecount f-1
1
Changecount
S -1
Changecount
succeded?
1
Valid = 1
Insert history
Fetch garagecount
values
END
Figure 13. RFIDcheck Procedure Flow
40
VIPS: Lab II – Prototype Product Specification
Input: RFID
Output: Char (1 or 0), availfac, availstu, availvis
4. ChangeCount procedure – used to update the current count of a particular garage as
necessary. It will receive the garage ID, the user type, and an integer value and use them
to increment or decrement the appropriate counter. Figure 8 shows the process flow of
the procedure.
[This space intentionally left blank]
41
VIPS: Lab II – Prototype Product Specification
start
Open cursors
Data < 0?
0
v?
1
v?
0
f?
0
s?
0
f?
0
s?
1
1
1
Availstu >=
data?
Availfac+data
Valid = 1;
Fetch garagecount
values
Availstu + data
Valid = 1;
Fetch garagecount
values
00
1
0
1
1
1
Availstu-data
Availvis + data
Valid = 1;
Fetch garagecount
values
Availvis >=
abs(data)?
Availfac >= abs
(data)?
Availstu >= abs
(data)?
1
1
1
Availvis + data
Valid = 1;
Fetch garagecount
values
0
Availfac + data;
Valid = 1;
Fetch garagecount
values
0
0
Availstu + data
Valid = 1;
Fetch garagecount
values
END
Figure 14. ChangeCount Procedure Flow
Inputs: gid, usertype, integer
Output: none
5. Scenario procedure – will update all necessary values in the VIPS Database to those
specified in the given scenario. This procedure will update the VIPS Database by:
42
VIPS: Lab II – Prototype Product Specification
a. Selecting randomly from a predefined list of visitors
b. Inserting these visitors via the barcode or RFID procedure
i. When adding to the garage, an entry gate will be specified
ii. When removing, an exit gate will be specified.
Inputs: gid, gateID, integer(number to be added/removed)
Outputs: none
6. Add garage procedure – will add a new garage with preset information. Up to two
garages will be available for the prototype.
Inputs: gid
Outputs: none
7. Remove garage procedure – will remove a given garage from the VIPS Database. A
minimum of one garage must remain.
Inputs: gid
Outputs: none
8. Clear garage procedure – will be used to return the garage to an empty state. The
procedure will check the history table to determine those visitors and subscribers who
have not left a garage. For an indicated visitor or subscriber, the correct procedure is
called to immediately register the visitor or subscribers exit. Figure 9 shows the
procedure flow.
43
VIPS: Lab II – Prototype Product Specification
start
Open cursors
Valid := 0;
i := 0;
Garage found?
1
i<
notexitedcount
1
v?
0
RFIDcheck( Gate
2)
1
Barcodecheck(
gate 2)
0
0
Fetch next row
Valid := 1;
END
Figure 15. ClearGarage Procedure Flow
44
VIPS: Lab II – Prototype Product Specification
3.1.4 RFID Tags and Barcodes
To help demonstrate the integration of the VIPS system with the customer's existing
infrastructure and the correctness of the VIPS Website implementation, the VIPS Test Harness
will use a barcode scanner to read newly created visitor passes.
1. Barcodes will be generated by the VIPS Website barcode generation algorithm and will
represent a five digit number. Each barcode will be unique.
3.1.5 Garage Simulation
The VIPS Garage Simulation will model two garages by simulating hardware, simulating
incoming and outgoing vehicular traffic, and displaying the state of those components
animatedly. The Garage Simulation must respond to commands from the Test Harness which
are defined in this section.
The Garage Simulation models hardware in the following manner:
1. The Garage Simulation will contain two garages.
2. A garage contains one display board, four gates, and a set of vehicles parked within.
3. Each gate has associated with it a barcode scanner, an RFID scanner, and a queue of
vehicles.
4. Each gate may be either an entrance or an exit but not both.
5. When a barcode or RFID tag is scanned, the sensor sends a message to the VIPS Engine,
formatted as defined in Table 2, containing its:
6. Garage identification number
45
VIPS: Lab II – Prototype Product Specification
7. Gate identification number
8. Message type
9. RFID tag or barcode value as appropriate
10. When the VIPS Engine sends a message to a garage’s display board, the display board
will change to reflect the new status contained in the message whose format is defined in
Table 2.
11. When the VIPS Engine sends a message to one of a garage’s gates, the gate will respond
by opening or rejecting depending on the message whose format is defined in Table 2.
12. Rate of traffic flow is controlled by the parameters set by the Test Harness.
13. Based on the rate of traffic flow, simulated vehicles representing users that exist in the
VIPS Database are randomly queued at entrance and exit gates.
14. The state of the model, to include the garages, each garage's display board, each gate's
open/reject status, and the queue of vehicles waiting at entrance gates will be displayed
animatedly.
The Garage Simulation must respond to commands from the Test Harness in order to
demonstrate prototype functionality. These commands are:
15. Pause – Toggles the paused state of the Garage Simulation.
16. If the Garage Simulation is currently active, it will:
17. Suspend gates from processing vehicles from their queues
46
VIPS: Lab II – Prototype Product Specification
18. Suspend vehicles from entering queues for gates
19. If the Garage Simulation is currently suspended, it will:
20. Resume gates processing vehicles from their queues
21. Resume vehicles entering queues for gates
22. Set rate of incoming traffic – Sets the rate at which vehicles enter the entrance gate
queues in vehicles per minute.
23. Set rate of outgoing traffic – Sets the rate at which vehicles enter the exit gate queues in
vehicles per minute.
24. Start-of-day Algorithm – Allocates the reserved spaces for the current date.
25. End-of-day Algorithm – Deallocates the unused reserved spaces for the current date.
[This space intentionally left blank]
[Byte 0]
This specifies the garage number to or from which the messages is traveling.
Garage ID
47
VIPS: Lab II – Prototype Product Specification
[Byte 1]
This specifies the gate number to or from which the message is traveling. If the
Gate ID
message is being sent to a display board, the Gate ID byte is irrelevant but still
must be included.
[Byte 2]
This specifies the type of sensor from or to which the data is traveling.
Message Type
Type
Value
Prototype Command
0
RFID Sensor
1
Barcode Scanner
2
Gate
3
Display Board
4
[Variable Length] This is the message being sent from or to a sensor. Its meaning and length depend
Data
on Message Type.
Message Type
Length and Meaning
RFID Sensor
[32 bit Integer] representing the RFID tag value.
Barcode Scanner
[32 bit Integer] representing the barcode value.
[Byte] representing “Open” or “Reject” commands.
Command
Value
Open
0
Reject
1
Gate
Display Board
[Byte 3] representing available student spaces.
48
VIPS: Lab II – Prototype Product Specification
[Byte 4] representing available faculty spaces.
[Byte 5] representing available visitor spaces.
[Byte] representing Test Harness Command
Command
Value
Prototype Command
Run Start-of-Day procedure
0
Run End-of-Day procedure
1
Table 3. Garage Simulation Message Format
3.1.6 Admin Screen/Test Harness
The Administrative screen will be a function provided to parking services that will allow
for manipulation of the VIPS Database. In the case of the prototype, the functionality of the
admin screen will exceed that of the real world product admin screen, in order to properly
demonstrate the product. The functionality of the admin screen will be:
1. A visitor screen – will allow creation and deletion of visitor accounts. It will also allow
the modification of the following:
a. Visitor name
b. Username
c. Password
d. Visitor address
e. Visitor license
f. Option to generate a pass
2. A garage screen – will allow creation and deletion of garages. It will allow modification
of the following:
49
VIPS: Lab II – Prototype Product Specification
a. Garage name
b. Address
c. Capacity for students, faculty/staff, visitors, and total number of spaces
d. Number of entrances and exits
3. A pass screen – will provide the following functionality:
a. Allow searching of passes by date, user ID, or barcode
b. Allow deletion of a given pass
4. Department screen – will allow Parking Services to create and delete departments and set
the manager ID for each department.
The Test Harness will provide additional functionality above that of the admin screen for
the purposes of the demonstration. In addition to the functionality of the admin screen it will
provide:
1. Full manipulation of the VIPS Database, including:
a. Current date
b. Number of available spaces in a garage
c. Number of student, faculty, and visitors in a garage
2. Scenario management – the Test Harness will provide quick links to predefined scenarios
for the demonstration.
a. Case one – the garage is full for students, faculty and visitors
b. Case two – the garage is full for students but not faculty or visitors
c. Case three – the garage is full for faculty but not students or visitors
3. Entry and departure forms – the Test Harness will provide input boxes allowing manual
entry of pass information, demonstrating what happens for a specific individual.
50
VIPS: Lab II – Prototype Product Specification
4. Garage Simulation – the Test Harness will have several options to change the
configuration of the Garage Simulation, including:
a. Entry rate
b. Exit rate
c. Add garage
d. Remove garage
3.2
Performance Requirements
Important components that have performance requirements are the VIPS Website, VIPS
Database, VIPS Engine and the Garage Simulation. The VIPS prototype has performance
requirements to help ensure that it can meet the demand that the real world product faces. Each
requirement is important to achieve, so testing the prototype is important.
3.2.1 VIPS Website
Since the VIPS Website is the main focal point for the customer, a good experience is
necessary for repeat visitors. To appeal to the widest audience of visitors, performance
requirements were created to insure that users running with the minimal specifications could
have a smooth, quick and positive experience. The performance requirements for the VIPS
Website are:
1. Pass size is less than 1 MB.
2. Barcode generation takes less than 7 seconds.
51
VIPS: Lab II – Prototype Product Specification
3.2.2 VIPS Database
The VIPS Database will be the central point of information exchange for the
implementation. Therefore it is necessary to provide an appropriate response time to ensure
proper traffic flow.
1. Transactions will take no more than 2 seconds to complete.
3.2.3 VIPS Engine
The VIPS Engine is the most likely bottleneck in the VIPS system because it acts as the
interface between the Garage Simulation and the VIPS Database. Because it has the potential to
wait on transactions from the VIPS Database, it is important to define how quickly it must
perform them.
1. The VIPS Engine must process and respond to all messages from the Garage Simulation
within three seconds. This includes:
2. Verifying the input via the VIPS Database procedure
3. Sending the appropriate signal to the VIPS Garage Simulation gate
4. Sending the appropriate signal to the VIPS Garage Simulation display board
5. The start-of-day and end-of-day garage space allocation and deallocation must start and
complete within five seconds of issuing the command from the VIPS Admin Screen/Test
Harness.
6. The VIPS Engine must query the VIPS Database's 'GarageCount' table and update any
discrepancies no less than once every two seconds.
52
VIPS: Lab II – Prototype Product Specification
3.2.4 Garage Simulation
The Garage Simulation has several specifications regarding the performance of its
simulated hardware. The Garage Simulation must be able to
1. Model two garages, with one display board and four gates per garage
2. Each garage must be able to contain up to 50 vehicles.
3. Update display boards less than a second after receiving properly formatted input.
4. Finish opening gates within two seconds of receiving properly formatted “OPEN”
command.
5. When combined with the performance requirements for the VIPS Engine and VIPS
Database, total scan-to-open time should be within five seconds.
3.3
Assumptions and Constraints
The VIPS prototype will have limitations and constraints. Due to this, VIPS Inc. has
developed a list of assumptions, constraints, and dependencies. The development of the
limitations, as shown in Table 3, is necessary to document any assumptions, constraints, and
dependencies because these will affect the requirements and explain possible incompleteness of
the prototype. For instance, VIPS Inc. will assume that the garages will be gated 24 hours a day.
This assumption allows VIPS Inc. to focuses on the innovative functionality of the prototype
rather than solving trivial issues. The development of a limitations table will allow VIPS Inc. to
produce and test a viable prototype to show functionality as it will relate to the complete product.
Table 3 contains a complete list of assumptions, constraints, and dependencies associated with
the VIPS prototype.
53
VIPS: Lab II – Prototype Product Specification
Conditions
Type
The parking environment will be
Effect on Requirements
Eliminate the need of tracking cars when gates
Assumption
gated 24 hours
are open
Prototype will only service
Assumption Prototype will not deal with mass subscriptions
visitor requests one at a time
A computer will be in parking
Will allow the system to use the same services
services to facilitate last minute
Assumption
for advance and day of purchases
requests
Conditions
Type
Effect on Requirements
A customer based database will not be created.
A table in the VIPS database
Assumption The customer database will be emulated as a
will be used for the blacklist
table in the VIPS Database.
User passwords will be plain
Prototype will not enforce an encryption
Assumption
text
algorithm on the user passwords
There will be enough spaces in
Allows the visitor parking to be guaranteed
the garage at the start of the day
Assumption without the reallocating of subscription spaces,
to allocate visitor spaces
prior to the visitor capacity of the garage.
Only one car at a time will pass
This allows for the Garage Simulation to
Assumption
through the entrance or exit
process the barcode/RFID reads one at a time
VIPS will have access to Human
Allows VIPS to develop the Faculty/ Staff
Assumption
Resource records
tables in the VIPS Database.
54
VIPS: Lab II – Prototype Product Specification
A CS department laptop is
Dependency If it is not, a student laptop will be used
available to run the application.
The VIPS Engine is used to
The prototype VIPS Database will fail if the
Dependency
process garage traffic
VIPS Engine does not work.
The VIPS Website is used to
The prototype VIPS Database will fail if the
Dependency
process visitor requests
VIPS Website does not work.
The barcodes used by VIPS will
Allows VIPS to ensure only one pass will be
Constraint
be unique for each visitor pass
issued under any one barcode.
Table 4. Assumptions, Dependencies, and Constraints on Prototype Requirements
3.4
Non-Functional Requirements
Non-functional requirements characterize the performance of the prototype. They are
elements that are present in the all aspects of the development of the prototype. The nonfunctional requirements do not impact the innovative features of the prototype but are needed for
successful development. The non-functional requirements are security, maintainability, and
reliability.
3.4.1 Security
Security is very critical for the VIPS prototype. VIPS customers must be assured that
their data will not be compromised. VIPS will ensure security through the use of access control.
Access control is critical to make sure that the system will not be abused. Access control will be
implemented through the use of username/password. The access control will be created
according to functional requirement 3.1.X. It will not allow unauthorized users access to the
55
VIPS: Lab II – Prototype Product Specification
system and grant authorized users the appropriate access. Security is of the upmost importance
to VIPS Inc. and the appropriate measures will be taken to ensure data security.
3.4.2 Maintainability
The two main things that need to be maintained are the VIPS software systems and the
garage hardware. Once visitors are added to the system, their information is stored internally in
the VIPS Database. The information is stored to allow the visitor access on the day they have
registered for. The visitor data will also be maintained for future visits and to help develop
historical trends. The VIPS Website must be maintained in order to allow the visitor to register.
The VIPS Engine must also be maintained to ensure the garage will allow authorized users to
enter and exit the garages. Hardware, including the laptop and the barcode scanner will be
inspected by VIPS Inc. This inspection will include a visual check as well as operational tests. It
is important for VIPS Inc. to maintain all hardware and software components in order to ensure
an effective prototype development and demonstration.
3.4.3 Reliability
In order for the VIPS prototype to be successful, it must meet a level of reliability. The
barcode reader must be able to scan passes with at least 95% reliability, from a maximum
distance of 6 inches. The prototype software must also work correctly with no critical errors and
be able to appropriately interface with all other components. The VIPS Engine should be free of
any conditions that could cause the software to freeze. The VIPS Database will be able store and
query data whenever necessary, with little to no lag time. The VIPS Website must be able to
handle multiple access requests without degradation of the system. The VIPS Website must also
be able to route visitor requests to the VIPS Database. Reliability is a very important aspect to
ensure a successful development of the VIPS prototype.
56
VIPS: Lab II – Prototype Product Specification
57